C#, C♯, C#相談室 P ..
199:デフォルトの名無しさん
16/11/13 09:01:19.59 sNDrzqcx.net
>194
綺麗なコードをみてみたら素晴らしさが一発でわかるとおもぞ。直感的にすぐに
わかる。わからないようなのではだめだな。
だれか194のためにだせるかな?
200:デフォルトの名無しさん
16/11/13 09:45:56.53 lb7gRuG3.net
>>194
同意。結局世の中に求められてるのは
大ヒットしたVB6レベルなんじゃないかねえ
SOAPがはやらなかったのも一緒。
201:デフォルトの名無しさん
16/11/13 10:23:03.20 67al7/78.net
VB6っぽくも書けるんだけどね。
ポトペタも出来るし。
202:デフォルトの名無しさん
16/11/13 10:23:37.75 sNDrzqcx.net
んーーーーんと考え込むよりもサクサクと作ったほうが手数は多くても生産性が
上がる。と考える人が殆どだから?
203:デフォルトの名無しさん
16/11/13 10:50:51.74 lO2MkZMm.net
html知っていればxamlの可読性にケチを付けること無いと思うんだが
今時html触ったことない人なんだろうか?
204:デフォルトの名無しさん
16/11/13 11:12:37.23 ZjdX2IN8.net
>>198
んーーーーんと考え込むよりもサクサクと作れるような案件ばかりだからだろ
205:デフォルトの名無しさん
16/11/13 11:39:53.10 IKKUDTFw.net
>>194
そんな擁護とか色眼鏡で見ないでも、単純に学習コストが高いのが一番のネックだろう。
206:デフォルトの名無しさん
16/11/13 11:52:49.11 fBLfWj6L.net
どこで何をやってるかわからない、ってのが不思議だな
振るまいを独立にモデリングした上で、UIのどことモデルのどこを対応付けるか、を明確化するのがMVVMであり、バインディングの利点じゃん?
従来のフォーム・イベントゴリ押し的なやり方だとこれが曖昧化してしまうから、どこで何をやってるかがわからなくなる
MVVMでわけわからなくなる人はなにか根本的に間違ったことやってるんじゃないかな?
207:デフォルトの名無しさん
16/11/13 12:15:54.37 IKKUDTFw.net
>>202
慣れてないだけだと思う
>>194
MVVMは高コストって主張も分かる。
単純な案件にはオーバースペックだし、Formsでも十分。
208:デフォルトの名無しさん
16/11/13 14:15:44.38 67al7/78.net
こうして人は老いて逝くのかな。
209:デフォルトの名無しさん
16/11/13 15:30:42.14 zWTpia8y.net
「フロントエンド界隈」が、声だけでかくて市場としては滅茶苦茶小さいのにに似てる
210:デフォルトの名無しさん
16/11/13 19:32:23.00 wHFHc9ra.net
フロントエンドプロセッサ
211:デフォルトの名無しさん
16/11/13 19:51:43.67 6IaE8voh.net
MVVMはOOPと相性悪いよな
間違った変更は拒絶して例外を投げるのが基本のOOP
間違った変更を一時的に受け入れて(そのかわりエラーを状態の一部として持つ)コミット時に不変条件を満たせば良いMVVM
Formsなら例外をキャッチしてメッセージを出して入力を戻すだけでいいからOOP的に正しいモデルをそのまま再利用できる
要するにビューがドメインモデルについてよく知らなくてもビジネスルール的に正しい状態に保つことができる
MVVMだとビュー及びビューモデルがビジネスルール的に正しいか正しくないかということを知っていなければならない
それはビューやビューモデルではなくドメインモデルが管理すべき情報でしょ
212:デフォルトの名無しさん
16/11/13 22:40:30.15 67al7/78.net
レイヤーが違うと思うけど。
難しいから全部フラットで良いよ。
213:デフォルトの名無しさん
16/11/14 17:11:40.86 iSq4NCna.net
var dic1 = new Dictionary<string, string>() { { "key", "value" } };
var dic2 = new Dictionary<string, string> { { "key", "value" } };
どちらでも動くようなのですが、カッコは付けるほうが良いですか?
214:デフォルトの名無しさん
16/11/14 19:10:02.84 xSfNgSMs.net
>>209
お好きな方で。
今なら
{["key"] = "value"}
の方が解りやすいかも。
215:デフォルトの名無しさん
16/11/14 22:10:40.45 p26anzny.net
テキストボックスの入力欄A, B, Cがある
A, Bは自由入力欄、CはA * Bを出力する読み取り専用(A, Bが変化したら即座に再計算される)
A, Bに数値と解釈できない文字列(decimalに変換できない文字列)が入力された場合、即座にERRVALという文字列に置き換える
Cが計算不能な場合、ERRVALという文字列に置き換える
このような画面をWPFで作成したいのですがViewModelとxamlはどのように書けばいいでしょうか?
216:デフォルトの名無しさん
16/11/14 22:57:37.38 2SylIT9P.net
それだけ決まっててむしろどこに悩んでるのさ
217:デフォルトの名無しさん
16/11/14 23:09:54.35 p26anzny.net
>>212
他のプログラマがどう書くか参考にしたいです
218:デフォルトの名無しさん
16/11/15 00:54:17.56 gSjda41/.net
>>199
htmlにはCSSがあるから見た目は外に出せる
219:デフォルトの名無しさん
16/11/15 07:18:35.80 wcWx6QZb.net
>>213
ならまず自分がどう書いたかを晒せよ
220:デフォルトの名無しさん
16/11/15 07:47:41.89 AaicVHah.net
キー入力ミスったら最初から入力しなおしな典型的な糞ソフト仕様だな
221:デフォルトの名無しさん
16/11/15 08:30:57.20 9/yxKzNn.net
>>213
ReactivePropertyのサンプルならググれば見つかるから参考にすりゃいいよ
222:デフォルトの名無しさん
16/11/15 10:37:08.44 9/yxKzNn.net
>>214
xamlを腐しているやつは、xamlを全然知らないんだな
223:デフォルトの名無しさん
16/11/15 11:29:28.89 f/VYzzwV.net
XAMLをよく知っているやつがちゃんとした説明してるの見たことない
224:デフォルトの名無しさん
16/11/15 12:05:59.99 Sy8HLWAK.net
>>219
残念なやつ
225:デフォルトの名無しさん
16/11/15 12:12:58.11 f/VYzzwV.net
というように人格否定しかできない
226:デフォルトの名無しさん
16/11/15 12:39:21.59 Sy8HLWAK.net
>>221
顔真っ赤www
227:デフォルトの名無しさん
16/11/15 14:14:09.51 EsNZ5iro.net
と、知ったかは発狂するのであった
228:デフォルトの名無しさん
16/11/15 17:55:17.20 idS/rHgA.net
CSSはxml形式じゃないから良い
必要なところで必要な形を使うのが良い
229:デフォルトの名無しさん
16/11/15 18:43:22.99 IxpYJQnb.net
全然使われてないのは書店(Amazonでもいいけど)に行くとあからさまにラインナップがしょぼいからすぐ分かる
mizchiと取り巻きの声だけやたらデカいReactみたいなもんだ
230:デフォルトの名無しさん
16/11/15 22:31:04.10 YqUWOmsB.net
>>214
style等は外に出せるぞ。
231:デフォルトの名無しさん
16/11/16 10:35:34.62 hL8zHUS9.net
中はやめてー
232:デフォルトの名無しさん
16/11/18 23:01:26.36 +QqWh5ch.net
変数aがnullならbもnullにして、
aがnullでないならaを用いてmyfuncの計算結果をbに入れたいのですが、
var b = (a == null) ? null: myfunc(a);
こんなふうにしたのですが、もっとスッキリ書けそうな気がするのですが、
思い付きません。
もっとスッキリ書けますか?
233:デフォルトの名無しさん
16/11/18 23:08:28.42 2P9KWEZx.net
myfuncの戻り値を考え直せとしかwwwwwwwwwwww
234:デフォルトの名無しさん
16/11/19 01:56:09.52 eBIxsLr/.net
>>228
var b = a?.myfunc(a);
235:デフォルトの名無しさん
16/11/19 01:57:55.29 eBIxsLr/.net
とおもったらmyfuncはaのメソッドじゃないのね
230は間違い。忘れてくだされ
236:デフォルトの名無しさん
16/11/19 03:57:45.25 gmVZjmNi.net
myfunc(null)がnullを返すようにすれば
b = myfunc(a)で済むんだがなぁ
まあきっとそうではない何かをする関数なんだろうな
おれならaやbがnullである事に特別な意味があったり、myfuncを呼ばない事に特別な意味があるなら
ちゃんとif文書くけどな
237:デフォルトの名無しさん
16/11/19 10:29:56.40 0bgRfGhz.net
>>229
string myfunc(string a){
if(a==null)
return null;
を追加したらスッキリしました!
238:デフォルトの名無しさん
16/11/19 11:12:00.41 6I7N2mEo.net
aってstringだったのか…
余計なことを言いたくなるなあ…
239:デフォルトの名無しさん
16/11/19 11:15:09.05 ZfUdGYAZ.net
スッキリワロタ
どうしてもならジェネリックの拡張メソッドを作っとく手もあったね。
240:デフォルトの名無しさん
16/11/19 17:50:29.26 t3MBfDke.net
nullを返す関数を作ると後々災いの元
241:デフォルトの名無しさん
16/11/19 17:52:57.62 E8arxXAw.net
かと言ってstringで""を返す関数を作っても後々災いの元
242:デフォルトの名無しさん
16/11/19 17:55:21.80 VKIYWaqI.net
>>236
またその話か
それはないよ。
243:デフォルトの名無しさん
16/11/19 23:03:49.26 0bgRfGhz.net
>>236
なんで?
244:デフォルトの名無しさん
16/11/20 00:13:29.86 BknfpFpO.net
暫く使ってみたがWPFというかMVVMはやっぱり良くないな
暫定的にとはいえ不正な状態のオブジェクトを受け入れるってのが致命的にコードを汚くする
カプセル化で状態を保護するのが基本のオブジェクト指向に喧嘩売ってるとしか思えない
245:デフォルトの名無しさん
16/11/20 00:26:32.91 K2ib4r+U.net
>>239
その関数使う使う時に一々nullチェックするの面倒。
それを忘れない保証もどこにもないし。
246:デフォルトの名無しさん
16/11/20 00:30:59.63 ckE9xegj.net
>>241
何という頭の悪さ。
nullを禁止したらnullを返すことで表現していたことを
もっと面倒な別の方法で呼び出し側に伝達する必要が生じるんだけど。
何でこんな簡単なことが分からないのかね。
247:デフォルトの名無しさん
16/11/20 01:00:26.85 KPo4Qlq+.net
FindFirstみたいなメソッドでマッチしない場合にnullじゃないオブジェクトを
返されたとしてもどのみちチェックする必要が出てくる
248:デフォルトの名無しさん
16/11/20 01:09:39.51 X8MMRSH3.net
null返す関数禁止じゃなくてnull代入禁止型にしてくれ
249:デフォルトの名無しさん
16/11/20 01:27:12.98 K2ib4r+U.net
>>242
勉強不足
250:デフォルトの名無しさん
16/11/20 01:38:16.74 K2ib4r+U.net
>>244
C#7.0か8.0に期待。
251:デフォルトの名無しさん
16/11/20 02:13:42.33 ckE9xegj.net
期待するだけ無駄。
馬鹿じゃなきゃちょっと考えればわかるはずだが、
必ず既定値で初期化されるようにするにしろ初期化なしの変数宣言ができないようにするにしろ、
nullを許容することの弊害とは別のより大きい弊害や利便性の低下を生むだけ。
だいたい、nullを許容することの弊害なんて大半はそれを主張してる奴が勘違いしてるだけだ
252:デフォルトの名無しさん
16/11/20 02:22:5
253:9.08 ID:9PtzIqGH.net
254:デフォルトの名無しさん
16/11/20 02:25:15.52 ckE9xegj.net
年齢の問題じゃないね。
馬鹿かそうでないか、それだけの問題
255:デフォルトの名無しさん
16/11/20 05:58:45.20 2ye3zmI2.net
>>244
nullを返す関数や変数にnullを代入する処理をよく使うのですが、
それで混乱した経験も無いのですが、なぜ、
nullを返す関数
変数にnullを代入
に反対する人がいるのでしょうか?
256:デフォルトの名無しさん
16/11/20 07:22:58.86 pCJ1qvOZ.net
>>250
>>241と同じ
257:デフォルトの名無しさん
16/11/20 08:05:54.92 2ye3zmI2.net
>>251
>その関数使う使う時に一々nullチェックするの面倒。
>それを忘れない保証もどこにもないし。
この意味が分からないのですが、関数を使うときにnullチェックする
と言うのは何ですか?
関数がnullを返す場合もあるように自分でそうしているわけだから
何も問題ないと思いますが。
258:デフォルトの名無しさん
16/11/20 08:15:43.24 pCJ1qvOZ.net
>>252
理解できない奴には理解できないからもう気にするな。null禁止にしても同じ問題起きるしw
259:デフォルトの名無しさん
16/11/20 08:27:09.27 2ye3zmI2.net
>>253
気になるんです。
教えてください。
260:デフォルトの名無しさん
16/11/20 08:32:27.43 w/pS54nD.net
そもそもこれは戻り値がstring限定の話じゃないの?
普通のオブジェクトでnull禁止はありえないからね
261:デフォルトの名無しさん
16/11/20 08:43:15.40 pCJ1qvOZ.net
>>255
(nullでなく()デフォルト値を入れた空のオブジェクトを返すって考え方もあるからオブジェクトでも同じだよ
そもそも1つの戻り値で関数失敗成功情報まで返そうとするのが間違い
262:デフォルトの名無しさん
16/11/20 08:47:01.08 3blV6AGf.net
値型は null にならないのでそれで用は足る。面倒なのは、Stringだかが。昔のBASIC の文字列型のように実装した値型を用意すれば解決。
263:デフォルトの名無しさん
16/11/20 09:29:50.43 2ye3zmI2.net
>>257
>面倒なのは、String
C#で文字列を扱っていてnullの扱いで面倒だと感じた経験が
一度もないのですが、Stringでnullがなぜ面倒なのですか?
264:デフォルトの名無しさん
16/11/20 09:42:15.04 BknfpFpO.net
nullは情報を捨ててしまうから可読性が低くなる
エラー許容型を作ってそれを使うのが定石
Errorable<string> s = func();
if(s.HasNoError) WriteLine(s.Value);
else WriteLine(s.ErrorMessage);
if(s.NotFound) ...
if(s.AuthError) ...
if(s.FormatError) ...
...
265:デフォルトの名無しさん
16/11/20 09:59:28.46 Y223jndk.net
>>259
> その関数使う使う時に一々nullチェックするの面倒。
> それを忘れない保証もどこにもないし。
全然改善されてないだろ w
てか、その例なら素直に例外使えよ
266:デフォルトの名無しさん
16/11/20 10:11:47.90 GbOcvoRT.net
IsNullアンチパターンみたいだね
267:デフォルトの名無しさん
16/11/20 10:12:24.08 wbF3tHCA.net
>>260
チェックなしでValueにアクセスしたら例外を投げる
Errorableという名前が見えることによってチェックを忘れるということを回避できる
チェックがめんどくさいという怠惰さには手の施しようがないがnullやエラーコードと違ってチェック方法が統一化できる点も優れている
268:デフォルトの名無しさん
16/11/20 10:27:40.57 9PtzIqGH.net
もう一歩踏み込んで、Maybe。
Valueプロパティは、もちろん無し。
269:デフォルトの名無しさん
16/11/20 10:30:00.58 X8MMRSH3.net
宗教としてC#にアイデンティティを代替している連中(貧乏人ほどオリンピックが好きなのと同じ)なのに
仕様を否定したって聞き入れる訳ないじゃん
ヘジにアントニー・ホーアの言葉をどう考えるか聞いた奴がいるが
なんて答えたか知らないんだろうし
(あるいは、C#に間違いがあってはならないから目をつぶっているか、そもそも英語は読めないか)
270:デフォルトの名無しさん
16/11/20 10:30:10.23 9PtzIqGH.net
>>250
ぼっちで書いてる時は、好きにする宜し。
271:デフォルトの名無しさん
16/11/20 10:35:26.28 2ye3zmI2.net
文字列の場合にはNullも "" も同じだと思えばいいよね
272:デフォルトの名無しさん
16/11/20 10:37:02.45 NgPgW0rj.net
参照型とnull許容型は別の概念にするべきだったと言ってるし
現在、null非許容型を破壊的にならないように言語仕様を変えよう(追加しよう)としている。
将来を全て見通せる人は、いないと言う事だよ。
273:デフォルトの名無しさん
16/11/20 10:38:09.66 Y223jndk.net
>>262
> チェックなしでValueにアクセスしたら例外を投げる
ならはじめから例外でいいだろ
> Errorableという名前が見えることによってチェックを忘れるということを回避できる
マジで言ってるの?
チェックする箇所には変数名しか見えないんだが...
まあ IDE でいちいち型を確認すればいいんだろうけど、エラーチェック忘れるような奴はそう言う型の確認も忘れるわけで...
> チェックがめんどくさいという怠惰さには手の施しようがないがnullやエラーコードと違ってチェック方法が統一化できる点も優れている
たぶん思い付きで書いてるんだろうけど例えば Errorable<string> の
> if(s.AuthError) ...
って何を返すの?
自作のクラスで新しいエラー状態をチェックしたい時はどうするの?
いちいち Errorable を派生させたりしたらチェック方法が統一できないしどうするつもり?
274:デフォルトの名無しさん
16/11/20 10:40:19.54 Y223jndk.net
>>266
お前さんがそれでいいならなんの問題もない
275:デフォルトの名無しさん
16/11/20 10:48:41.71 NgPgW0rj.net
>>249
最近は若くても「老害」みたいな人が少なくないよね。
新しい事を覚える・勉強するのを嫌がる。
現状のやり方を変えるのを恐れる。
現状維持大好き。
良いか悪いは別問題だけど。
276:デフォルトの名無しさん
16/11/20 10:58:38.68 wbF3tHCA.net
>>268
初めから例外を投げるではチェックのためにtryを書かなければならない
パフォーマンスが悪いしifで分岐する処理を書きたいという場面では構文的に不利で不適切
変数の型が見えなくなるほど長いスコープは普通は書かないので考慮しなくて良い
エラーというのは幾つかの典型的なエラーに分類可能
例であげたようにNotFoundやAuthErrorといった幾つかの典型的なエラーを定義しておけば良い
新しいエラーを定義する必要はない
277:デフォルトの名無しさん
16/11/20 11:34:52.66 Y223jndk.net
>>271
> パフォーマンスが悪いしifで分岐する処理を書きたいという場面では構文的に不利で不適切
まあ、これはいいとして
> 変数の型が見えなくなるほど長いスコープは普通は書かないので考慮しなくて良い
フィールドとかには使えないってことでいいかな?
> エラーというのは幾つかの典型的なエラーに分類可能
へー、すごいね w
> 例であげたようにNotFoundやAuthErrorといった幾つかの典型的なエラーを定義しておけば良い
で、Errorable<string> の AuthError ってなにさ
> 新しいエラーを定義する必要はない
自称エスパーのお前はそうなんだろうね w
278:デフォルトの名無しさん
16/11/20 11:43:29.92 lYnhz1xv.net
null非許容型が追加されたら便利だなーとは思う
「nullをなくせ」という意見にはまったく賛同できないが
エラー許容型は、エラーの種類を enum で返すプロパティを付けたものをよく作る
(エラー種類ごとにプロパティ作るようなことはしない)
でも、nullで済む場合も多いんだよね
279:デフォルトの名無しさん
16/11/20 11:43:53.85 kKwT4/wt.net
>>272
はぁ
今は返り値の話をしているんだろ
そもそもオブジェクトの内部状態であるフィールドがエラーを受け入れるのが間違いって基本的なことになんで思い至らないのか
すごいっていうか、常識
人間がどんだけエラー処理と付き合ってきたと思ってるんだ?
AuthErrorは認証、認可のエラー
2chの書き込みだから横着して省略したがこれらは普通は別にする
nullを見ただけでエラー内容がわかる歴史上類を見ないほどに強力なエスパーの君にはかなわないよ
プログラマにしておくのは勿体無いから新しい宗教でも立ち上げることをお勧めするよ
280:デフォルトの名無しさん
16/11/20 11:47:36.19 pCJ1qvOZ.net
変数にエラーコードを入れるっていう発想がもうw
281:デフォルトの名無しさん
16/11/20 11:47:38.25 GbOcvoRT.net
>>266
その考えの場合はnullじゃなくて、""を返すのも良いかもね。
282:デフォルトの名無しさん
16/11/20 11:56:23.29 Y223jndk.net
>>274
> そもそもオブジェクトの内部状態であるフィールドがエラーを受け入れるのが間違いって基本的なことになんで思い至らないのか
え?
オレオレスタイルをどや顔で言われても困るんだが w
> これらは普通は別にする
結局 Errorable<string> と Errorable<database> は別に作るってことかよ...
チェック方法が統一出来るとかほざいてたのにね w
283:デフォルトの名無しさん
16/11/20 12:10:20.24 kKwT4/wt.net
>>277
はぁ
オレオレスタイルではなくオブジェクト指向の基本
別に作らないよ
君は超人的エスパーだから何をどう考えてそういう答えにたどり着いたのか常人にはちょっと理解しがたいんだ
これからはそのことを考慮して常人にもわかるように丁寧に意見して欲しい
284:デフォルトの名無しさん
16/11/20 12:10:41.53 zFrmc+0J.net
>>266
オラクルですね
285:デフォルトの名無しさん
16/11/20 12:23:00.48 L/fyhMFX.net
>>277
みっともないから、もう止めとけ。
286:デフォルトの名無しさん
16/11/20 12:30:03.99 Y223jndk.net
>>278
オレオレスタイルは宗教だろうから教祖さんと争う気はないよ w
で、
> これらは普通は別にする
の意味を説明してみ
287:デフォルトの名無しさん
16/11/20 12:30:42.62 Y223jndk.net
>>280
お前がな w
288:デフォルトの名無しさん
16/11/20 12:37:01.76 kKwT4/wt.net
>>281
この文脈でauth errorと省略せずにauthentication errorとauthorization errorに分けるという意味以外に何があるんだ?
君は何をどう考えてErrorable<string>とErrorable<database>は別に作るという考えに到達したの?
ジェネリック型の新しい使い方を編み出したの?
ハイレベルすぎてついていけないよ
一体何段階思考手続きをスキップできればこの境地にたどり着けるのか
289:デフォルトの名無しさん
16/11/20 12:38:10.81 aCqfb5MR.net
数字の0が無かった時代に0の発明を否定する人みたいだな。
290:デフォルトの名無しさん
16/11/20 12:43:24.41 h3zFIm5r.net
何度も言うけどnullを追放したって問題Aが別の問題Bに置き換わるだけ。
そして普通に考えれば問題Bの悪質性はAより大きくなる場合の方が多いだろう。
nullガーって吠えてる馬鹿って何でこの程度のことが分からんかね。
(a) 値がnullであることで問題が顕在化した
からといって
(b) nullの存在が問題の原因
であるとは限らない。
この程度のことも分からない奴はプログラマ辞めろよ本当
291:デフォルトの名無しさん
16/11/20 12:45:41.10 2ye3zmI2.net
>>279
そう、
オレオレスタイルではなてく
オラクルスタイルだ。
292:デフォルトの名無しさん
16/11/20 12:53:48.90 Jza3G5L3.net
結局メソッドがエラーを返せるようにするにはどうするのが一番いいの?
293:デフォルトの名無しさん
16/11/20 12:54:07.99 Y223jndk.net
>>283
> この文脈でauth errorと省略せずにauthentication errorとauthorization errorに分けるという意味以外に何があるんだ?
そんな話は全くしてないが?
そんなのどうでもいいから
>> で、Errorable<string> の AuthError ってなにさ
の答えを書けよ w
294:デフォルトの名無しさん
16/11/20 12:54:12.13 L/fyhMFX.net
まさに、井の中の蛙 (´・ω・`)
295:デフォルトの名無しさん
16/11/20 12:57:21.73 L/fyhMFX.net
>>287
1つの手段は、エラー種類と「値」のタプルを返す。
これだと、エラー処理を強制は出来んけどね。
296:デフォルトの名無しさん
16/11/20 12:57:41.85 Y223jndk.net
>>289
上から目線で意味のないこと言ってるけどどうしたの?
ここ仮にも技術系の板だから話に加われないなら黙っていてくれるとありがたいんだが
297:デフォルトの名無しさん
16/11/20 17:21:32.25 XK08TpAy.net
エラーはほとんどの場合例外でいいよ
でも例外が使えない場面もあるんだよなぁ
298:デフォルトの名無しさん
16/11/20 18:54:25.34 34y1pXq0.net
>>287
エラーと言ってもいろんなレイヤーでいろんな事があるわけで
結論としてはケースバイケースでどれが一番とか決めれない
これを理解できずに単一の方法ですべてやろうとするからおかしな話になるわけで
まあ、宗教論はその宗旨に納得できる点がある場合もあるけど、他の宗教を認めないのがなぁ
299:デフォルトの名無しさん
16/11/20 19:03:56.76 eCa9a5kv.net
例外を投げないパターンはここらへんを読むといいんじゃない?
一般的とは行かなくても、オレオレではない
URLリンク(faithandbrave.hateblo.jp)
URLリンク(ufcpp.net)
URLリンク(www.open-std.org)
300:デフォルトの名無しさん
16/11/20 19:18:59.75 V9rEuhsa.net
nullable-likeの提案は良いね
301:デフォルトの名無しさん
16/11/20 19:26:56.04 w/pS54nD.net
nullを排除するために、何故ここまで複雑に作る必要があるのか理解出来ん
普通にnull使えよw
302:デフォルトの名無しさん
16/11/20 19:31:08.12 34y1pXq0.net
単にnullの取り扱いから、例外処理についてに話が拡大してるからな
303:デフォルトの名無しさん
16/11/20 19:46:59.71 ELwGw4ow.net
null排除派はごく一部いるけど市民権を得てない
メリットが薄いから
3 == i と言う書き方みたいにこだわる人だけこだわる
304:デフォルトの名無しさん
16/11/20 20:23:01.03 JNgwCyth.net
今後iOS開発の主流になるだろうSwiftがnull非許容ベースだから
将来的には分からないかもよ
305:デフォルトの名無しさん
16/11/20 20:32:56.89 ixFUSBgZ.net
信者にそんな話しても無駄
306:デフォルトの名無しさん
16/11/20 20:42:02.87 RSV7nlYW.net
null あってもいいって言ってるのはなきゃなでも構わない人が大半じゃないかと思う。
Swift が非許容でそれを使う必要があるなら、それの流儀でなんの苦もなく対応しそう。
そんなことに拘ってるのはオレオレな一部の人だけじゃねーのかなぁ。。
307:デフォルトの名無しさん
16/11/20 21:02:17.68 2AHf550w.net
異教徒にそんな話しても無駄
308:デフォルトの名無しさん
16/11/20 22:12:22.04 eCa9a5kv.net
>>296
それを言い出すとなにも言語仕様がいじれなくなっちゃう
Javaとかは進化が停滞して今必死に挽回してるし
もちろん、実装や文法の複雑さと利点を天秤にかけるのは常にしてるので、Roslynのissueとかを見てみると良いよ。
もっと変なのもたくさんある
URLリンク(qiita.com)
を見るとわかるが、実際に各言語がnull安全に取り組んでる
309:デフォルトの名無しさん
16/11/20 23:25:18.49 OrHcogku.net
null安全ねえw
そういう発想をする人ってよくいう「例外を握りつぶす」コードを書いちゃうタイプなんだろうなとは思うわ。
言いたいことは理解できるが全く同意はできない。
それはただの錯誤だからな。
安全どころか、nullであれば容易に発見できたバグをわざわざ発見困難にするだけ。
何がうれしいんだそんなの。
310:デフォルトの名無しさん
16/11/21 00:24:21.34 hlf3slD2.net
ScalaのOption使ってみた感想
・今までは無効な値(null)を返す可能性がある事は、ドキュメントを読まないと分からなかったけど定義だけで分かるから便利
・分解が色々な方法で出来て便利
まあなくても何とかなるけど、あれば便利程度
311:デフォルトの名無しさん
16/11/21 01:11:30.92 fZvEw43o.net
F#にもoptionあるけど死ぬ程便利だわw
先ず、エラーを握り潰す事が出来ない。
ドキュメントを読む必要が無い。
monadとして扱うと、一々ifで分岐書く手間がなくなる。
eitherまで踏み込めば、検査例外云々で議論する事自体が馬鹿らしくなる。
面倒くさいけどねw
C#のint?を使った事ある人には解ると思う。
コンパイラに事前チェックをしてもらえる有り難みが。
機械に解る単純作業?に対して、人間が一々苦労する馬鹿らしさが。
312:デフォルトの名無しさん
16/11/21 01:16:13.30 fZvEw43o.net
それから、初心者に対してこそ効果抜群だよ。
「そう書く」事しか出来ないから。
強制出来るから。
313:デフォルトの名無しさん
16/11/21 01:34:00.10 CO+aVjyU.net
検査例外も出たときは素晴らしい機能だって絶賛されてたような気がするなぁ
314:デフォルトの名無しさん
16/11/21 02:03:53.66 n+GSTHBL.net
検査例外は他に誰も採用しなかったけど
Optionalはこぞって採用されているという決定的な違いがある
315:デフォルトの名無しさん
16/11/21 02:04:20.65 n+GSTHBL.net
あ、ごめん
C#perにそんなこと言っても分からないよね(苦笑)
316:デフォルトの名無しさん
16/11/21 11:12:26.42 Ka0MFQDU.net
ん?Optional?VBの話?
317:デフォルトの名無しさん
16/11/21 11:41:21.77 hLpmxTjl.net
グラディウスだろ
318:デフォルトの名無しさん
16/11/21 17:31:28.36 fZvEw43o.net
>>310
このスレにもいるような「老害」は少数派だよ
と信じたい。
319:デフォルトの名無しさん
16/11/21 20:45:41.48 HLjti5+r.net
実際、エラーの扱いは時代によって色々変わってきてるからね
null安全の手法はこれからの主流になっていくのかもしれない
そんで、また数年後には新しいやり方に置き換えられるんだろう
320:デフォルトの名無しさん
16/11/21 21:06:27.63 4A1pLeCT.net
エラーの扱いじゃなくてヒューマンエラーを未然に防ぐのが意図でしょnull安全ってのは。
その意図は認めるけど、null安全がその目的に対して合理的とは全く思わんがね
321:デフォルトの名無しさん
16/11/21 21:15:05.95 fZvEw43o.net
option型とnull安全は重なってる部分もあるけど、意味としてズレてる部分もある。
例えば、C#の値型でもoption型は有意義な訳で。
322:デフォルトの名無しさん
16/11/21 22:30:24.18 wfKopLFy.net
サードパーティーライブラリーを使えない前提でオブジェクトのマッピングを手軽に行うにはなにを使う?
パフォーマンスはあまり気にしていない
同名同型のプロパティをマッピングできれば十分
今のところシリアライザーで誤魔化してる感じ
323:デフォルトの名無しさん
16/11/22 00:16:30.64 QATijxTL.net
null安全よりstring?.lengthの方が合理的に見えるわ
最初からならともかく、ここまで普及したC#で今更取り入れて定着するのは難しいよな
324:デフォルトの名無しさん
16/11/22 06:51:43.66 y8FHZWuV.net
>>318
> 最初からならともかく、ここまで普及したC#で今更取り入れて定着するのは難しいよな
これには同意するけど
> null安全よりstring?.lengthの方が合理的に見えるわ
これはないわ
string が null になる可能性がないなら普通に string.length って書いた方がエラーが早期にわかるからデバッグも楽だし
325:デフォルトの名無しさん
16/11/22 07:50:04.91 vhsrXRxU.net
?.もnull安全の一環な気はする。
ちなみに、null非許容型導入の影響で、?.を使っていない箇所は全てwarning扱いになる話もあったりする。
326:デフォルトの名無しさん
16/11/22 13:10:29.71 bfu4FZ0h.net
string?.length
これって式の左辺に何書くの?
int? hoge
とか?
で結局hoge==nullとか聞いちゃうの?
?.演算子は参照型と値型のペアでは使いにくいし分かりにくいと思う
327:デフォルトの名無しさん
16/11/22 17:09:05.83 EJKURZYz.net
君ら一体何を議論してるの?
分かりやすく解説してくれ
328:デフォルトの名無しさん
16/11/22 17:11:14.76 VnsYzvlz.net
Optionalの是非というか使い所の話でないの?
329:デフォルトの名無しさん
16/11/22 19:57:46.66 vhsrXRxU.net
>>321
例えば
int len = str?.Length ?? 0;
330:デフォルトの名無しさん
16/11/22 20:13:33.64 ga0p/qoV.net
C++の参照は良いものだった
331:デフォルトの名無しさん
16/11/23 10:56:47.19 Sj0D9A4Y.net
>>325
なんで過去形?
332:デフォルトの名無しさん
16/11/23 11:55:24.93 Sj0D9A4Y.net
URLリンク(stackoverflow.com)
このページで
dictionary.FirstOrDefault
とやっていますがディクショナリーにFirstOrDefaultを
やるとなぜこういう結果になるのですか?
333:デフォルトの名無しさん
16/11/23 13:27:10.63 GLuKyrfg.net
>>327
何を「何故」と思ってるか分からん
334:デフォルトの名無しさん
16/11/23 18:46:09.31 QXjR6WNV.net
>>327
Dictionaryは、IEnumerable<KeyValuePair>を実装しているから。
335:デフォルトの名無しさん
16/11/23 19:25:46.80 Sj0D9A4Y.net
>>328
FirstOrDefault って最初の要素を取って来るんじゃないんですか?
何故全ての要素をループ出来るんですか?
336:デフォルトの名無しさん
16/11/23 19:44:53.91 GLuKyrfg.net
>>330
『引数の条件に一致した』最初の要素ね。
内部的には列挙子で探してるよ。
337:デフォルトの名無しさん
16/11/23 19:48:19.93 4RFw+AHR.net
列挙子=enum ・・・
338:デフォルトの名無しさん
16/11/23 19:49:49.71 dUmyuUeh.net
列挙子はIEnumeratorですw
339:デフォルトの名無しさん
16/11/23 20:19:45.57 Sj0D9A4Y.net
>>331
そういうことですか。
良く分かりました。
皆さん、ありがとうございました。
340:デフォルトの名無しさん
16/11/23 20:45:31.10 mr7aPRRr.net
>>322
時代の流れについて行けないおじいちゃん達をいかに介護するかの議論だよww
341:デフォルトの名無しさん
16/11/24 09:15:21.21 DNYUjCey.net
プロジェクトA C#DLLライブラリ
プロジェクトB C#ASP.NETアプリケーション(Web サイト)
プロジェクトC C#ASP.NETアプリケーション(Web API)
BとCはAに依存している
BとCは別のサーバーにデプロイする
2つのサーバーにインストールされているフレームワークが異なる(具体的には4と4.5.1)
サーバー管理者の都合によりフレームワークの更新はできない
Bをビルドする時はAのフレームワークバージョンを4にする
Cをビルドする時はAのフレームワークバージョンを4.5.1にする
このビルド時のフレームワーク切り替え作業が手間なのでなんとかして1オペレーションでビルドできるようにしたい
なんとかなりませんか?
342:デフォルトの名無しさん
16/11/24 09:36:13.90 iMAQMNBa.net
そういうのは依存してるとは言わない
aだけビルドするsln、bcだけビルドするsln作っておいて
aだけビルドするabcのslnでbcはポストビルドイベントでコマンドラインビルド、
bcだけビルドするabcのslnでaはプリビルドイベントでコマンドラインビルドとか?
343:デフォルトの名無しさん
16/11/24 14:18:54.69 G2Ig6Dqz.net
>>336
Webサイトって、Webアプリとは違ってランタイム側でビルドするんじゃなかったっけ?
344:デフォルトの名無しさん
16/11/24 18:57:30.96 /9TZdtP5.net
>>336
プロジェクトCを4.0指定で実行させれば良いんじゃ
>>338
webサイトにもプリコンパイルってのがある
VSがサポートしてるのかどうかはしらんが
345:デフォルトの名無しさん
16/11/24 22:53:33.34 5QlniI4z.net
教えて下さい。
C# で Windows のサービスプログラムを書きました。
その中でプロセス間通信を使いたく、パイプ(NamedPipeServerStream/NamedPipeClientStream)の利用を考えました。
サービスプログラムはそのままだとデバッグが面倒なので、
そのサービスプログラムを参照したフォームプログラムを作ってバグ取りをしました。
フォームプログラムからは、ボタンを押すことでサービスの開始や停止の処理をそっくり呼ぶようにしています。
ここで、
・フォームプログラムでは、問題なくパイプの送受信が出来る
・サービスプログラムでは、パイプの送受信が出来
346:ネい ただし、サービスを止めるときにパイプの待ち受けを終了させるために、同じプログラム内から送信するデータは送受信できている ⇒ 実際に待ち受けを抜けているので同プログラム内では出来ていると思われる と言う状態になりました。 サービスプログラム内でプロセス間通信、この場合は名前付きパイプですが、の使用に制限などはあるのでしょうか。 他の要因を考えるべきか悩みました。情報があれば教えていただけると助かります。
347:デフォルトの名無しさん
16/11/25 01:40:52.65 gI/r9WkT.net
>>340
セッション0のアクセス権限の問題。
namedpipeclientstream-can-not-access-to-namedpipeserverstream-under-session-0
URLリンク(stackoverflow.com)
348:デフォルトの名無しさん
16/11/25 10:25:47.20 2+oHnkxr.net
fw3.5からfw4.0以上のdllを参照する方法ないかなぁ?
349:デフォルトの名無しさん
16/11/25 15:18:07.17 6J0+Q2dT.net
>>341
よくそんなのぱっと出てくるなあw
350:340
16/11/25 23:09:50.97 Oc8F6euI.net
>>341
やっぱりそういうのがあったんですね。。
対策を考えます。
ありがとう。
351:デフォルトの名無しさん
16/11/26 00:37:00.99 pkHe6RQg.net
上のリンク先の回答みたいにPipeSecurityとか適切に設定してやればいいんじゃないの
352:デフォルトの名無しさん
16/11/26 15:34:45.46 w/Dhvdu8.net
WindowsのAPIだからC#とは直接的には関係ないけど教えてほしい。
特定のウィンドウにキーボードイベントを送信しようと考えている。
keybd_eventを使用してキーボードイベントの送信する事は成功した。
ちなみに第二引数のスキャンコードは使用しない、みたいな事を書いてあるサイト(MSDN含む)が多かったが
スキャンコードを指定しないと対象アプリがキーボード処理を受け付けてくれなかったため指定してある。
対象アプリがバックグラウンド中であっても操作しようと考えてSendMessage(またはPostMessage)に変更しようとしたのだが
スキャンコードはどこにどのように設定すればいいのだろう?
第四引数のlParamであろうと言う事は想像がつくが、スキャンコードをそのまま設定しても駄目だった。
353:デフォルトの名無しさん
16/11/26 16:13:12.18 dXHq99jt.net
>>346
WM_KEYDOWNならこれ、カーソルキーとかも24ビット立てる必要があったかな
URLリンク(msdn.microsoft.com)
SendMessage(hWnd, WM_KEYDOWN, uCode, MapVirtualKey(uCode, 0) << 16 | 1)
とかそんな感じだったはず、離すときはWM_KEYUPにして32ビットを立てる
C++でWM_KEYDOWNイベントのlParamを吐くウィンドウプロシージャでも作ると良い
354:347
16/11/26 16:22:01.70 dXHq99jt.net
> 離すときはWM_KEYUPにして32ビットを立てる
うっかりミスった、30〜31ビットね
WM_KEYDOWN時のlParam | 0xC0000000する形
355:347
16/11/26 16:37:54.65 dXHq99jt.net
あ、そもそもC#でもウィンドウプロシージャオーバーライド出来たっけ
protected override void WndProc(ref Message m) {
base.WndProc(ref m);
if(0x0100 <= m.Msg && m.Msg <= 0x0102) Text = m.ToString();
}
とか適当なフォームでやれば実際のウィンドウメッセージが確認できるよ
356:デフォルトの名無しさん
16/11/26 17:19:55.67 w/Dhvdu8.net
>>347-349
非常に参考になった。
これを元にキー送信処理を作り直すことにするよ。
357:340
16/11/26 21:03:56.05 ZtR+Z7Wd.net
>>341,345
昨日はまだ調べていませんでした。
341 に書いていただいた URL の方法で普通に出来ました。
ありがとう。
358:デフォルトの名無しさん
16/11/27 21:23:49.80 I1ny1q/I.net
妙な質問だけど、今2ch以外でユーザー同士でC#関連の質問解答ができるコミュニティーって、
- MSDNフォーラム
- わんくまの掲示板
- DOBON.NETの掲示板
質問して答えが返ってきそうなのはこのぐらい?
あ、別にマルチで質問投げてやろうとかそういう意図ではないので念のため
359:デフォルトの名無しさん
16/11/28 00:18:17.41 n0A2uJuC.net
ja.stackoverflowはもう泣く以外の道ないなw
360:デフォルトの名無しさん
16/11/28 00:18:37.64 VTugBhJZ.net
>>352
StackOverflow一択だろ
361:デフォルトの名無しさん
16/11/28 00:23:13.14 fF5TvHl5.net
google翻訳少し賢くなったんだから「このページを翻訳する」で結構使える
362:デフォルトの名無しさん
16/11/28 01:04:22.51 v97E8kC6.net
>>352
最近はteratailもありかも
あとは、.NET共通のことならVB中学校も一応あり
363:デフォルトの名無しさん
16/11/28 01:42:44.60 9T0ZytTv.net
>>353-354
stackoverflowって日本語版もあったのかw
ありがとう
>>356
teratailはまったく知らなかったありがとう。
364:デフォルトの名無しさん
16/11/28 03:25:24.52 PwcZf+No.net
あとはQA@ITとか
365:デフォルトの名無しさん
16/11/28 04:33:07.21 VTugBhJZ.net
>>357
日本語限定ってどこかに書いてあったっけ?
366:デフォルトの名無しさん
16/11/28 19:31:45.97 FcPInj/k.net
>>359
>- MSDNフォーラム
>- わんくまの掲示板
>- DOBON.NETの掲示板
日本語って一目で分かるだろ
367:デフォルトの名無しさん
16/11/28 19:35:28.66 MT+LNPN6.net
落ち着けよハゲのブラザー
368:デフォルトの名無しさん
16/11/28 21:09:47.26 SXoUdBtU.net
>>354は stackoverflow.com のつもりで書いたが>>357は ja.stackoverflow.com を見つけて、
日本語版の存在を知らなかった>>354は>>357を皮肉と受け取った。
369:デフォルトの名無しさん
16/11/28 21:23:26.86 C8x/B1Vp.net
>>360
バカの連鎖反応
370:デフォルトの名無しさん
16/11/28 21:35:12.23 Efu8jG2p.net
人脈作れば全部解決だろ
Xamarinユーザー見習えよ
371:デフォルトの名無しさん
16/11/28 22:05:43.16 /OQd0iyQ.net
元の質問者の>>352だけど、質問の仕方がまずかったなら謝るけど
無意味に喧嘩腰でつっかかるのはどうかと思うよ
意図としては英語も排除しないけど日本語のを中心に教えて欲しかった。
英語は読むのは何とか読めても書く(質問する)のは結構つらいっすわ。
372:デフォルトの名無しさん
16/11/29 15:41:26.31 07zLg605.net
>>364
あのオタサー集団と同列に見られるのは非常に辛い
373:デフォルトの名無しさん
16/11/30 08:32:18.72 rOv2n/Yl.net
axwindowmediaplayerで次、前のボタンにイベントを割り当てるのはどうしたらいいですか。
this.axWindowsMediaPlayer1.Ctlcontrols.next += new AxWMPLib.なんちゃらなどで記述?
ボタン自体もグレーアウトしていて使えない状態です。
再生などのボタンは初めから再生が割り当てられていてなにも記述しないでもよかったのですが。
374:デフォルトの名無しさん
16/11/30 11:01:13.74 U6G+25fY.net
AxWindowsMediaPlayerでそんな細かい制御はできない
currentPlaylistとかでIWMPMedia管理すればそれらも使えるようになるはず
組み込みのプレイリスト使いたくないならUIも自分で全部やる
375:デフォルトの名無しさん
16/11/30 16:39:10.32 y2jQ/DIV.net
LINQのQuantifierの日本語訳なんだけど、MSDNだと量指定子、
岩永さんのところだと限定子となってるけど、どっちがより適切だと思う?
URLリンク(msdn.microsoft.com)(v=vs.120).aspx
URLリンク(ufcpp.net)
376:デフォルトの名無しさん
16/11/30 23:23:25.49 rOv2n/Yl.net
>>368
ありがとう。プレイリストがよさそうです。
377:デフォルトの名無しさん
16/12/01 09:05:41.40 ySUX8EsS.net
>>369
語義的には量指定子じゃない
quantityが量だから
378:デフォルトの名無しさん
16/12/01 18:33:51.23 CcMyBcAe.net
でも量指定子って正規表現的な言い回しだよな。
SQL的な言い回しだとALL,ANY,SOMEとかは限定子になるはず。
URLリンク(software.fujitsu.com)
379:デフォルトの名無しさん
16/12/01 18:37:08.39 CcMyBcAe.net
ただまあ本家が量指定子ってるんだから、量指定子が正式用語ではあるだろうけど。
380:デフォルトの名無しさん
16/12/01 18:39:48.63 lOA8D/0g.net
英語のまま使ってもらいたい
381:デフォルトの名無しさん
16/12/01 19:00:45.21 74fND9I4.net
そもそもそんなキーワードを使う場面が思い浮かばない…
382:デフォルトの名無しさん
16/12/02 00:05:35.89 ui5LUeC9.net
AnyとAllとContainsをまとめて分類しただけの言葉のようだが、禿しくどうでも良い
383:デフォルトの名無しさん
16/12/02 00:27:24.78 57Q76p9I.net
一般的な呼び方じゃ量化子だよな。
384:デフォルトの名無しさん
16/12/02 06:58:37.23 jL2K9FKD.net
LINQは日本語ではなに? LINQは英語のままで量化子だけ日本語てのは
運用の誤り。
無理やり日本語にするならクオンティフィアでいいと思うがゴミみたいな
概念をわざわざ日本語にするのはよくない。説明的に日本語で「量化を
意味する」のように使うのは問題ないが、「量化子」のように語彙にして
しまうのはよくない。英語のまま運用するのがよい。
385:デフォルトの名無しさん
16/12/02 07:09:43.00 jL2K9FKD.net
訂正
このサイトの説明では
Any,All,Conttainsを総合的に説明するのが目的だからLINQという具体的な
ものよりは上位概念だな。この場合は限定子で正しいと思う。
量指定、量化はちょっと違うな。
386:デフォルトの名無しさん
16/12/02 07:21:27.21 iUEu5k7c.net
LINQは固有名詞だから訳しようがないけど量化子はすでに記号論理学でも使われてる一般名詞だろ
387:336
16/12/02 07:48:29.69 GGzlnXmJ.net
めんどくさいから英語のままでいいってのはある
388:デフォルトの名無しさん
16/12/02 10:36:52.50 X9iN1GdM.net
明治の人に謝るべき暴言。
389:デフォルトの名無しさん
16/12/02 14:59:21.44 rEQGNTwO.net
>>380
LINQはLanguage Integrated Queryを省略してるだけだから日本語化できるでしょ(してもらいたくないが)
OPEC〜石油輸出国機構みたいに訳してる例は多い
390:デフォルトの名無しさん
16/12/02 17:36:35.56 8D4FZt7r.net
>>383
してみ
391:デフォルトの名無しさん
16/12/02 17:40:15.92 DaaN/lCj.net
383ではないが、『言語に統合された問い合わせ』
・・・ないわ
392:デフォルトの名無しさん
16/12/02 18:09:20.76 rEQGNTwO.net
>>384
統合言語クエリって単語がすでにある。クエリも訳したら統合言語処理要求か?
393:デフォルトの名無しさん
16/12/02 19:38:47.97 4/nN0nxx.net
組込問合せ機能 辺りでいいんじゃね?
394:デフォルトの名無しさん
16/12/02 20:25:58.53 fkVt0GEN.net
統合失調言語
395:デフォルトの名無しさん
16/12/02 20:31:59.72 57Q76p9I.net
「LINQは LINQ Is Not Queryの略」とか言い出して、その後「LINQはLINQ。略語や頭字語じゃない」とか言い出す。
396:デフォルトの名無しさん
16/12/02 20:59:04.23 fqYy1w3v.net
一体誰のことを揶揄した気になっているのかね
397:デフォルトの名無しさん
16/12/02 21:09:36.57 ui5LUeC9.net
横だがストールマン以外の誰と言うんだよ
398:デフォルトの名無しさん
16/12/04 09:09:46.43 HFDVK7VF.net
おまえら言語センスがないな。「問式」でOK。今後日本語でのLINQこれだ。
399:デフォルトの名無しさん
16/12/04 09:20:34.29 a6Aihxwg.net
Bingに聞いたらLINQの日本語訳はLINQでいいってさ
マイクロソフトのお墨付きだからこれが正解な
400:デフォルトの名無しさん
16/12/04 09:42:24.52 zAL6lz1+.net
Binqに聞いたらLINQの日本語での質問はLINEQでいいってさ
に見えた
401:デフォルトの名無しさん
16/12/04 10:29:28.25 U0Kel+uM.net
こういう関数を作ったら
void func<T>(T obj, string name) {
obj[name] = ...
}
[name]の部分でエラーが出ます。
こういう関数は作れませんか?
402:デフォルトの名無しさん
16/12/04 10:41:15.33 0sR5hBHN.net
すべてのクラスが this[string] を持つわけじゃないから…
自分がTに入れたいクラスをwhere T: で指定しては
403:デフォルトの名無しさん
16/12/04 11:15:31.06 U0Kel+uM.net
>>396
ありがとうございました。
上手く行きました。
404:デフォルトの名無しさん
16/12/04 12:05:02.46 OeUSkEhR.net
ジェネリックは使いにくいよな
C++みたいな仕様にしてくれりゃいいのに
405:デフォルトの名無しさん
16/12/04 12:33:20.31 sIaSQQRI.net
>>398
あほす
406:デフォルトの名無しさん
16/12/04 12:56:13.33 3+5uaoN5.net
C++のテンプレートの糞エラーは酷いよな
C#みたいにしてくれりゃあいいのにww
407:デフォルトの名無しさん
16/12/04 13:58:45.59 VS/jD7cp.net
>>398
なんでわざとあんな文法になってると思うんだよ
JIT言語の特長を最大限に活かすためだぜ
コンパイラ言語みたいに使うコードを全てあらかじめ生成しておくわけではなく
Tでnewされた時に初めてコードを生成するからメモリ使用量も少ない
ただ利点はそのまま欠点にもなる
T型同士の演算コードを書くとたちまちエラーになるのでdynamic型にキャストするとかしないとな
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
317日前に更新/272 KB
担当:undef