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/04/26(水) 21:36:27.67

>>60
> ちなみにイントラネット上であれば開いたソケットはアプリを閉じない限りクローズする必要はないでしょうか
当然だけどリッスンポートは待ち受けで開いたまま
コネクトする側は必要なくなったら閉じるのが普通

**デフォルトの名無しさん** · 2017/04/27(木) 00:21:44.79

オブザーバー、発行・購読
中央管制塔ありのメディエイター
メッセージキュー

**デフォルトの名無しさん** · 2017/04/27(木) 07:42:43.29

>>61>>62
ありがとうございます
もう少しサンプルを調べて勉強してみます

**デフォルトの名無しさん** · 2017/05/06(土) 00:24:40.77

こっちか

**デフォルトの名無しさん** · 2017/05/17(水) 20:59:26.88

C#って言語とランタイムの性能はいいけどエコシステムが貧弱だな

**デフォルトの名無しさん** · 2017/05/17(水) 21:02:34.01

最近はNuGetもかなり充実したけどJavaにはさすがに到底敵わない

**デフォルトの名無しさん** · 2017/05/17(水) 21:28:20.78

>>67
なんでNuGetとJava比べてんの？

**デフォルトの名無しさん** · 2017/05/17(水) 21:49:09.74

>>67
これは恥ずかしい

67 · 2017/05/17(水) 23:19:09.78

なんで叩かれてるのか知らないけど、Mavenリポジトリと言えば満足?

**デフォルトの名無しさん** · 2017/05/18(木) 00:04:10.18

web系の自動化ツール充実度に嫉妬

**デフォルトの名無しさん** · 2017/05/18(木) 03:52:39.26

>>70
具体的に

**デフォルトの名無しさん** · 2017/05/18(木) 06:54:17.24

>>71
Web系はやっつけだろうが早くリリースするのが至上命題だからテストを自動化しないとカオスになる

**デフォルトの名無しさん** · 2017/05/19(金) 23:40:22.50

クラスのメンバーの型を動的に変更するなどは可能ですか？
例えばMyClassのメンバーに
public string name { get; set; }
が有るとして、それを一時的に
public List<string> name { get; set; }
に変えるなど可能ですか？

**デフォルトの名無しさん** · 2017/05/20(土) 00:19:20.01

>>74
できない
何のためにそんなことをしたいのか

**デフォルトの名無しさん** · 2017/05/20(土) 00:28:41.92

public string|List<string> name { get; set; }
じゃ駄目？

**デフォルトの名無しさん** · 2017/05/20(土) 00:44:05.60

>>74
そのメンバーに色々な型のデータを突っ込みたいなら dynamic 型を調べるがよろし

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

>>76
ありがとうございました。うまく行きました。
こんな手法があるんですね。

**デフォルトの名無しさん** · 2017/05/20(土) 02:50:37.33

え、なにそれは

**デフォルトの名無しさん** · 2017/05/20(土) 03:36:45.84

>>76
このテクニックなんか名前ついてるの？

**デフォルトの名無しさん** · 2017/05/20(土) 04:31:41.03

アンカーの付け間違い

**デフォルトの名無しさん** · 2017/05/20(土) 06:41:31.55

コンパイル通らねーよｗ意味不明

**デフォルトの名無しさん** · 2017/05/20(土) 10:23:12.61

素直にgenerics使え

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

nameとnamesの区別がついてないクソPG

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

あっTypeScriptと勘違いしてた
C#じゃ出来なかったわ
すまん

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

いつどこからアクセスするかわからないプロパティの型を可変にする意味は何？

実際バグ出したいだけだろ？

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

静的に型付けされてるメンバーを動的に変更することは出来ないに決まってるねw
逆に出来たら困る
なんか静的に型付けされているってことの意味が分からない人が時々いるよね

型Bと型Cの両方を受け入れるプロパティが欲しいならプロパティーの型を共通のベースクラスAにして、
プロパティの値はプログラマの責任で適切にキャストして使うしかない

あとはBとCの間で相互に暗黙変換できるようにするとか

**デフォルトの名無しさん** · 2017/05/20(土) 12:28:59.33

初心者は制約があるより自由にかけるほうが良いと思う時期があるものさ
問題があった時にどこからでもさわれたほうが対処しやすいからフィールドは全部publicにしたほうがいいとかね

**デフォルトの名無しさん** · 2017/05/20(土) 17:55:46.01

ふらっとでやろう

**デフォルトの名無しさん** · 2017/05/20(土) 22:16:05.31

class A
{
public int i;
public virtual void storeNumber(int arg){ i = arg; }
}
class B : A
{
public new int i;
public override void storeNumber(int arg) {
base.storeNumber(arg);
i = arg; }
}
A typeA = new B();
typeA.storeNumber(1);
System.Console.WriteLine(typeA.i); //1
B typeB = (B)typeA;
System.Console.WriteLine(typeB.i); //1
typeB.storeNumber(2);
System.Console.WriteLine(typeA.i); //2
System.Console.WriteLine(typeB.i); //2
new キーワードのメンバは変数の型で参照先が決まると書いてあったんですが
A型の変数から呼び出しても、オーバーライドしたクラスBのメソッドから代入すれば
new が付いてるint i でも値を代入できるということでいいんでしょうか？

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

いまいち言いたいことは分からんがそうだよ

**デフォルトの名無しさん** · 2017/05/20(土) 22:49:49.46

>>91
ありがとうございます。オーバーライドとbaseのことを調べてコード書いてたら
これでひっかかってたので助かりました。

**デフォルトの名無しさん** · 2017/05/20(土) 23:36:54.63

隠蔽した本人から隠蔽後のメンバーじゃなくて
隠蔽したはずのベースクラスのメンバーが見えるなら何のための隠蔽よww

まあでも、どうせ隠蔽なんてまず使わないw
俺が使ったのはたぶんWindows Formのコントロールをカスタマイズするときに
virtualになってないメンバーを苦し紛れになんちゃってオーバーライドする時ぐらいだ

**デフォルトの名無しさん** · 2017/05/20(土) 23:56:17.91

隠蔽は後から他の奴が基底クラスに同一シグネチャのメンバを追加しやがったときに
派生クラスが壊れないようにするための仕様だよ
積極的に使うものではない
当時のMSは極度の互換性パラノイアに陥っていたため、C#はバージョニングに関しては異常に神経質設計されている

**デフォルトの名無しさん** · 2017/05/23(火) 12:03:34.57

ヌル許容のdatetimeだとyear関数とか使えないんですか？
入力必須じゃない項目なので困っています。

**デフォルトの名無しさん** · 2017/05/23(火) 12:15:28.78

>>95
dt?.Year

**デフォルトの名無しさん** · 2017/05/23(火) 12:17:58.62

ヌル許容のdatetimeってわからない。．NETのは構造体なのに

**デフォルトの名無しさん** · 2017/05/23(火) 12:21:51.82

大分前からヌルが基本的に無いintとかにヌル入れられるヌル許容型ってのがあるが。。。

int? x = 123;
int? y = null;

**デフォルトの名無しさん** · 2017/05/23(火) 13:22:43.56

>>95
つかえるよ
コード間違えてないか？

**デフォルトの名無しさん** · 2017/05/23(火) 14:04:03.15

stringですら?付けてstring?にしようという時代に
細かいことをごちゃごちゃと

**デフォルトの名無しさん** · 2017/05/23(火) 17:45:15.21

stringは参照型だから元からヌル許容してたのに、なぜヌル許容型をわざわざ？
浦島太郎で申し訳ないが説明頼む。

**デフォルトの名無しさん** · 2017/05/23(火) 18:27:41.35

>>101
https://github.com/dotnet/csharplang/blob/master/proposals/nullable-reference-types.md

**デフォルトの名無しさん** · 2017/05/23(火) 18:33:56.97

https://gist.github.com/olmobrutall/31d2abafe0b21b017d56
これだろ
string?じゃなくて、nullを許容しないstring!を導入したらどうか?という話
stringをstring!に変換しようとしたときにコンパイラがnullチェックを入れればいいだけだから悪くないアイデアだとと思う

**デフォルトの名無しさん** · 2017/05/23(火) 18:49:06.30

>>101
よく知らんけど、DateTimeとかDB側でNULL許容として扱われている値型を同等に扱うためじゃないのかね
じゃないとEFとか破綻しそう

**デフォルトの名無しさん** · 2017/05/23(火) 18:52:36.71

>>104
.Net1.0から実装されていて欲しかったけどな
つかDataSetっていうウンコがあったからNULL許容型の生まれが遅くなった可能性があるな

**デフォルトの名無しさん** · 2017/05/23(火) 18:53:40.67

>>104
そうじゃなくて逆にnon-nullableが欲しいというのが趣旨だよ
で102で紹介されてるstring?の案は「いっそ参照型もデフォルトでnull非許容にしようぜ」という超過激なトンデモ案

**デフォルトの名無しさん** · 2017/05/23(火) 18:57:42.54

是非そうすべきだ

**デフォルトの名無しさん** · 2017/05/23(火) 19:06:32.73

TypeScriptがそういう風に仕様変更されたけどさすがにC#には不可能でしょ
TypeScriptとは違って過去の資産があるし書捨てプロジェクトばかりじゃないんだから
やるならstring!しかないけど!だらけでソースが見苦しくなるのが難点だな

**デフォルトの名無しさん** · 2017/05/23(火) 19:11:34.18

https://www.infoq.com/jp/news/2017/04/CSharp-Nullable
近いうちに実現するっぽいよね
こういうところがC#って凄い。

**デフォルトの名無しさん** · 2017/05/23(火) 19:13:26.09

いつまでもVBを引きずって瞑想していたMicrosoftとは思えないな
ヘジたんは偉大だ

**デフォルトの名無しさん** · 2017/05/23(火) 19:19:42.67

>>96
ありがとうございました。
単純に理解不足で参照側に？をつけていないだけでした。

**デフォルトの名無しさん** · 2017/05/23(火) 19:23:28.74

またnullの話w

null非許容が欲しいなんて問題の原因を取り違えているだけであって、
そんなもの導入してもnull例外が初期化忘れに置き換わるだけだっていう
簡単な事実が分からんアホが多すぎで呆れるよ

**デフォルトの名無しさん** · 2017/05/23(火) 19:25:29.82

>>103
ありがとう。
逆なら納得だわ。

**デフォルトの名無しさん** · 2017/05/23(火) 19:27:51.33

>>112
そこまで単純化されたら大助かり。

**デフォルトの名無しさん** · 2017/05/23(火) 20:14:30.69

>>112
何言ってるのかわからん
初期化忘れって何よ

**デフォルトの名無しさん** · 2017/05/23(火) 20:31:14.27

またJavaに大きな差を付けてしまうな
あとはエコシステムも充実させてくれ

**デフォルトの名無しさん** · 2017/05/23(火) 20:57:28.99

>>112
null結合演算子も超嫌ってたしね～君

**デフォルトの名無しさん** · 2017/05/23(火) 21:35:09.71

>>117
そっちは何も問題ない

**デフォルトの名無しさん** · 2017/05/23(火) 21:48:39.96

varの話してもいいですか？

**デフォルトの名無しさん** · 2017/05/23(火) 22:57:25.70

命が惜しくないならどうぞ

**デフォルトの名無しさん** · 2017/05/24(水) 02:20:31.18

TypeScriptとかSwiftとかKotlinの先例があるのにnull非許容の意味が理解できない>>112　みたいのが社会の進歩を妨げてるんだよなぁ
nullの代わりに空文字を入れることになるみたいな意味不明なことを言ってるやつもいたし、英語の議論が読めないにしても他の言語の例ぐらいは確認してからしゃべってほしい

**デフォルトの名無しさん** · 2017/05/24(水) 02:27:23.98

またしょうもないのが現れたな
意味も意図も理解できるが、意図した通りの機能は発揮しないと言ってるんだけど

だからその「先例」とやらで現に意図した通り間違って自分の足を撃たない機能を発揮してるのかと。
してやしねえよw

**デフォルトの名無しさん** · 2017/05/24(水) 02:32:41.30

要するに、nullを許容することに起因する問題が存在するので
nullを許容しなければそれは解決するのだ、なんていうのはただの愚か者の錯覚であって、
そんなものは問題Aをより発見が困難な問題Bに置き換えることにしかならない

**デフォルトの名無しさん** · 2017/05/24(水) 03:32:06.26

nullが生まれた背景と現在のnullの問題点 ― null参照問題（前編）
http://www.buildinsider.net/column/iwanaga-nobuyuki/011
C#でのnull参照問題への取り組み ― null参照問題（後編）
http://www.buildinsider.net/column/iwanaga-nobuyuki/012

読もうな

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

nullpoを許容

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

ポインタじゃなくていいところでは(nullを許容しない)参照をつかう
C++では当たり前にやっていた事でその威力は皆が知っていた
C++から派生したC#やJavaがこれを捨て去った意味が逆にわからない
C#はあるべき姿に戻ろうとしているだけ

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

>>122-123
レス古事記乙

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

Int f(int x) ならxで例えば小数の事を考えなくて済む。
同じく f(hogeClass y) でyがnullの可能性を
考えなくて済むならそのほうが良いだろう。

そう思わないならプログラマーは
早々にやめたほうが良いと思うの。
nullチェック忘れてヌルポだすコードを
量産するバカが減るのは助かる。

**デフォルトの名無しさん** · 2017/05/24(水) 08:56:56.79

なんで馬鹿は馬鹿を説得しようとするんだろう？
馬鹿は馬鹿なんだから自分が馬鹿だなんて認める分けねえだろ
だからお前も馬鹿だと言うんだ

馬鹿は死ね

**デフォルトの名無しさん** · 2017/05/24(水) 09:20:10.02

>>128
少数のことを考えなくて済むように、nullがあった方が助かる場面もあるだろ
そう思ってないようなおまえは早々にやめたほうが良いと思うよ

**デフォルトの名無しさん** · 2017/05/24(水) 09:38:54.50

ついでにundefinedも導入してほしい

**デフォルトの名無しさん** · 2017/05/24(水) 10:29:24.60

ぬるぽ

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

どうしてnull非許容型を導入するって話をnullの根絶なんて話に持っていこうとするんだろうね？

**デフォルトの名無しさん** · 2017/05/24(水) 10:46:19.73

>>128
間違ってるよその発想
その発想って>>1254の記事にもあるけど、メソッドが引数にnullを受け入れる
確信もないのに意図してnullを渡すプログラマなんかいません。

nullを受け入れないメソッドにnullを渡してしまう事態が起こるのは、
バグによってプログラマの意図に反してそうなるからだよ。当たり前でしょ。

だからnull非許容型を導入したところで、「プログラマの意図の反して変数の能がnullであるバグ」が
「プログラマの意図に反して変数の値が不適切であるバグ」に置き換わるだけ。

そして後者は前者より発見が困難な分、悪性度はより高い。
こんな簡単なことが分からん奴ってアホだろほんっと。

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

>>133
一つより二つ覚える方が大変だろ
未開人だと三つ以上は沢山だぞ
そんなにプログラミングの要素を増やすな
覚えきれない

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

変数がnullである　は　変数が不適切である　に含まれる
変数が不適切なケースのうち変数がnullであるケースを言語仕様として排除できるって話じゃないの？
確かにこのnullのケースを排除しても他に不適切なケースがある設計なら完璧な対策ではないだろうけど有用なケースも認められるなら検討の価値はあるんじゃないかな？

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

>>134
意図してNull値を渡すつもりがないなら
Null値が入る可能性があることがコンパイル前に判明するほうが
あきらかに修正もしやすいだろ
なに言ってんだ

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

>>137
何を言ってるのか意味が分からんね

**デフォルトの名無しさん** · 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許容型を今迄通り使えばよろし