C#, C♯, C＃相談室 P ..
71:デフォルトの名無しさん
17/05/17 21:02:34.01 rHqwwCfA.net
最近はNuGetもかなり充実したけどJavaにはさすがに到底敵わない
72:デフォルトの名無しさん
17/05/17 21:28:20.78 Lj2qZJuK.net
>>67
なんでNuGetとJava比べてんの？
73:デフォルトの名無しさん
17/05/17 21:49:09.74 OvRO5BGY.net
>>67
これは恥ずかしい
74:67
17/05/17 23:19:09.78 SKu/yZ4u.net
なんで叩かれてるのか知らないけど、Mavenリポジトリと言えば満足?
75:デフォルトの名無しさん
17/05/18 00:04:10.18 JYcaMM6T.net
web系の自動化ツール充実度に嫉妬
76:デフォルトの名無しさん
17/05/18 03:52:39.26 nv0hNXKv.net
>>70
具体的に
77:デフォルトの名無しさん
17/05/18 06:54:17.24 Zif2rhHO.net
>>71
Web系はやっつけだろうが早くリリースするのが至上命題だからテストを自動化しないとカオスになる
78:デフォルトの名無しさん
17/05/19 23:40:22.50 K2XF16mV.net
クラスのメンバー�
79:ﾌ型を動的に変更するなどは可能ですか？ 例えばMyClassのメンバーに public string name { get; set; } が有るとして、それを一時的に public List<string> name { get; set; } に変えるなど可能ですか？
80:デフォルトの名無しさん
17/05/20 00:19:20.01 /WJez+wG.net
>>74
できない
何のためにそんなことをしたいのか
81:デフォルトの名無しさん
17/05/20 00:28:41.92 lbI4YU5N.net
public string|List<string> name { get; set; }
じゃ駄目？
82:デフォルトの名無しさん
17/05/20 00:44:05.60 I6OViHCS.net
>>74
そのメンバーに色々な型のデータを突っ込みたいなら dynamic 型を調べるがよろし
83:デフォルトの名無しさん
17/05/20 01:21:14.87 aMCzC0+r.net
>>76
ありがとうございました。うまく行きました。
こんな手法があるんですね。
84:デフォルトの名無しさん
17/05/20 02:50:37.33 /vBlyS11.net
え、なにそれは
85:デフォルトの名無しさん
17/05/20 03:36:45.84 XoWVmAv8.net
>>76
このテクニックなんか名前ついてるの？
86:デフォルトの名無しさん
17/05/20 04:31:41.03 DT+L3BmX.net
アンカーの付け間違い
87:デフォルトの名無しさん
17/05/20 06:41:31.55 hBo0eJTZ.net
コンパイル通らねーよｗ意味不明
88:デフォルトの名無しさん
17/05/20 10:23:12.61 wDlYVPvY.net
素直にgenerics使え
89:デフォルトの名無しさん
17/05/20 11:05:10.16 NUOkmiRN.net
nameとnamesの区別がついてないクソPG
90:デフォルトの名無しさん
17/05/20 11:05:32.94 lbI4YU5N.net
あっTypeScriptと勘違いしてた
C#じゃ出来なかったわ
すまん
91:デフォルトの名無しさん
17/05/20 11:08:01.58 NUOkmiRN.net
いつどこからアクセスするかわからないプロパティの型を可変にする意味は何？
実際バグ出したいだけだろ？
92:デフォルトの名無しさん
17/05/20 12:26:52.90 pKHKYg56.net
静的に型付けされてるメンバーを動的に変更することは出来ないに決まってるねw
逆に出来たら困る
なんか静的に型付けされているってことの意味が分からない人が時々いるよね
型Bと型Cの両方を受け入れるプロパティが欲しいならプロパティーの型を共通のベースクラスAにして、
プロパティの値はプログラマの責任で適切にキャストして使うしかない
あとはBとCの間で相互に暗黙変換できるようにするとか
93:デフォルトの名無しさん
17/05/20 12:28:59.33 Lw3rlvDI.net
初心者は制約があるより自由にかけるほうが良いと思う時期があるものさ
問題があった時にどこからでもさわれたほうが対処しやすいからフィールドは全部publicにしたほうがいいとかね
94:デフォルトの名無しさん
17/05/20 17:55:46.01 lhYW/664.net
ふらっとでやろう
95:デフォルトの名無しさん
17/05/20 22:16:05.31 tNlWtPh8.net
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 でも値を代入できるということでいいんでしょうか？
96:デフォルトの名無しさん
17/05/20 22:22:56.23 spqPzklw.net
いまいち言いたいことは分からんがそうだよ
97:デフォルトの名無しさん
17/05/20 22:49:49.46 tNlWtPh8.net
>>91
ありがとうございます。オーバーライドとbaseのことを調べてコード書いてたら
これでひっかかってたので助かりました。
98:デフォルトの名無しさん
17/05/20 23:36:54.63 PmwbqNDX.net
隠蔽した本人から隠蔽後のメンバーじゃなくて
隠蔽したはずのベースクラスのメンバーが見えるなら何のための隠蔽よww
まあでも、どうせ隠蔽なんてまず使わないw
俺が使ったのはたぶんWindows Formのコントロールをカスタマイズするときに
virtualになってないメンバーを苦し紛れになんちゃってオーバーライドする時ぐらいだ
99:デフォルトの名無しさん
17/05/20 23:56:17.91 /WJez+wG.net
隠蔽は後から他の奴が基底クラスに同一シグネチャのメンバを追加しやがったときに
派生クラスが壊れないようにするための仕様だよ
積極的に使うものではない
当時のMSは極度の互換性パラノイアに陥っていたため、C#はバージョニングに関しては異常に神経質設計されている
100:デフォルトの名無しさん
17/05/23 12:03:34.57 +V9bC4xn.net
ヌル許容のdatetimeだとyear関数とか使えないんですか？
入力必須じゃない項目なので困っています。
101:デフォルトの名無しさん
17/05/23 12:15:28.78 jI6oRZ6H.net
>>95
dt?.Year
102:デフォルトの名無しさん
17/05/23 12:17:58.62 F7+6VHDt.net
ヌル許容のdatetimeってわからない。．NETのは構造体なのに
103:デフォルトの名無しさん
17/05/23 12:21:51.82 3W0XlzKr.net
大分前からヌルが基本的に無いintとかにヌル入れられるヌル許容型ってのがあるが。。。
int? x = 123;
int? y = null;
104:デフォルトの名無しさん
17/05/23 13:22:43.56 edjbow2J.net
>>95
つかえるよ
コード間違えてないか？
105:デフォルトの名無しさん
17/05/23 14:04:03.15 A3vGR0ii.net
stringですら?付けてstring?にしようという時代に
細かいことをごちゃごちゃと
106:デフォルトの名無しさん
17/05/23 17:45:15.21 PJIONmxy.net
stringは参照型だから元からヌル許容してたのに、なぜヌル許容型をわざわざ？
浦島太郎で申し訳ないが説明頼む。
107:デフォルトの名無しさん
17/05/23 18:27:41.35 Ph34uzkO.net
>>101
URLﾘﾝｸ(github.com)
108:デフォルトの名無しさん
17/05/23 18:33:56.97 LMlAaHk/.net
URLﾘﾝｸ(gist.github.com)
これだろ
string?じゃなくて、nullを許容しないstring!を導入したらどうか?という話
stringをstring!に変換しようとしたときにコンパイラがnullチェックを入れればいいだけだから悪くないアイデアだとと思う
109:デフォルトの名無しさん
17/05/23 18:49:06.30 UZ2qE6DF.net
>>101
よく知らんけど、DateTimeとかDB側でNULL許容として扱われている値型を同等に扱うためじゃないのかね
じゃないとEFとか破綻しそう
110:デフォルトの名無しさん
17/05/23 18:52:36.71 yWN+qtCg.net
>>104
.Net1.0から実装されていて欲しかったけどな
つかDataSetっていうウンコがあったからNULL許容型の生まれが遅くなった可能性があるな
111:デフォルトの名無しさん
17/05/23 18:53:40.67 LMlAaHk/.net
>>104
そうじゃなくて逆にnon-nullableが欲しいというのが趣旨だよ
で102で紹介されてるstring?の案は「いっそ参照型もデフォルトでnull非許容にしようぜ」という超過激なトンデモ案
112:デフォルトの名無しさん
17/05/23 18:57:42.54 HT5KxiNP.net
是非そうすべきだ
113:デフォルトの名無しさん
17/05/23 19:06:32.73 X2XHKUCb.net
TypeScriptがそういう風に仕様変更されたけどさすがにC#には不可能でしょ
TypeScriptとは違って過去の資産があるし書捨てプロジェクトばかりじゃないんだから
やるならstring!しかないけど!だらけでソースが見苦しくなるのが難点だな
114:デフォルトの名無しさん
17/05/23 19:11:34.18 J4QCEXrr.net
URLﾘﾝｸ(www.infoq.com)
近いうちに実現するっぽいよね
こういうところがC#って凄い。
115:デフォルトの名無しさん
17/05/23 19:13:26.09 HT5KxiNP.net
いつまでもVBを引きずって瞑想していたMicrosoftとは思えないな
ヘジたんは偉大だ
116:デフォルトの名無しさん
17/05/23 19:19:42.67 QProx2es.net
>>96
ありがとうございました。
単純に理解不足で参照側に？をつけていないだけでした。
117:デフォルトの名無しさん
17/05/23 19:23:28.74 SHq3YOvL.net
またnullの話w
null非許容が欲しいなんて問題の原因を取り違えているだけであって、
そんなもの導入してもnull例外が初期化忘れに置き換わるだけだっていう
簡単な事実が分からんアホが多すぎで呆れるよ
118:デフォルトの名無しさん
17/05/23 19:25:29.82 5hEoQuZK.net
>>103
ありがとう。
逆なら納得だわ。
119:デフォルトの名無しさん
17/05/23 19:27:51.33 5hEoQuZK.net
>>112
そこまで単純化されたら大助かり。
120:デフォルトの名無しさん
17/05/23 20:14:30.69 AM37HZZ1.net
>>112
何言ってるのかわからん
初期化忘れって何よ
121:デフォルトの名無しさん
17/05/23 20:31:14.27 HT5KxiNP.net
またJavaに大きな差を付けてしまうな
あとはエコシステムも充実させてくれ
122:デフォルトの名無しさん
17/05/23 20:57:28.99 Swob9G4V.net
>>112
null結合演算子も超嫌ってたしね～君
123:デフォルトの名無しさん
17/05/23 21:35:09.71 SHq3YOvL.net
>>117
そっちは何も問題ない
124:デフォルトの名無しさん
17/05/23 21:48:39.96 VdgHftUV.net
varの話してもいいですか？
125:デフォルトの名無しさん
17/05/23 22:57:25.70 MQkBzlkR.net
命が惜しくないならどうぞ
126:デフォルトの名無しさん
17/05/24 02:20:31.18 IRME+Rk/.net
TypeScriptとかSwiftとかKotlinの先例があるのにnull非許容の意味が理解できない>>112 みたいのが社会の進歩を妨げてるんだよなぁ
nullの代わりに空文字を入れることになるみたいな意味不明なことを言ってるやつもいたし、英語の議論が読めないにしても他の言語の例ぐらいは確認してからしゃべってほしい
127:デフォルトの名無しさん
17/05/24 02:27:23.98 k5coCCFX.net
またしょうもないのが現れたな
意味も意図も理解できるが、意図した通りの機能は発揮しないと言ってるんだけど
だからその「先例」とやらで現に意図した通り間違って自分の足を撃たない機能を発揮してるのかと。
してやしねえよw
128:デフォルトの名無しさん
17/05/24 02:32:41.30 k5coCCFX.net
要するに、nullを許容することに起因する問題が存在するので
nullを許容しなければそれは解決するのだ、なんていうのはただの愚か者の錯覚であって、
そんなものは問題Aをより発見が困難な問題Bに置き換えることにしかならない
129:デフォルトの名無しさん
17/05/24 03:32:06.26 5B8IqCyj.net
nullが生まれた背景と現在のnullの問題点 ― null参照問題（前編）
URLﾘﾝｸ(www.buildinsider.net)
C#でのnull参照問題への取り組み ― null参照問題（後編）
URLﾘﾝｸ(www.buildinsider.net)
読もうな
130:デフォルトの名無しさん
17/05/24 04:54:25.97 f/qUGphe.net
nullpoを許容
131:デフォルトの名無しさん
17/05/24 05:52:55.01 SWY45HoB.net
ポインタじゃなくていいところでは(nullを許容しない)参照をつかう
C++では当たり前にやっていた事でその威力は皆が知っていた
C++から派生したC#やJavaがこれを捨て去った意味が逆にわからない
C#はあるべき姿に戻ろうとしているだけ
132:デフォルトの名無しさん
17/05/24 07:19:29.94 OFlbMgow.net
>>122-123
レス古事記乙
133:デフォルトの名無しさん
17/05/24 08:19:55.11 gnZYpDQN.net
Int f(int x) ならxで例えば小数の事を考えなくて済む。
同じく f(hogeClass y) でyがnullの可能性を
考えなくて済むならそのほうが良いだろう。
そう思わないならプログラマーは
早々にやめたほうが良いと思うの。
nullチェック忘れてヌルポだすコードを
量産するバカが減るのは助かる。
134:デフォルトの名無しさん
17/05/24 08:56:56.79 2RBb7Y8v.net
135:なんで馬鹿は馬鹿を説得しようとするんだろう？ 馬鹿は馬鹿なんだから自分が馬鹿だなんて認める分けねえだろ だからお前も馬鹿だと言うんだ 馬鹿は死ね
136:デフォルトの名無しさん
17/05/24 09:20:10.02 CWb9U0nP.net
>>128
少数のことを考えなくて済むように、nullがあった方が助かる場面もあるだろ
そう思ってないようなおまえは早々にやめたほうが良いと思うよ
137:デフォルトの名無しさん
17/05/24 09:38:54.50 dFpq1SmP.net
ついでにundefinedも導入してほしい
138:デフォルトの名無しさん
17/05/24 10:29:24.60 4XHCBZ7H.net
ぬるぽ
139:デフォルトの名無しさん
17/05/24 10:36:49.92 0w0qPph2.net
どうしてnull非許容型を導入するって話をnullの根絶なんて話に持っていこうとするんだろうね？
140:デフォルトの名無しさん
17/05/24 10:46:19.73 xvW9RZ2K.net
>>128
間違ってるよその発想
その発想って>>1254の記事にもあるけど、メソッドが引数にnullを受け入れる
確信もないのに意図してnullを渡すプログラマなんかいません。
nullを受け入れないメソッドにnullを渡してしまう事態が起こるのは、
バグによってプログラマの意図に反してそうなるからだよ。当たり前でしょ。
だからnull非許容型を導入したところで、「プログラマの意図の反して変数の能がnullであるバグ」が
「プログラマの意図に反して変数の値が不適切であるバグ」に置き換わるだけ。
そして後者は前者より発見が困難な分、悪性度はより高い。
こんな簡単なことが分からん奴ってアホだろほんっと。
141:デフォルトの名無しさん
17/05/24 11:09:16.07 PQqcAP89.net
>>133
一つより二つ覚える方が大変だろ
未開人だと三つ以上は沢山だぞ
そんなにプログラミングの要素を増やすな
覚えきれない
142:デフォルトの名無しさん
17/05/24 11:32:23.53 fJwJIEtw.net
変数がnullである は 変数が不適切である に含まれる
変数が不適切なケースのうち変数がnullであるケースを言語仕様として排除できるって話じゃないの？
確かにこのnullのケースを排除しても他に不適切なケースがある設計なら完璧な対策ではないだろうけど有用なケースも認められるなら検討の価値はあるんじゃないかな？
143:デフォルトの名無しさん
17/05/24 11:40:03.52 lmoDZ3Fc.net
>>134
意図してNull値を渡すつもりがないなら
Null値が入る可能性があることがコンパイル前に判明するほうが
あきらかに修正もしやすいだろ
なに言ってんだ
144:デフォルトの名無しさん
17/05/24 12:07:37.15 xvW9RZ2K.net
>>137
何を言ってるのか意味が分からんね
145:デフォルトの名無しさん
17/05/24 12:11:17.02 QZczTL/V.net
>>138
お前がな
146:デフォルトの名無しさん
17/05/24 12:23:14.46 Em+sDdPu.net
全部Object型でやってろってのと変わらんがな
147:デフォルトの名無しさん
17/05/24 12:55:24.52 cF0VKHZde
Linux上でC#を使ってAndroid開発って出来ますかね？
今までC/C++やJavaでやってきたのですが、
C#で上記が可能ならC#に移行したいなと考えてまして。
148:デフォルトの名無しさん
17/05/24 15:17:32.97 IRME+Rk/.net
>>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);
149:デフォルトの名無しさん
17/05/24 15:28:42.02 9Gf4SnqN.net
実行時例外でるならそれでいいじゃんｗ
150:デフォルトの名無しさん
17/05/24 15:34:09.87 xvW9RZ2K.net
>>142
具体的で
151:素晴らしい 確かにその例で示されているような「nullの考慮忘れ」を防ぐ一定の効果は 期待できることは認める。 でもそれ、よく考えると机上の空論でしょ。 普通のプログラマならある変数やコレクションが仕様上nullを持ちうるかどうかは 常に気にしながらコーディングするので、そこに例示されている「nullの考慮忘れ」は 実際にはそんなにありがちな問題ではないと思う。 ありがちなのは、その例でいえばリストに値を入れる段階で プログラマの意図に反してnullが混入する問題だよね。
152:デフォルトの名無しさん
17/05/24 15:55:01.74 fJwJIEtw.net
実行されるまで気づかないならインタプリタと一緒じゃん
153:デフォルトの名無しさん
17/05/24 16:07:24.68 IRME+Rk/.net
>>144
＞ありがちな問題ではない
ありがちかどうかではなく、その機能を導入するメリットとデメリットの釣り合い。
エラーが未然に防げたり、記述が簡潔で見やすくなるならメリット。
文法が複雑になったり、別のバグの原因になったり、動作が遅くなったり、実装に手間がかかるならデメリット。
現状は「新バージョンではnull許容はstring?にしろよ」から「文法は変更せずフロー解析でどうにかしようぜ」までいろんなアイデアがある
個人的には、標準ライブラリの頭nullチェックをしてArgumentNullExceptionを出すようにしているところがいらなくなってライブラリ作者にはメリットがデカそうかなとはおもってる
null入れてArgumentNullExceptionがでるテストも書かなくて良くなる
154:デフォルトの名無しさん
17/05/24 16:22:43.45 IRME+Rk/.net
>>144
>リストに値を入れる段階でプログラマの意図に反して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比較のコストが入ってるけど、俺の知識が浅いだけなのでもっとうまいやり方も多分あると思う
155:デフォルトの名無しさん
17/05/24 17:14:59.24 rw+7fc+A.net
そうだねーPHPから出てこないでね
156:デフォルトの名無しさん
17/05/24 18:01:59.69 9Gf4SnqN.net
null許容にするメリットを実感できないんだろうな
157:デフォルトの名無しさん
17/05/24 19:54:58.94 wmLMN2ht.net
使えとは言ってないのにな
親でも殺されたか？
ゴミムシの親なんか区別がつかないだろうが
158:デフォルトの名無しさん
17/05/24 23:36:34.45 a2/m6a7T.net
>>147
コンパイル後の出力にnullチェックが入ってるってことは
string! aにnullが入る可能性が出来てしまうってこと！？
そこはコンパイルエラーにしてもらおうよ
>>142の
> ・nullの考慮忘れ
> ・過剰なnullチェック
> というのを防ぐのが目的
（＋テスト）
は、防ぐというより無くしたい
159:デフォルトの名無しさん
17/05/25 01:11:21.81 lqQtAs3j.net
>>151
nullチェックはNull許容型からNull非許容型にする際の話
nullの可能性があるならタイプマッチとかで消すほうが素直だけど、kotlinとかでは例外を投げる変換を用意してるみたい
修正されてない古いライブラリとかだとnullにはならないけどnull許容型みたいのが存在せざるを得ないので、そういう機能もほしい
160:ということじゃないかな
161:デフォルトの名無しさん
17/05/25 03:16:43.36 ezJU1k3U.net
今のところ超過激なトンデモ案が優勢なのかな？
採用されたら仕事が捗りそうなので、とても期待しているww
162:デフォルトの名無しさん
17/05/25 03:37:28.50 XcDeaOpm.net
null非許容型が追加されるならconstメソッドも
追加してほしいもんだ。
163:デフォルトの名無しさん
17/05/25 03:38:41.10 K8EeLAYg.net
いまだに2.0とか3.0やってる化石には全く関係のない話だから
足引っ張らないで欲しいわ
164:デフォルトの名無しさん
17/05/25 11:11:39.41 raX4nowj.net
Linqすら使えない自分の職場の悪口は止めてくれないか
165:デフォルトの名無しさん
17/05/25 11:17:54.20 TdXNYUaP.net
職場？お遊戯会の間違いだろ
166:デフォルトの名無しさん
17/05/25 11:41:19.09 OZ9w4Yf7.net
ロック問題で、価値ないつまらんネタ書いている奴こっち来い
適当にあしらってやるよ
167:デフォルトの名無しさん
17/05/25 11:44:07.67 raX4nowj.net
>>158
向こうに行ってやれよw
168:デフォルトの名無しさん
17/05/25 11:50:35.84 OZ9w4Yf7.net
最近は、こっちではnull非許容ネタやってるのか・・・
これ導入されたらガベージコレクタの性能落ちたりしないかな
4G越えのでかいツリー構造とか作っていると、参照つなぎ替えだけで色々やばいことが起こるんだよな
できるかぎり、用のないフィールドに参照ぶら下げたくないと最近しつこくnull入れてたりするんだが。
あと、event関係、弱参照で全部作り直さないとヤバないかな。
Taskとかと相性悪くて簡単にメモリーリーク起こすし、 WeakEventManagerでWPFは変態回避してただでさえコード変態状態だし。
VMごと作り直さないと色々噴き出しそうだ
169:デフォルトの名無しさん
17/05/25 11:51:39.74 OZ9w4Yf7.net
>>159
ここはキチガイの建てたゴミ箱、ちょうどいいんだよ。
170:デフォルトの名無しさん
17/05/25 12:35:35.78 KYr+IXo2.net
>>160
そんな場合はnull許容型を今迄通り使えばよろし
171:デフォルトの名無しさん
17/05/25 12:39:51.97 doyjLZp2.net
なんで択一の考えしか出来ないんだろうな
頭悪いのか？
頭悪いならゴミ回収みたいなルーチンワークしてろよ
172:デフォルトの名無しさん
17/05/25 12:40:36.41 OZ9w4Yf7.net
>>162
統一性のないコードになりそうだw
ここまで破壊的変更をするなら同じVM上で動く別言語として全く新しく設計した方が良い気がしてきている。
C#と混合してプロジェクトに登録できるようにすればシームレスにつながると思う。
今のC#には、アクロバテックな予約語追加とかも増えてきているし、いろいろ限界が来ていると思うんだ。
173:デフォルトの名無しさん
17/05/25 13:22:25.50 OZ9w4Yf7.net
どうせならC#を改造するのではなく、新規言語にして、ここにあるパターンをサクっと言語仕様として実装してみてほしいな。
URLﾘﾝｸ(ja.wikipedia.org)(%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と交互に書くときに {} 忘れで判りにくいバクにならなくて済む。
174:デフォルトの名無しさん
17/05/25 13:37:43.42 Gj1BXJi/.net
>ID:OZ9w4Yf7
基地外こっちでも大暴れかwww
175:デフォルトの名無しさん
17/05/25 13:39:20.53 OZ9w4Yf7.net
>>166
ようキチガイ、ここは、お前が建てたスレだろ。
向こういくなや、あっちはマジ質問なんだから。
お前とは、ここで遊んでやる。
176:デフォルトの名無しさん
17/05/25 16:36:05.73 Wjjn5VOT.net
まじで基地外だからな・・・
177:デフォルトの名無しさん
17/05/25 17:37:12.65 KYr+IXo2.net
>>164
swiftもkotlinも同じ感じの仕様だから適切に使い分けられれば良いんでないのかな
それがスキルだし
178:デフォルトの名無しさん
17/05/25 18:24:15.44 6uvmeYQm.net
c#がもし最初から作り直せるとしたらどんなふうにする？
俺は
yield returnじゃなくてyieldにする
ジェネリックをsystemに入れる
179:デフォルトの名無しさん
17/05/25 18:31:48.41 ISg+EccP.net
取り敢えずintは64ビットでstringはnull無し
180:デフォルトの名無しさん
17/05/25 18:55:20.09 QWlkLrx5.net
switchのbreakは省略可能にする
181:デフォルトの名無しさん
17/05/25 18:57:08.84 yV0yCNuL.net
Nodeが快適すぎる
C#ってなんだったの？
182:デフォルトの名無しさん
17/05/25 18:57:54.98 6uvmeYQm.net
>>173
言語と動作環境比べられても…
183:デフォルトの名無しさん
17/05/25 19:21:56.48 KYr+IXo2.net
immutable保証の構文は欲しい
if forは文でなくて式でありたい
副作用隔離文法も欲しい
184:デフォルトの名無しさん
17/05/25 19:24:16.19 BYkVp2J8.net
ジャップなんて99%素人に毛が生えたレベルなのに使い分けとか酷だ
185:デフォルトの名無しさん
17/05/25 19:36:21.23 6uvmeYQm.net
ダック・タイプの問題も最初からすっきり仕様作る
186:デフォルトの名無しさん
17/05/25 19:39:01.89 1nEgUyka.net
constとreadonlyの整理
c++のconstが好きだった
187:デフォルトの名無しさん
17/05/25 19:56:07.17 KYr+IXo2.net
デフォルトでconst
キーワード指定した時だけ非const
が良いなあ
188:デフォルトの名無しさん
17/05/25 20:07:38.18 ZdIAUNK0.net
何が嫌かと言えばVMだな。最初からネイティブコードコンパイラーならC++すら凌駕したかもしれん
189:デフォルトの名無しさん
17/05/25 20:09:09.51 lGDY6SHI.net
少なくともC#のconstとreadonlyは機能的に違うし、
どちらを無くされても困ると思うけど...
190:デフォルトの名無しさん
17/05/25 20:10:14.40 VSmfM+8N.net
>>173
フレームワークって知ってる？
191:デフォルトの名無しさん
17/05/25 20:18:46.47 6uvmeYQm.net
名前空間の分割をもっと簡素にする
今はusing増えすぎでめんどい
あと一ファイルに名前空間一つに限定で
ファイル先頭で指定、｛ ｝なしにする
namespace Hoge.Hoge :
これでwebからのコードのコピペが楽になる
192:デフォルトの名無しさん
17/05/25 20:24:26.30 vS0Oxp45.net
switch の最後の節の break は不要にする
ってかこれぐらいすぐやれ
毎回モヤモヤするんだよ
193:デフォルトの名無しさん
17/05/25 20:26:15.77 1nEgUyka.net
>>181
だから整理って書いたんだけど…
統合って意味じゃないよ
194:デフォルトの名無しさん
17/05/25 20:28:33.23 SU7CE5fr.net
readonlyは長すぎる
javaのfinalもだけど頼むから多用する奴は3文字以内にしてくれ
scalaなら定数も変数も同じ3文字だから揃って見やすいのに
195:デフォルトの名無しさん
17/05/25 20:29:42.51 lGDY6SHI.net
>>185
では整理とは具体的にどういう意味でしょう
196:デフォルトの名無しさん
17/05/25 20:33:29.10 OZ9w4Yf7.net
細かい機能系だと == オーバーロードが割と収集つかない感じなっているので
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が入り混じって混沌の世界と化している。
197:デフォルトの名無しさん
17/05/25 20:35:22.76 SU7CE5fr.net
>>188
トレイトがあれば自動実装出来るのにな…
198:デフォルトの名無しさん
17/05/25 20:37:17.55 yV0yCNuL.net
C++に回帰するのだ
199:デフォルトの名無しさん
17/05/25 20:42:49.06 OZ9w4Yf7.net
>>190
今のC#はまさにそこに向かっているので嫌なんだよね。
収集のつかない言語拡張、誰も知らない大量の構文と予約語で築かれた謎の言語仕様。
C++は、21世紀のCOBOLだ
200:デフォルトの名無しさん
17/05/25 20:44:09.62 6uvmeYQm.net
c++はほらバカには便利だろう見たいな新機能をいれてるけどそれすら使いこなしにくい
201:デフォルトの名無しさん
17/05/25 20:46:56.61 lm8UuBKM.net
型宣言は後置の方がいい
>>175
>immutable保証の構文
デフォルトでimmutableにして、
必要ならmutableに出来ればよくね
202:デフォルトの名無しさん
17/05/25 20:47:18.02 yV0yCNuL.net
C#が滅んでも困らないからいいや
node.jsがあれば安泰
203:デフォルトの名無しさん
17/05/25 21:04:38.19 dzSQ5kE9.net
>>189
キチガイに触るな
204:デフォルトの名無しさん
17/05/25 21:08:44.13 B4esX4Id.net
>>191
糖衣構文を要求したその口で「収集のつかない言語拡張」とか一体何の冗談？
205:デフォルトの名無しさん
17/05/25 21:10:56.06 OZ9w4Yf7.net
immutableを構文を作るのであれば、new でプール中にすでに同じ内容のオブジェクトが無いか調査して
既にあるならそちらを利用する仕組みも欲しいな。
これを利用する場合比較演算子EqualsとReferenceEqualsは同じ結果になるのでEqualsもGetHashCodeも自動実装の物でよい。
オブジェクトプールは、弱参照のHashSetで実装される事になると思うが、弱参照の先が死んでいた場合、HashSetの登録項目も整理できる。
ガベージコレクトと一緒にこれを整理できればより効率的だが、これは現状ライブラリベースで作る事は出来ない、VM側のサポートが必要。
これについては、メモリ管理にリファレンスカウンタを実装しても良いと思う、基本はリファレンスカウンタでマークスイープはゴールキーパーとして機能させる感じで。
206:デフォルトの名無しさん
17/05/25 21:11:49.39 lGDY6SHI.net
>>188
何言ってるのかよく分からうけどカオスを増加させるだけにしか思えんな
参照型の==がデフォで参照の比較になっているのが混乱の元だと言いたいならそこは同意する。
VBと同じように参照等価検査専用の演算子を用意して==はオーバーロードしない限り
使えないようにしてくれた方が分かりやすかったと思う
207:デフォルトの名無しさん
17/05/25 21:14:05.32 OZ9w4Yf7.net
>>196
お前みたいな馬鹿には分からないのですw
208:デフォルトの名無しさん
17/05/25 21:18:19.71 OZ9w4Yf7.net
>>198
オーバーロードしたらEqualsとの違いが不明確になる。
使う側にはそれはとても伝わりにくい。
だから==と書けばそれはEqualsの事であるという事にした方が簡潔だと思うよ。
比較は頻発するので毎回Equalsを書くのはさすがに面倒。
209:デフォルトの名無しさん
17/05/25 21:18:19.88 iDw56Z9j.net
c#とc++の違いが分からん
210:デフォルトの名無しさん
17/05/25 21:24:52.13 VSmfM+8N.net
>>201
+が2個多いだろ、よく眺めてみろ
211:デフォルトの名無しさん
17/05/25 21:27:49.57 SU7CE5fr.net
>>201
C++…うんこ
c#…B級グルメ
212:デフォルトの名無しさん
17/05/25 21:54:41.07 sQqbIl08.net
C#を食ったらケツからC++が出るのか
213:デフォルトの名無しさん
17/05/25 21:58:44.98 1nEgUyka.net
>>187
そんなん知らんよｗ
なんで具体的な提案なんかしなきゃならんのだ
2種もキーワードがあるのにc++のconstに比べて貧弱だなーって思っただけ
この部分がもっと便利になればいいねーくらいで話ししてんのに難癖つけられてもなー
214:デフォルトの名無しさん
17/05/25 22:05:37.39 OZ9w4Yf7.net
関数型のように値は一度割り当てたら変更不能というストリクトな仕様は
変数一つ一つに意味を考えて名前を付けるようになれるので見通しは良くなるね。
半面、ビギナーには辛いやり方だと思う。
変更できない物だけでどうやって変化していくものを表現するのか分からなくて途方にくれそうな絵が見える。
果たして吉とでるか凶とでるか？
215:デフォルトの名無しさん
17/05/25 22:07:44.05 06apVH37.net
>>202
どっちも+2個だろー
216:デフォルトの名無しさん
17/05/25 22:16:44.94 dzSQ5kE9.net
┏━ ╋╋
┗━ ╋╋
217:デフォルトの名無しさん
17/05/25 23:36:14.82 VSmfM+8N.net
>>207
C#は4つだろ
218:デフォルトの名無しさん
17/05/26 00:05:23.61 grHVRT/B.net
やっぱメモリ管理は自動の方がいいですか？
219:デフォルトの名無しさん
17/05/26 00:15:54.83 R9lW8EDm.net
>>210
自動の方がいいと思うよ、安心感が全然違う。
ただ、マークスイープはオブジェクト総数増大につれてパフォーマンスに問題が出始めている感じがする。
ガベコレはすべてのスレッドを止めないと始められないが、オブジェクト総数増大とともに停止時間がやばくなる。
極力、マークスイープ以外の方法で回収できる感じにした方が良いかもしれないと最近は思う。
220:デフォルトの名無しさん
17/05/26 00:29:53.59 4xYFMnBo.net
>>197
思い込みで変なことを語る前に今のGCについて勉強した方がいいのでは
殆どのオブジェクトはマークアンドスイープ「ではない」GCによって回収されるんだぜ
221:デフォルトの名無しさん
17/05/26 00:33:29.03 R9lW8EDm.net
>>211
少なくともC#では、スタック周りだけでしょう。
シンプルな世代別ガベコレで実装されていると思われます。
C#ではC++のスマートポインタのようにスコープ抜けた瞬間に回収される所は見ないです。
それでは解決しきらないというのが自分の環境では起こり始めつつある。
222:デフォルトの名無しさん
17/05/26 00:38:57.52 R9lW8EDm.net
まぁ、C#の場合すべて強参照状態なんで参照カウンタで実装したところで
よほど意識してくれないかぎり有効に機能してくれない可能性は現状では高いですね。
特にevent回りとasync/await/Task回りに言えます。
223:デフォルトの名無しさん
17/05/26 00:40:01.31 Mhihnqx0.net
>>213
余計な工夫でmidlife crisis起こしてそうw
オブジェクトはすぐに使い捨てたほうがGCの負担になりにくいんだよ
224:デフォルトの名無しさん
17/05/26 00:43:15.17 R9lW8EDm.net
>>215
規模が小さいなら、使い捨てても使い捨てなくても、もともとパフォーマンスが問題になる事はないんですよ。
パフォーマンスが問題になるほど規模が大きくなっているので負担が大きいのは必然なんです。
トートロジーみたいな議論だからその反論は無意味。
225:デフォルトの名無しさん
17/05/26 02:06:01.59 7MLVuo4L.net
>>205
自分で言ったことを知らないって無茶苦茶だな
というか、そもそもC++のconstって肯定的に語る人はほ�
226:ﾆんどいないよ。
227:デフォルトの名無しさん
17/05/26 03:47:01.99 jh4BS3n9.net
>>217
え？金も出ないのに次期言語仕様のドラフト上げろっていうの？
君がどれくらいの人にアンケート取って肯定的な人が居ないと言ってるのか知らんが逆に否定的な人はどうなの？
肯定的な人が居ないのはそもそもちゃんと使ってる人が少ないからってだけでは？
assertionとかもそうだけど無くても問題もないものは当然初心者向けサイトでは扱われず使用者も少なくなりがち
ちなみにconst c# c++ってググれば検索上位は似たような内容が国内外含め結構出てくるよ
228:デフォルトの名無しさん
17/05/26 09:30:04.80 g456XZgo.net
C++を肯定的な奴少ないが使ってるのは多い。置き換えきれる言語がないんだよ
229:デフォルトの名無しさん
17/05/26 11:01:05.91 2e/JbZY2.net
constは地獄でしょ
230:デフォルトの名無しさん
17/05/26 11:41:49.76 2utmFH39.net
>>219
いい得てるわw
231:デフォルトの名無しさん
17/05/26 13:10:14.69 V0QADimW.net
c#でポインタが使えれば俺はc++はもういらない。
232:デフォルトの名無しさん
17/05/26 17:16:27.99 Vk2AXjGC.net
メモリ管理はRustのゼロコストGC(正確にはGCじゃないけど)に期待してる
>>222
っunsafe
233:デフォルトの名無しさん
17/05/26 18:58:46.42 4GVMWdle.net
>>222
使えるよ
234:デフォルトの名無しさん
17/05/26 19:35:43.26 R9lW8EDm.net
パフォーマンスを上げるのに
new するときにどの世代のメモりに生成するか指定できると便利になりそうな気がする
明らかに長期生存が分かっているオブジェクトを若いからというだけでガベコレに晒すのは無駄なんだが、現状無差別でしか生成できない。
アプリケーション終了時点まで消えてなくなることが無いと分かっているオブジェクトに至っては、生成直後に管理から外してもらえると良いんだけど。
235:デフォルトの名無しさん
17/05/26 19:47:07.58 R9lW8EDm.net
>>220
天国だよ
特にラムダ式とかローカル関数では、コピーとキャプチャを区別しなくてよくなる。
というかキャプチャとか考えたやつ、もうちょっとマシな方法思いつかんかったんかよって思う。
どのスコープの物なのか判りにくくてバグの温床
C++みたいに、キャプチャかコピーか明示できるようにして欲しかった。
236:デフォルトの名無しさん
17/05/26 20:08:39.93 bEaQUHBT.net
キャプチャーがそんなに分かりづらいとは思わんけどな
237:デフォルトの名無しさん
17/05/26 20:11:40.53 R9lW8EDm.net
>>227
もしそうだったら、何時ぞのバージョンアップの準破壊的変更で
foreach(var item in xxx) のitemのスコープを変えたりとか苦しい羽目にはならなかったろうよw
238:デフォルトの名無しさん
17/05/26 20:15:07.40 bEaQUHBT.net
>>228
それキャプチャーの問題じゃないでしょ
ループ変数のスコープの問題
239:デフォルトの名無しさん
17/05/26 20:16:06.09 R9lW8EDm.net
>>229
何言ってんだよ、キャプチャがなければ何の問題もない話だろw
240:デフォルトの名無しさん
17/05/26 20:16:55.50 bEaQUHBT.net
よく分からん思考回路だな...
241:デフォルトの名無しさん
17/05/26 20:18:42.55 R9lW8EDm.net
>>231
お前が、トラブルにあったことが無い程度にしかプログラムしていない初心者だからだよw
242:デフォルトの名無しさん
17/05/26 20:21:16.22 bEaQUHBT.net
言っても無駄だと思うけど、だからそれはキャプチャーの仕様が
トリッキーでミスリーディングだから起こる問題じゃありません。
foreachのループ変数のスコープがプログラマの予想を裏切るものだから起こる問題です
243:デフォルトの名無しさん
17/05/26 20:33:16.54 R9lW8EDm.net
結局、C#のEqualsやキャプチャとかが分かりにくくなってしまったのは
利用者から見て隠すべきでない物を隠してしまった所にあるんだろうな
operator == のオーバーロードも、C++ならポインタと実態の違いをプログラマが
. と -> の違いとしてしっかり認識しながらプログラムしている。問題なんか見たことない。
だから、C++のプログラムをしていた自分はJava屋が指摘する == のオーバーロードの危険性について
そんなの気にしすぎと軽視していたんだよな、ところが実際にはヤバかった。
C++プログラマは、ポインタとして利用しているオブジェクトには、ポインタらしい == のオーバーロードを
実体に対しての == は、実体を比較する為のオーバーロードをいつも意識している。
C#は、参照(意味的にはポインタ)を、実体の比較としてオーバーロードしようとしてしまう。意識していないからね。
このあたりが齟齬の発生地点のような気がする。
というかC#はじめて、やらかした。
どころか、標準の string からしてやらかしている。
C++では、ラムダ式でもしっかりと意識したコードができるようになっている。
次の問題は async /await だ、あれも隠してはいけない物の代表格、バグの温床だね。
C#の設計陣、そろそろ学習しろよって思うのであるがw
244:デフォルトの名無しさん
17/05/26 20:51:46.15 bEaQUHBT.net
ああ、昨日の人か
==のオーバーロードが危険とはまったく思わないし、等号という記号のイメージに
そった定義で可能なことは自然で当然のこと
問題があるとすれば、むしろオーバーロードしなくても使えてしまうことだろう。
昨日も書いたけど、VBのようにオーバーロードしないと使えない仕様の方が好ましかった
245:デフォルトの名無しさん
17/05/26 21:36:33.37 Ym5et5f0.net
マップキーに使える値型は==を上書きする
それ以外はデフォルトのまま参照の比較
これで困ったことはないな
強いていうなら決まり切った形式の実装がめんどくさいことか
246:デフォルトの名無しさん
17/05/27 20:08:35.61 CUGuWQ0O.net
そういや空の自作構造体をhashset辺りに入れるとどうなるの？
247:デフォルトの名無しさん
17/05/27 20:26:33.27 TYkkRdMw.net
>>237
.netのソース見るとnon-staticなフィールドのない値型のインスタンスは全部等価になるっぽい
試してないけど
248:デフォルトの名無しさん
17/05/27 21:21:07.48 CUGuWQ0O.net
そうなんだ。比較時に例外飛ばすと思ってたよ。
249:デフォルトの名無しさん
17/05/27 21:22:20.09 6qDXI5sJ.net
質問する前に試せよ
250:デフォルトの名無しさん
17/05/27 22:01:52.68 pNqYSKN5.net
structの既定の比較は、かなり複雑な事やってる。
ポインターとか環境によって可変するフィールドや、アライメント関連で構造体中に隙間が無い場合に限ってmemcmpで高速比較する。
それ以外は、リフレクション使っての比較なのでパフォーマンスが大幅に落ちる。
なので、原則オーバーライドして使えという事を、昔C#が出始めたころにMSが言っていた。
自分は、いいかげん面倒くさいので、自分用は式ツリー使って比較とハッシュ計算の関数を自動生成してコンパイルした上で使っている。
既定の比較もこういうのを標準で作ってくれると面倒が無いし間違いもないんだが、などと思っている。
比較したいフィールドもしくはプロパティーに[EqualsTarget]というアトリビュートを付けたら、それで自動生成される感じ。
大小比較もこれで実装されるようにしてやった。
公開して、全員に使ってもらおうかどうか思案中、ちょと変態コードすぎるので気が引けてる。
251:デフォルトの名無しさん
17/05/27 22:27:07.42 9Ba3g3h0.net
初心者が頑張ってる感があって微笑ましい
252:デフォルトの名無しさん
17/05/28 00:28:08.62 v+RO0IME.net
スレチ感があるけど該当スレが分からずここで聞くんですが
Windows Formで背景色って灰色が初期値なのって何故でしょうか
253:デフォルトの名無しさん
17/05/28 00:31:20.09 X8MhB+Ic.net
Windowsを作ったマイクロソフトに聞け
254:デフォルトの名無しさん
17/05/28 02:09:41.98 0Vke4+SI.net
>>243
それ本来はOSの設定で変更可能なはずなんだけど。Win8以降コンパネで設定できなくなってるから
何だか訳分からんことになってるね
しかし、今触ってみて改めて思ったけどWin10のUIはウンコだな
Win7の時代の方がよほど分かりやすかった
誰が考えたらこんなカオスで使いづらいUIになるんだ
255:デフォルトの名無しさん
17/05/28 08:42:44.56 Q4IaIxAm.net
つか、元のコンセプトから見れば、灰色じゃなくて銀色のはずなんだけど
どう見てもねずみ色だね
256:デフォルトの名無しさん
17/05/28 10:16:19.73 LDH8CI3x.net
なぜグレーかというと、ハイライトと陰でウィジットを立体っぽく表現できたから。
だからフラットデザインではグレーにすり必然性はない。
257:デフォルトの名無しさん
17/05/28 10:30:30.28 BVKFrymy.net
開発用端末はMac、サーバーはLinux
最近はWindowsの出る幕がない
258:デフォルトの名無しさん
17/05/28 11:35:19.99 WRDHmffy.net
俺も最近は職場のPCでも開発はほとんどVirtalBox上のLinuxでスクリプト書いてる
たまにVS立ち上げる機会があるとクソ使いやすくて感動するけど、VS以外のWindowsは大嫌い
259:デフォルトの名無しさん
17/05/28 11:41:23.39 7TA+N736.net
>>249
VS でスクリプト書けばいいだけじゃん
260:デフォルトの名無しさん
17/05/28 12:42:49.19 U0KxOEQh.net
VSをLinuxやMac向けに売れば絶対儲かるやろ
for MacとかじゃなくてWin版と同じように使える奴
261:デフォルトの名無しさん
17/05/28 13:54:11.57 V1TJzJdZ.net
XCodeで心穏やかにプログラムを書ける奴を尊敬する
よほど精神修養したんだろうな
262:デフォルトの名無しさん
17/05/28 13:55:34.04 X8MhB+Ic.net
ユーザー数が
Win >>>> 越えられない壁 >>>> Mac
だから採算が取れる見込みが無けりゃ作らないよ
263:デフォルトの名無しさん
17/05/28 14:34:28.04 7TA+N736.net
そもそも VS で儲けるとか w
264:デフォルトの名無しさん
17/05/28 15:17:54.35 U0KxOEQh.net
>>253
開発者は
Mac>>>>>越えられない壁>>>>>Win
だろ
265:デフォルトの名無しさん
17/05/28 15:22:27.08 w6vv9NyD.net
>>255
vs for macで何か不満でも？
266:デフォルトの名無しさん
17/05/28 15:26:48.07 Q4IaIxAm.net
>>255
それはない
大企業の開発環境がMacとかあり得ん
267:デフォルトの名無しさん
17/05/28 15:27:43.83 X8MhB+Ic.net
>>255
もうちょっと現実見ようぜ
268:デフォルトの名無しさん
17/05/28 15:44:53.94 BVKFrymy.net
現実見た結果Macにたどり着いた
まあ三流企業は永久に窓でも使ってろってこった
269:デフォルトの名無しさん
17/05/28 15:46:59.96 V1TJzJdZ.net
winでもmacでも*nixでもストレスしか溜まらん
開発者向けの天国OS欲しいわ
270:デフォルトの名無しさん
17/05/28 15:58:51.29 Q4IaIxAm.net
三流企業というか弱小企業はMac使うんだろう
271:デフォルトの名無しさん
17/05/28 16:01:38.86 BVKFrymy.net
>>261
弱小企業は金がないから窓使うしかない
かわいそう
272:デフォルトの名無しさん
17/05/28 16:03:22.88 Q4IaIxAm.net
でかいビル丸ごと一棟開発の部署でほぼ全部windowsマシーンとか見たことないんだろう
273:デフォルトの名無しさん
17/05/28 16:05:30.06 lvl9gPaw.net
>>262
で、なんでお前みたいなカスがここにいるんだ？
274:デフォルトの名無しさん
17/05/28 16:08:15.24 Q4IaIxAm.net
国内でmacが1000台稼働してますなんてオフィス見たことも聞いたこともない
275:デフォルトの名無しさん
17/05/28 16:08:20.73 BVKFrymy.net
コスパならLinux
快適さならMac
思考停止するならWindows
276:デフォルトの名無しさん
17/05/28 16:08:28.50 LqX4nhhl.net
>>263
その光景に寒気を覚えない奴は実務未経験だろうな
277:デフォルトの名無しさん
17/05/28 16:34:01.56 5PeSitGp.net
visual studioとc#が最強すぎるから今
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
1628日前に更新/250 KB
担当:undef