C#, C♯, C＃相談室 Part94 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/04/22(土) 15:36:53.26

■Visual Studio 2015 Community & Express (無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part92 （実質93）
http://echo.2ch.net/test/read.cgi/tech/1485589613/

■次スレは>>970が建てる事
建てられない場合は他を指定する事。

**デフォルトの名無しさん** · 2017/05/24(水) 12:11:17.02

>>138
お前がな

**デフォルトの名無しさん** · 2017/05/24(水) 12:23:14.46

全部Object型でやってろってのと変わらんがな

**デフォルトの名無しさん** · 2017/05/24(水) 15:17:32.97

>>134
ただの理解不足。具体的にTypeScriptとかのコードでその状況を示して見てよ。

多分、nullが入れられなくなるので初期値に別に値(stringならstring.Empty的なもの)を入れるもんだと思ってるんだろう。
それは間違った考え

・nullの考慮忘れ
・過剰なnullチェック
というのを防ぐのが目的

<従来>
void Hoge(string arg){ 〜 }

//listが要素を持っていなければfirstはnull
string first = list.FirstOrDefault();
//何らかの処理
//nullの考慮忘れ。実行時例外
Hoge(first);

<null非許容型>
//Hogeの引数はnull非許容
void Hoge(string! arg){ 〜 }
//ここは「何らかの処理」の都合でnull許容とする
string first = list.FirstOrDefault();
//何らかの処理
//nullの考慮忘れ。コンパイルエラー
Hoge(first);

**デフォルトの名無しさん** · 2017/05/24(水) 15:28:42.02

実行時例外でるならそれでいいじゃんｗ

**デフォルトの名無しさん** · 2017/05/24(水) 15:34:09.87

>>141
具体的で素晴らしい
確かにその例で示されているような「nullの考慮忘れ」を防ぐ一定の効果は
期待できることは認める。

でもそれ、よく考えると机上の空論でしょ。
普通のプログラマならある変数やコレクションが仕様上nullを持ちうるかどうかは
常に気にしながらコーディングするので、そこに例示されている「nullの考慮忘れ」は
実際にはそんなにありがちな問題ではないと思う。

ありがちなのは、その例でいえばリストに値を入れる段階で
プログラマの意図に反してnullが混入する問題だよね。

**デフォルトの名無しさん** · 2017/05/24(水) 15:55:01.74

実行されるまで気づかないならインタプリタと一緒じゃん

**デフォルトの名無しさん** · 2017/05/24(水) 16:07:24.68

>>143
＞ありがちな問題ではない
ありがちかどうかではなく、その機能を導入するメリットとデメリットの釣り合い。
エラーが未然に防げたり、記述が簡潔で見やすくなるならメリット。
文法が複雑になったり、別のバグの原因になったり、動作が遅くなったり、実装に手間がかかるならデメリット。

現状は「新バージョンではnull許容はstring?にしろよ」から「文法は変更せずフロー解析でどうにかしようぜ」までいろんなアイデアがある

個人的には、標準ライブラリの頭nullチェックをしてArgumentNullExceptionを出すようにしているところがいらなくなってライブラリ作者にはメリットがデカそうかなとはおもってる
null入れてArgumentNullExceptionがでるテストも書かなくて良くなる

**デフォルトの名無しさん** · 2017/05/24(水) 16:22:43.45

>>143
>リストに値を入れる段階でプログラマの意図に反してnullが混入する
nullを含まないリストならList<null非許容型>にすれば意図に反してnullが混入しうる状況ではエラーや警告にしてくれるようになる
List<null許容>から変えられないなら、取り出す時にnull非許容にすればその場でエラーが確認できる

フロー解析で検出が無理な状況も当然存在するけど、多分こんなことをするのかな
<現状>
string A(){
string a = Hoge();//Hogeの戻り値はnull
別の処理
return a;//意図せずnullを返してしまう
}

これだと、別の処理中にぬるぽになったり、戻り値がnullになるかも。
Hogeの戻り値が不適切なのに、別の処理中でエラーが起こるのでスタックトレースとかではバグが探しにくい。

<null非許容>
string! A(){
string! a = Hoge().ToNull非許容;　//null非許容に変換
別の処理
return a;
}
これが以下のようにコンパイルで展開される
string A(){
string a = Hoge();
if( a == null)throw new Null非許容型変換例外();
別の処理
return a;
}

例外発生箇所が確定するので、バグの位置がすぐにわかる
この例だとnull比較のコストが入ってるけど、俺の知識が浅いだけなのでもっとうまいやり方も多分あると思う

**デフォルトの名無しさん** · 2017/05/24(水) 17:14:59.24

そうだねーPHPから出てこないでね

**デフォルトの名無しさん** · 2017/05/24(水) 18:01:59.69

null許容にするメリットを実感できないんだろうな

**デフォルトの名無しさん** · 2017/05/24(水) 19:54:58.94

使えとは言ってないのにな
親でも殺されたか？
ゴミムシの親なんか区別がつかないだろうが

**デフォルトの名無しさん** · 2017/05/24(水) 23:36:34.45

>>146
コンパイル後の出力にnullチェックが入ってるってことは
string! aにnullが入る可能性が出来てしまうってこと！？
そこはコンパイルエラーにしてもらおうよ

>>141の
> ・nullの考慮忘れ
> ・過剰なnullチェック
> というのを防ぐのが目的
（＋テスト）
は、防ぐというより無くしたい

**デフォルトの名無しさん** · 2017/05/25(木) 01:11:21.81

>>150
nullチェックはNull許容型からNull非許容型にする際の話
nullの可能性があるならタイプマッチとかで消すほうが素直だけど、kotlinとかでは例外を投げる変換を用意してるみたい

修正されてない古いライブラリとかだとnullにはならないけどnull許容型みたいのが存在せざるを得ないので、そういう機能もほしいということじゃないかな

**デフォルトの名無しさん** · 2017/05/25(木) 03:16:43.36

今のところ超過激なトンデモ案が優勢なのかな？
採用されたら仕事が捗りそうなので、とても期待しているww

**デフォルトの名無しさん** · 2017/05/25(木) 03:37:28.50

null非許容型が追加されるならconstメソッドも
追加してほしいもんだ。

**デフォルトの名無しさん** · 2017/05/25(木) 03:38:41.10

いまだに2.0とか3.0やってる化石には全く関係のない話だから
足引っ張らないで欲しいわ

**デフォルトの名無しさん** · 2017/05/25(木) 11:11:39.41

Linqすら使えない自分の職場の悪口は止めてくれないか

**デフォルトの名無しさん** · 2017/05/25(木) 11:17:54.20

職場？お遊戯会の間違いだろ

**デフォルトの名無しさん** · 2017/05/25(木) 11:41:19.09

ロック問題で、価値ないつまらんネタ書いている奴こっち来い
適当にあしらってやるよ

**デフォルトの名無しさん** · 2017/05/25(木) 11:44:07.67

>>157
向こうに行ってやれよw

**デフォルトの名無しさん** · 2017/05/25(木) 11:50:35.84

最近は、こっちではnull非許容ネタやってるのか・・・
これ導入されたらガベージコレクタの性能落ちたりしないかな
4G越えのでかいツリー構造とか作っていると、参照つなぎ替えだけで色々やばいことが起こるんだよな
できるかぎり、用のないフィールドに参照ぶら下げたくないと最近しつこくnull入れてたりするんだが。
あと、event関係、弱参照で全部作り直さないとヤバないかな。
Taskとかと相性悪くて簡単にメモリーリーク起こすし、 WeakEventManagerでWPFは変態回避してただでさえコード変態状態だし。
VMごと作り直さないと色々噴き出しそうだ

**デフォルトの名無しさん** · 2017/05/25(木) 11:51:39.74

>>158
ここはキチガイの建てたゴミ箱、ちょうどいいんだよ。

**デフォルトの名無しさん** · 2017/05/25(木) 12:35:35.78

>>159
そんな場合はnull許容型を今迄通り使えばよろし

**デフォルトの名無しさん** · 2017/05/25(木) 12:39:51.97

なんで択一の考えしか出来ないんだろうな
頭悪いのか？
頭悪いならゴミ回収みたいなルーチンワークしてろよ

**デフォルトの名無しさん** · 2017/05/25(木) 12:40:36.41

>>161
統一性のないコードになりそうだw
ここまで破壊的変更をするなら同じVM上で動く別言語として全く新しく設計した方が良い気がしてきている。
C#と混合してプロジェクトに登録できるようにすればシームレスにつながると思う。
今のC#には、アクロバテックな予約語追加とかも増えてきているし、いろいろ限界が来ていると思うんだ。

**デフォルトの名無しさん** · 2017/05/25(木) 13:22:25.50

どうせならC#を改造するのではなく、新規言語にして、ここにあるパターンをサクっと言語仕様として実装してみてほしいな。
https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)
>一部のデザインパターンは、プログラミング言語（例: Java, C++）の機能の欠損の印であると主張されることがある。
>計算機科学者のピーター・ノーヴィグは、GoFによるデザインパターン本の23パターンのうち16パターンは、
>言語によるサポートによって単純化または除去できることをLispやDylanを用いて実演した。

あと、マルチスレッドプログラミングに関するパターンも、C#で書いていて本当に冗長と感じる。
文法は、Pythonみたいにインデントでネストを書けるようにしてくれれば、Pythonと交互に書くときに {} 忘れで判りにくいバクにならなくて済む。

**デフォルトの名無しさん** · 2017/05/25(木) 13:37:43.42

>ID:OZ9w4Yf7
基地外こっちでも大暴れかwww

**デフォルトの名無しさん** · 2017/05/25(木) 13:39:20.53

>>165
ようキチガイ、ここは、お前が建てたスレだろ。
向こういくなや、あっちはマジ質問なんだから。
お前とは、ここで遊んでやる。

**デフォルトの名無しさん** · 2017/05/25(木) 16:36:05.73

まじで基地外だからな・・・

**デフォルトの名無しさん** · 2017/05/25(木) 17:37:12.65

>>163
swiftもkotlinも同じ感じの仕様だから適切に使い分けられれば良いんでないのかな
それがスキルだし

**デフォルトの名無しさん** · 2017/05/25(木) 18:24:15.44

c#がもし最初から作り直せるとしたらどんなふうにする？

俺は
yield returnじゃなくてyieldにする
ジェネリックをsystemに入れる

**デフォルトの名無しさん** · 2017/05/25(木) 18:31:48.41

取り敢えずintは64ビットでstringはnull無し

**デフォルトの名無しさん** · 2017/05/25(木) 18:55:20.09

switchのbreakは省略可能にする

**デフォルトの名無しさん** · 2017/05/25(木) 18:57:08.84

Nodeが快適すぎる
C#ってなんだったの？

**デフォルトの名無しさん** · 2017/05/25(木) 18:57:54.98

>>172
言語と動作環境比べられても…

**デフォルトの名無しさん** · 2017/05/25(木) 19:21:56.48

immutable保証の構文は欲しい
if forは文でなくて式でありたい
副作用隔離文法も欲しい

**デフォルトの名無しさん** · 2017/05/25(木) 19:24:16.19

ジャップなんて99%素人に毛が生えたレベルなのに使い分けとか酷だ

**デフォルトの名無しさん** · 2017/05/25(木) 19:36:21.23

ダック・タイプの問題も最初からすっきり仕様作る

**デフォルトの名無しさん** · 2017/05/25(木) 19:39:01.89

constとreadonlyの整理
c++のconstが好きだった

**デフォルトの名無しさん** · 2017/05/25(木) 19:56:07.17

デフォルトでconst
キーワード指定した時だけ非const
が良いなあ

**デフォルトの名無しさん** · 2017/05/25(木) 20:07:38.18

何が嫌かと言えばVMだな。最初からネイティブコードコンパイラーならC++すら凌駕したかもしれん

**デフォルトの名無しさん** · 2017/05/25(木) 20:09:09.51

少なくともC#のconstとreadonlyは機能的に違うし、
どちらを無くされても困ると思うけど...

**デフォルトの名無しさん** · 2017/05/25(木) 20:10:14.40

>>172
フレームワークって知ってる？

**デフォルトの名無しさん** · 2017/05/25(木) 20:18:46.47

名前空間の分割をもっと簡素にする
今はusing増えすぎでめんどい

あと一ファイルに名前空間一つに限定で
ファイル先頭で指定、｛　｝なしにする
namespace Hoge.Hoge :

これでwebからのコードのコピペが楽になる

**デフォルトの名無しさん** · 2017/05/25(木) 20:24:26.30

switch の最後の節の break は不要にする

ってかこれぐらいすぐやれ
毎回モヤモヤするんだよ

**デフォルトの名無しさん** · 2017/05/25(木) 20:26:15.77

>>180
だから整理って書いたんだけど…
統合って意味じゃないよ

**デフォルトの名無しさん** · 2017/05/25(木) 20:28:33.23

readonlyは長すぎる
javaのfinalもだけど頼むから多用する奴は3文字以内にしてくれ
scalaなら定数も変数も同じ3文字だから揃って見やすいのに

**デフォルトの名無しさん** · 2017/05/25(木) 20:29:42.51

>>184
では整理とは具体的にどういう意味でしょう

**デフォルトの名無しさん** · 2017/05/25(木) 20:33:29.10

細かい機能系だと == オーバーロードが割と収集つかない感じなっているので
object.ReferenceEquals object.Equals を毎回書く羽目になり始めている
これは無駄なので == オーバーロードは廃棄して
object.ReferenceEquals object.Equals の糖衣構文として === !== == != という形にして欲しい。
Java屋がC#登場時に==オーバーロードはヤバイと警告していたが、今のC#は本当にそうなってしまった。
当初は気にしすぎと思っていたが、これは良くなかったな。
<= >= なんかも最低1個書けば残りは自動的に実装してほしいな。
== != はobject.Equalsは必須なので、あとは < <= >= > のいずれか一個を定義すれば残りは全部生成可能。
IComparable<A>を実装したのなら、逆にそこからobject.Equalsを実装してほしい。
object.ReferenceEquals に対応する GetHashCode() は簡単に利用できるべきだ。
LINQを使うときに、Distinct()などで、object.ReferenceEqualsを使いたいケースは多い。
どの比較を使うのか簡単に指定できるようになって欲しい。
比較演算子は、三引数の演算子にして、比較方法、比較対象1、比較対象2という感じにして
a ==[比較方法] b のような感じで扱えるようになると見通しが良くなると思う。
今のC#は、ラムダ式と比較用interfaceが入り混じって混沌の世界と化している。

**デフォルトの名無しさん** · 2017/05/25(木) 20:35:22.76

>>187
トレイトがあれば自動実装出来るのにな…

**デフォルトの名無しさん** · 2017/05/25(木) 20:37:17.55

C++に回帰するのだ

**デフォルトの名無しさん** · 2017/05/25(木) 20:42:49.06

>>189
今のC#はまさにそこに向かっているので嫌なんだよね。
収集のつかない言語拡張、誰も知らない大量の構文と予約語で築かれた謎の言語仕様。
C++は、21世紀のCOBOLだ

**デフォルトの名無しさん** · 2017/05/25(木) 20:44:09.62

c++はほらバカには便利だろう見たいな新機能をいれてるけどそれすら使いこなしにくい

**デフォルトの名無しさん** · 2017/05/25(木) 20:46:56.61

型宣言は後置の方がいい

>>174
>immutable保証の構文

デフォルトでimmutableにして、
必要ならmutableに出来ればよくね

**デフォルトの名無しさん** · 2017/05/25(木) 20:47:18.02

C#が滅んでも困らないからいいや
node.jsがあれば安泰

**デフォルトの名無しさん** · 2017/05/25(木) 21:04:38.19

>>188
キチガイに触るな

**デフォルトの名無しさん** · 2017/05/25(木) 21:08:44.13

>>190
糖衣構文を要求したその口で「収集のつかない言語拡張」とか一体何の冗談？

**デフォルトの名無しさん** · 2017/05/25(木) 21:10:56.06

immutableを構文を作るのであれば、new でプール中にすでに同じ内容のオブジェクトが無いか調査して
既にあるならそちらを利用する仕組みも欲しいな。
これを利用する場合比較演算子EqualsとReferenceEqualsは同じ結果になるのでEqualsもGetHashCodeも自動実装の物でよい。
オブジェクトプールは、弱参照のHashSetで実装される事になると思うが、弱参照の先が死んでいた場合、HashSetの登録項目も整理できる。
ガベージコレクトと一緒にこれを整理できればより効率的だが、これは現状ライブラリベースで作る事は出来ない、VM側のサポートが必要。
これについては、メモリ管理にリファレンスカウンタを実装しても良いと思う、基本はリファレンスカウンタでマークスイープはゴールキーパーとして機能させる感じで。

**デフォルトの名無しさん** · 2017/05/25(木) 21:11:49.39

>>187
何言ってるのかよく分からうけどカオスを増加させるだけにしか思えんな

参照型の==がデフォで参照の比較になっているのが混乱の元だと言いたいならそこは同意する。
VBと同じように参照等価検査専用の演算子を用意して==はオーバーロードしない限り
使えないようにしてくれた方が分かりやすかったと思う

**デフォルトの名無しさん** · 2017/05/25(木) 21:14:05.32

>>195
お前みたいな馬鹿には分からないのですw

**デフォルトの名無しさん** · 2017/05/25(木) 21:18:19.71

>>197
オーバーロードしたらEqualsとの違いが不明確になる。
使う側にはそれはとても伝わりにくい。
だから==と書けばそれはEqualsの事であるという事にした方が簡潔だと思うよ。
比較は頻発するので毎回Equalsを書くのはさすがに面倒。

**デフォルトの名無しさん** · 2017/05/25(木) 21:18:19.88

c#とc++の違いが分からん

**デフォルトの名無しさん** · 2017/05/25(木) 21:24:52.13

>>200
+が2個多いだろ、よく眺めてみろ

**デフォルトの名無しさん** · 2017/05/25(木) 21:27:49.57

>>200
C++…うんこ
c#…B級グルメ

**デフォルトの名無しさん** · 2017/05/25(木) 21:54:41.07

C#を食ったらケツからC++が出るのか

**デフォルトの名無しさん** · 2017/05/25(木) 21:58:44.98

>>186
そんなん知らんよｗ
なんで具体的な提案なんかしなきゃならんのだ
2種もキーワードがあるのにc++のconstに比べて貧弱だなーって思っただけ

この部分がもっと便利になればいいねーくらいで話ししてんのに難癖つけられてもなー

**デフォルトの名無しさん** · 2017/05/25(木) 22:05:37.39

関数型のように値は一度割り当てたら変更不能というストリクトな仕様は
変数一つ一つに意味を考えて名前を付けるようになれるので見通しは良くなるね。
半面、ビギナーには辛いやり方だと思う。
変更できない物だけでどうやって変化していくものを表現するのか分からなくて途方にくれそうな絵が見える。
果たして吉とでるか凶とでるか？

**デフォルトの名無しさん** · 2017/05/25(木) 22:07:44.05

>>201
どっちも+2個だろー

**デフォルトの名無しさん** · 2017/05/25(木) 22:16:44.94

┏━ ╋╋
┗━ ╋╋

**デフォルトの名無しさん** · 2017/05/25(木) 23:36:14.82

>>206
C#は4つだろ

**デフォルトの名無しさん** · 2017/05/26(金) 00:05:23.61

やっぱメモリ管理は自動の方がいいですか？

**デフォルトの名無しさん** · 2017/05/26(金) 00:15:54.83

>>209
自動の方がいいと思うよ、安心感が全然違う。
ただ、マークスイープはオブジェクト総数増大につれてパフォーマンスに問題が出始めている感じがする。
ガベコレはすべてのスレッドを止めないと始められないが、オブジェクト総数増大とともに停止時間がやばくなる。
極力、マークスイープ以外の方法で回収できる感じにした方が良いかもしれないと最近は思う。

**デフォルトの名無しさん** · 2017/05/26(金) 00:29:53.59

>>196
思い込みで変なことを語る前に今のGCについて勉強した方がいいのでは
殆どのオブジェクトはマークアンドスイープ「ではない」GCによって回収されるんだぜ

**デフォルトの名無しさん** · 2017/05/26(金) 00:33:29.03

>>210
少なくともC#では、スタック周りだけでしょう。
シンプルな世代別ガベコレで実装されていると思われます。
C#ではC++のスマートポインタのようにスコープ抜けた瞬間に回収される所は見ないです。
それでは解決しきらないというのが自分の環境では起こり始めつつある。

**デフォルトの名無しさん** · 2017/05/26(金) 00:38:57.52

まぁ、C#の場合すべて強参照状態なんで参照カウンタで実装したところで
よほど意識してくれないかぎり有効に機能してくれない可能性は現状では高いですね。
特にevent回りとasync/await/Task回りに言えます。

**デフォルトの名無しさん** · 2017/05/26(金) 00:40:01.31

>>212
余計な工夫でmidlife crisis起こしてそうw
オブジェクトはすぐに使い捨てたほうがGCの負担になりにくいんだよ

**デフォルトの名無しさん** · 2017/05/26(金) 00:43:15.17

>>214
規模が小さいなら、使い捨てても使い捨てなくても、もともとパフォーマンスが問題になる事はないんですよ。
パフォーマンスが問題になるほど規模が大きくなっているので負担が大きいのは必然なんです。
トートロジーみたいな議論だからその反論は無意味。

**デフォルトの名無しさん** · 2017/05/26(金) 02:06:01.59

>>204
自分で言ったことを知らないって無茶苦茶だな
というか、そもそもC++のconstって肯定的に語る人はほとんどいないよ。

**デフォルトの名無しさん** · 2017/05/26(金) 03:47:01.99

>>216
え？金も出ないのに次期言語仕様のドラフト上げろっていうの？
君がどれくらいの人にアンケート取って肯定的な人が居ないと言ってるのか知らんが逆に否定的な人はどうなの？
肯定的な人が居ないのはそもそもちゃんと使ってる人が少ないからってだけでは？
assertionとかもそうだけど無くても問題もないものは当然初心者向けサイトでは扱われず使用者も少なくなりがち
ちなみにconst c# c++ってググれば検索上位は似たような内容が国内外含め結構出てくるよ

**デフォルトの名無しさん** · 2017/05/26(金) 09:30:04.80

C++を肯定的な奴少ないが使ってるのは多い。置き換えきれる言語がないんだよ

**デフォルトの名無しさん** · 2017/05/26(金) 11:01:05.91

constは地獄でしょ

**デフォルトの名無しさん** · 2017/05/26(金) 11:41:49.76

>>218
いい得てるわw

**デフォルトの名無しさん** · 2017/05/26(金) 13:10:14.69

c#でポインタが使えれば俺はc++はもういらない。

**デフォルトの名無しさん** · 2017/05/26(金) 17:16:27.99

メモリ管理はRustのゼロコストGC(正確にはGCじゃないけど)に期待してる

>>221
っunsafe

**デフォルトの名無しさん** · 2017/05/26(金) 18:58:46.42

>>221
使えるよ

**デフォルトの名無しさん** · 2017/05/26(金) 19:35:43.26

パフォーマンスを上げるのに
new するときにどの世代のメモりに生成するか指定できると便利になりそうな気がする
明らかに長期生存が分かっているオブジェクトを若いからというだけでガベコレに晒すのは無駄なんだが、現状無差別でしか生成できない。
アプリケーション終了時点まで消えてなくなることが無いと分かっているオブジェクトに至っては、生成直後に管理から外してもらえると良いんだけど。

**デフォルトの名無しさん** · 2017/05/26(金) 19:47:07.58

>>219
天国だよ
特にラムダ式とかローカル関数では、コピーとキャプチャを区別しなくてよくなる。
というかキャプチャとか考えたやつ、もうちょっとマシな方法思いつかんかったんかよって思う。
どのスコープの物なのか判りにくくてバグの温床
C++みたいに、キャプチャかコピーか明示できるようにして欲しかった。

**デフォルトの名無しさん** · 2017/05/26(金) 20:08:39.93

キャプチャーがそんなに分かりづらいとは思わんけどな

**デフォルトの名無しさん** · 2017/05/26(金) 20:11:40.53

>>226
もしそうだったら、何時ぞのバージョンアップの準破壊的変更で
foreach(var item in xxx) のitemのスコープを変えたりとか苦しい羽目にはならなかったろうよw

**デフォルトの名無しさん** · 2017/05/26(金) 20:15:07.40

>>227
それキャプチャーの問題じゃないでしょ
ループ変数のスコープの問題

**デフォルトの名無しさん** · 2017/05/26(金) 20:16:06.09

>>228
何言ってんだよ、キャプチャがなければ何の問題もない話だろw

**デフォルトの名無しさん** · 2017/05/26(金) 20:16:55.50

よく分からん思考回路だな...

**デフォルトの名無しさん** · 2017/05/26(金) 20:18:42.55

>>230
お前が、トラブルにあったことが無い程度にしかプログラムしていない初心者だからだよw

**デフォルトの名無しさん** · 2017/05/26(金) 20:21:16.22

言っても無駄だと思うけど、だからそれはキャプチャーの仕様が
トリッキーでミスリーディングだから起こる問題じゃありません。

foreachのループ変数のスコープがプログラマの予想を裏切るものだから起こる問題です

**デフォルトの名無しさん** · 2017/05/26(金) 20:33:16.54

結局、C#のEqualsやキャプチャとかが分かりにくくなってしまったのは
利用者から見て隠すべきでない物を隠してしまった所にあるんだろうな

operator == のオーバーロードも、C++ならポインタと実態の違いをプログラマが
. と -> の違いとしてしっかり認識しながらプログラムしている。問題なんか見たことない。
だから、C++のプログラムをしていた自分はJava屋が指摘する == のオーバーロードの危険性について
そんなの気にしすぎと軽視していたんだよな、ところが実際にはヤバかった。

C++プログラマは、ポインタとして利用しているオブジェクトには、ポインタらしい == のオーバーロードを
実体に対しての == は、実体を比較する為のオーバーロードをいつも意識している。
C#は、参照(意味的にはポインタ)を、実体の比較としてオーバーロードしようとしてしまう。意識していないからね。
このあたりが齟齬の発生地点のような気がする。
というかC#はじめて、やらかした。
どころか、標準の string からしてやらかしている。

C++では、ラムダ式でもしっかりと意識したコードができるようになっている。
次の問題は async /await だ、あれも隠してはいけない物の代表格、バグの温床だね。
C#の設計陣、そろそろ学習しろよって思うのであるがw

**デフォルトの名無しさん** · 2017/05/26(金) 20:51:46.15

ああ、昨日の人か

==のオーバーロードが危険とはまったく思わないし、等号という記号のイメージに
そった定義で可能なことは自然で当然のこと

問題があるとすれば、むしろオーバーロードしなくても使えてしまうことだろう。
昨日も書いたけど、VBのようにオーバーロードしないと使えない仕様の方が好ましかった

**デフォルトの名無しさん** · 2017/05/26(金) 21:36:33.37

マップキーに使える値型は==を上書きする
それ以外はデフォルトのまま参照の比較
これで困ったことはないな
強いていうなら決まり切った形式の実装がめんどくさいことか

**デフォルトの名無しさん** · 2017/05/27(土) 20:08:35.61

そういや空の自作構造体をhashset辺りに入れるとどうなるの？

**デフォルトの名無しさん** · 2017/05/27(土) 20:26:33.27

>>236
.netのソース見るとnon-staticなフィールドのない値型のインスタンスは全部等価になるっぽい
試してないけど

**デフォルトの名無しさん** · 2017/05/27(土) 21:21:07.48

そうなんだ。比較時に例外飛ばすと思ってたよ。

**デフォルトの名無しさん** · 2017/05/27(土) 21:22:20.09

質問する前に試せよ