ふらっと C#,C♯,C＃（初心者用） Part153

2021/12/13(月) 22:53:21.18

!extend:checked:vvvvv:1000:512
次スレを立てる時は↑を2行冒頭に書くこと（1行分は消えて表示されない為）

「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者、議論をしたいだけの人は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスや酔っぱらいレスはやめてください
>>980を踏んだ人は新スレを建てて下さい。>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。

■前スレ
ふらっと C#,C♯,C＃（初心者用） Part152
http://mevius.5ch.net/test/read.cgi/tech/1629888256/
■関連スレ
C#, C♯, C＃相談室 Part94
http://mevius.5ch.net/test/read.cgi/tech/1553075856/
■コードを貼る場合は↓を使いましょう。
https://ideone.com/
https://dotnetfiddle.net/
■情報源
https://docs.microsoft.com/ja-jp/dotnet/standard/class-libraries/
https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/
https://docs.microsoft.com/en-us/dotnet/standard/class-libraries/
https://referencesource.microsoft.com/
https://source.dot.net/
・Insider.NET > .NET TIPS - ＠IT
https://www.atmarkit.co.jp/ait/subtop/features/dotnet/dotnettips_index.html
・DOBON.NET　.NET Tips
https://dobon.net/vb/dotnet/index.html

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2022/01/04(火) 12:01:01.01

>>321から>>323ときてジャバスクとか後付感半端ないわ
こういうのとは仕事したくねーわw

2022/01/04(火) 12:07:12.39

>>323見たときに
var json =
こうあったとき、デコード後のclassが入ってることあったり、json stringが入ってたり、varやjsonなんて型や変数名だとわけわかんねーよ！
って話かと思ったら全然違った。なんだこの流れ・・・

2022/01/04(火) 12:11:24.66

これこれ。>>341 おれは一言もジャバスクなんて言ってないのにジャバスクの話にされて、
さらにはおれがジャバスクを後付したと妄信し、いきなり仕事したくないとかキチガイ妄想炸裂。
仕事先でこんなキチガイいたらガチで名誉毀損で訴えるわ。

これが型をスルーできる奴の脳の構造。リアルでアホだろ、こいつら…

2022/01/04(火) 12:12:43.55

※現在は削除されています
https://i.imgur.com/1WGlGRS.png

2022/01/04(火) 12:14:13.14

>>343
TypeScriptおすすめ

2022/01/04(火) 12:23:30.92

TypeScriptは型ヒント付きスクリプト言語にはよくあることだけど型が嘘をつけるので積極的に使わない方がいい
「型がついてるから安心だ」と思っていたら実行時に違う型の値が入っていることがよくある
なんなら生のJavaScriptの方が「型がないから全ての変数が信用できない」という前提に立てる分まだマシまである

2022/01/04(火) 12:29:36.62

>>346
それ言い出すとC++もreinterpret_cast多用で型の嘘つけるからなあ

2022/01/04(火) 12:42:28.79

>>347
まさにそれだね
cppは名前付きのキャストを使い分ける習慣が広まってるから状況は多少、マシ
TSにはanyとかいう負の遺産がある
それにJSはそれ自身ではできることが少ない言語なのでインフラapiコールに頼りがちだ
そこでanyを使いたくなくても多用するのでとにかく間違えやすい
自分がうっかり間違える可能性
チームメンバーが間違える可能性
ライブラリ作者が間違える可能性
とにかく間違いが起こりやすい
なのでTypeScriptは使わないほいがいい

2022/01/04(火) 12:53:18.36

・間違ったコールバックの型付け
・間違ったasの使用
・間違った.d.tsの使用
・間違ったユーザー定義タイプガード

TypeScriptで肩を間違える可能性があるのはこんなところかね。
まぁ、自分で使いこなせないものを使わない方がいいってのはその通りだが、
他人も同じように使いこなせないわけじゃないしな。

2022/01/04(火) 13:23:06.07

>>349
間違える余地が在ることが問題
特定の個人が使いこなせるこなせないという低次元な議論じゃない
型Aと書いたものが実際にはAでないという可能性が生じた時点であらゆるコードが信頼性を失い
その検証のために心労とコストが増えて
そして実際にバグが増える

C#では例えば「DateTimeと書いた変数に実際にはstringが入っているかもしれない」などと考えてコーディングする人は誰もいない
C#ではよほどのことがなければ基本的に型が嘘をつかないからそれで上手くいく
DateTimeと書かれたらそれはDateTimeであってstringであることを考慮する必要はない

しかしTypeScriptは違う
型は平気で嘘をつく
Date型と書いた変数が実際は文字列だろうが数値だろうがお構いなしだ

TypeScriptでは型が嘘をついていないことを確かめるには
その型が嘘をついている可能性があるという前提でバリデーションを追加するか
依存してるライブラリの内部の隅々までソースを追いかけるか
そういった対策をしなければならない
それはあまりにも非生産的だ

2022/01/04(火) 13:31:23.12

function ExternalLibFunc(): string

function example() {
const s: string = ExternalLibFunc();
if (typeof s === “string”)
throw new Error(“type errro”);
// do something
}

これが安全なTypeScriptコード
stringと宣言されたものを本当にstringかどうか確かめなければならない

この確認はバカバカしいと思うがやらなければバグを踏む可能性がある
でも全てを確認するなんて大変だ
だからみんな確認を怠る
そして実際にバグが発生する
そういう言語なんだTypeScriptってのは

2022/01/04(火) 14:02:28.93

Form1csにイベントがたくさんあるので行数が多くなってしまうのですが
部品ごとにファイルを分けてコードを書く方法を教えてください

2022/01/04(火) 15:10:27.49

>>352
メニューやツールバーみたいのがあったら
イベントハンドラの数が増えること自体は仕方ない。

行数が増えて困ることは目的の場所を探しにくくなることだから、
対策は#regionディレクティブをうまく使って分類することぐらい

2022/01/04(火) 15:15:26.98

>>352
partial class

2022/01/04(火) 15:40:55.02

>>352
void HogeEvent(object s, EventArgs e) {
//長いコード
}

↑これを
↓こうする

void HogeEvent(object s, EventArgs e) {
_hoge.DoSomething();
}

class Hoge {
public DoSomething() {
// 長いコード
}
}

2022/01/04(火) 16:14:54.64

>>350
そうは言ってもc#だってobjectや継承あるからな・・・

2022/01/04(火) 17:04:00.85

>>350
ネイティブ呼び始めたら嫌でもチェックせんか？
タグ付きユニオンとか使い始めたらどうせそうなるし。

2022/01/04(火) 17:29:19.72

なんだ動的型付け言語が嫌いなだけか

2022/01/04(火) 17:41:00.66

>>356
全く意味合いが異なる

2022/01/04(火) 17:42:21.35

>>357
本来バリデーションが必要がないところでバリデーションが必要になることが大問題

2022/01/04(火) 18:00:52.01

それはバリデーションじゃなくてバグのチェックだねw

2022/01/04(火) 18:24:36.74

そだね
TypeScriptdではそういうことも必要になってくる
言語上の欠陥なんだけどランタイムがJSだから永遠に解決しないだろうなこれ

2022/01/04(火) 18:24:37.24

>間違える余地が在ることが問題

完全無欠な言語以外は認められないと？

>型Aと書いたものが実際にはAでないという可能性が生じた時点であらゆるコードが信頼性を失い

どういう場合にそのようなことが起きるかがわかってないんだろうね。結局使いこなしの問題。

2022/01/04(火) 18:27:22.35

>>363
完全無欠な言語しか使わないとまでは言わない
ただ大きな欠陥のある言語は使いたくない
感覚としてはその程度だね

どういう場合に起こるか？
それはあらゆる場面で起こりうる
ライブラリすら信用できない

2022/01/04(火) 20:53:29.42

>>360
本来バリデーションは必要なのに必要じゃないと思い込んでるだけだろ。
カナリア置いたりした経験無さそう。

2022/01/04(火) 20:55:06.78

>>364
あるゆるは言い過ぎでは？
ほとんどの場合信頼境界を越えるからかと。

2022/01/04(火) 21:33:12.76

formsのchartを使ってるんだけど、20系列くらいを100ms以下でリアルタイム更新って厳しいのかな
色々試したけど更新にどうしても時間がかかる。。

2022/01/04(火) 21:37:51.18

>>365
c♯においてdatetime型の変数の中身がdatetime型以外である可能性があるの？
本来必要なバリデーションって何よ？

2022/01/04(火) 21:44:14.34

>>364
Cのポインタだって使い方を間違えたら正しい型を示さないことになるし、C自身も安全でない言語と見做される
こともあるが、それを分かったうえで正しく使う人はいるし実際広く使われている。そういうこと。

2022/01/04(火) 21:58:28.71

>>368
外部のAPIで1899年以前を扱いうる場合。

2022/01/04(火) 22:45:31.35

>>367
サードパーティ製のチャートを探すことをお勧め
詳しくないから具体的な名前は特に挙げられないけど
とりあえずScottPlotって名前を最近見かけたので試してみては
しかし20系列もあると読みづらそうだな

2022/01/04(火) 22:57:39.12

>>367
ただの折れ線グラフとかでビジュアル的に凝る必要がなければ
UserConrolから自分で作った方が早いかもね。

昔散々そういうのやってたけど、やってみると案外簡単だ。
WPFを選択するとパフォーマンス問題にぶち当たるから注意。

2022/01/04(火) 23:04:51.13

おすすめ本あります？
アマゾンで独習を見たのですが第４版は不評、第３版おすすめとなってたんですが
２０１０年出版っというのが引っかかっているので他を探しています。

スキルはPythonでPyGameのサンプルを打ち込みつつ、解説を見て勉強してるレベルです。
その他言語の経験はなし！

2022/01/04(火) 23:13:01.18

>>365
違う
本来バリデーションは必要ないのにTSでは(というか型がゆるゆるのスクリプト言語全般だが)余計なバリデーションが必要ということ

string x = func();
と書いた時にC#ではxが本当に文字列であることを検証する必要はない
nullになっていないか、文字列が特定の書式を満たしているか、といった心配はあるだろう
しかし、xにintが入ってる可能性は考慮する必要はない

TSではxにnumberが入っているかも、という可能性を考慮しなければならない
これが本来やらなくていいはずのバリデーションだ
これは型が嘘をつくから起こりうること
TSの代表的な欠陥の１つだ

2022/01/04(火) 23:14:48.44

>>369
詭弁
話を逸らすな

2022/01/04(火) 23:19:57.46

var x = func();
var y = x.func();
型が分からないとイライラくるよね。
スルーできる奴の脳みそってそれをすべて妄想で埋めてることが社会実験で実証された。

2022/01/04(火) 23:20:34.56

>型が嘘をつく

この言い回しをよっぽど気に入っているようだけどｗ当然TypeScriptが勝手に嘘をつくわけはなくて、
嘘をつかせたのはそれを使うプログラマ自身だわな

2022/01/04(火) 23:24:23.97

>>376
それはメソッド名が糞なだけだよ

**デフォルトの名無しさん** (ｽﾌｯ Sd62-XkW2) · 2022/01/04(火) 23:30:10.65

わざわざ宣言した行まで戻って型確認するのか

2022/01/04(火) 23:30:19.98

相変わらずコードが読めてもテンプレ読めない人が多いな

2022/01/04(火) 23:36:38.21

>>377
TSが勝手に嘘をつくことはないがC#と比べて嘘をつかせるように導くのに長けている
プログラマは世界中に沢山いてTSを使うと漏れなくその脅威に晒される
また彼らが作成したライブラリにも嘘が潜んでいるかもしれない

2022/01/04(火) 23:58:26.60

>>374
違わないよ。
全てTSの中であればNumberであることが担保されているのは、全てC#の中である場合と同程度に正しい。
C#の場合でも信頼境界を越えるのであればその可能性は考慮しないといけないし、TSの場合でも信頼境界を越えないのであれば気にする必要は無い。
ましてやTSというかJSはシングルスレッドなので別スレッドに壊される事も無い。

2022/01/05(水) 00:01:01.66

>>381
お前信頼境界って言葉一切ググらずに喋ってるだろ。
言われたことぐらい理解して反論してこいよ。

2022/01/05(水) 00:50:54.28

>>382
全てTSでも型が保証されない
最も簡単な事例は
const x: string = 100 as any
もちろんこんなコードを書く人はいないが
複雑で膨大なアプリケーションコードを扱うプロジェクトのなかで誰一人としてミスをしないかというと
そんな保証は全くなく型に嘘をつかれることになるだろう

2022/01/05(水) 00:51:02.44

>>383
ブーメラン

2022/01/05(水) 00:56:20.83

>>384
それはC#でも同じでしょ。

2022/01/05(水) 00:59:38.17

C#ではI/Oが生じる場合にも型が嘘をつくことはない
例えばこうだ

int x = Parse<int>(inputStream);

パースエラーにより実行時に例外が発生することはある
それはどの言語でも起こりうることだ
しかし、依然としてxにstringが入ったり、DateTimeが入ったり、という、TSでは普通にあり得る悍ましい挙動を示すことは無いのだ
なぜならC#はTSと違って型が嘘をつかないから
C#の型は信頼できる
TSの型は嘘つきで信頼できない

2022/01/05(水) 01:00:08.39

>>384
大規模アプリ開発では、何層もの見えない層があった結果これが起こる。
オブジェクトの型を破壊的に変換 - C#と諸々」でググってみ。

2022/01/05(水) 01:00:59.54

>>387
じゃあTSはどうしてxにStringやなにがしかが入るの？どこで入れてんのよ？w

2022/01/05(水) 01:10:21.43

>>386
全く異なる
C#ではdynamic、リフレクション、コード生成を使えばコンパイラの検証を回避して、間違った型の変数に値を設定できる
しかし、C#でこれをやると実行時にエラーになるのだ
TSで何事もなく処理が進むのとは、全く趣が異なる
そう、TSではstringと指定した筈の変数にnumberやDateの変数が入ったまま、何事もなく進んでしまうのだ
これは本当に恐ろしい挙動だ
つまり、バグを仕込んだところから、しばらく処理が進んだところで被害が顕現する、ということだ
これはまるで、潜伏期間の長いコロナウイルスのように厄介な特性だ
この挙動はC言語などではよくあるものだったが、原因と結果が離れているのでデバッグがしにくい、とのことで先人達は大いに苦しめられたものだ
まがりなりにも後発の言語であるTSが、大昔の言語設計と同じ失敗を繰り返しているのは残念でならない

2022/01/05(水) 01:17:22.12

>>388
低レベルなメモリアクセスでランタイムを破壊できるのはどの言語でも当たり前のことだろう
TSのように低レベルメモリアクセスでもなんでもない、ただの代入で型安全を破壊できるようなものと同列に扱うべきではない

2022/01/05(水) 01:19:07.95

>>389
困ったことにTSではどこででも起こりうる
だから欠陥言語なんだよ
C#のように低レベルメモリアクセスで無理やり破壊すればできるよ、といった次元とはわけがちがう

2022/01/05(水) 01:46:29.20

>>379
varの上にマウスカーソル合わせてツールチップに表示される型を見るだけ

2022/01/05(水) 07:33:07.78

>>384
既に>>349で挙げているがそこに注意してプログラミングすればいいだけ。
お前は馬鹿だからそれができないんだろうが世の中の人間がみなお前と同じように馬鹿なわけではない。

2022/01/05(水) 07:38:49.44

JSなんて使いたくて使ってるやつはいないって事だよ
ほかに選択肢がないから仕方なく使ってるだけで

そもそも本来TSのようなトランスパイラはこの世に存在し得ない存在

2022/01/05(水) 09:23:21.76

なんでc#スレで一生懸命TSの悪口言ってるの？

2022/01/05(水) 09:53:21.58

欠陥指摘できる俺すげー君だろw
スルーしとけ

2022/01/05(水) 09:57:56.22

WinFormのlistViewをタブレットで使いたいのですがlist部分を指で上下してlistをスクロールする事は出来るでしょうか
スクロールバーで上下出来るのですがスマホのように出来ないかなと

2022/01/05(水) 10:15:33.57

>>394
挙げられたリストでは全く足りない
こういう認識の甘さがバグを仕込むキッカケになるのだろう
そもそも人間は間違える余地があれば、いつか必ず間違える
注意してれば大丈夫、などという考え方では到底ダメだ

2022/01/05(水) 10:17:21.15

>>396
しつこく返してくる奴がいるから仕方なく付き合ってやってる
そいつがTSの型は安全でないという当たり前の事実を素直に受け入れれば俺もこんなレスバしなくても済むんだが

2022/01/05(水) 10:34:58.47

TypeScriptなしではJS開発やってられなくなってしまったな
特にチーム開発

2022/01/05(水) 11:00:24.24

>>398
一応標準でサポートされてるはずだけど
なんかスクロール遅いし慣性の扱いが下手糞だけど…

2022/01/05(水) 11:06:50.05

>>400
おまえは相手がうんと言うまでスレチ議論続けるつもりか

2022/01/05(水) 11:43:03.34

例えばリストビューを作るときにアイテムのTagに日時を代入しとく
そうしたら選択したアイテムの日時がすぐにわかるから。こんなのはよくやる手法だよね

で、実際にアイテムがクリックされたときにTagを読んで日時を取得しようとしたらstringだったりDateTimeだったりして型エラー。バリデーションｗが必要になる
こんなの（アホがプログラミングしたら）c#でも日常茶飯事だからな
tsでも同じ。アホがプログラミングしたらバリデーションｗは必須だし、普通にプログラミングしたら不要

2022/01/05(水) 11:54:44.06

>>404
君は議論の焦点を全く理解してないようだね

2022/01/05(水) 12:07:48.08

すまんが、昔、Linux + LLDBでのC#のデバッグ方法が公式サイトに書かれていたようが気がするんだけどさ
そんなようなページってどこにあるのか、誰か知ってたら教えて！！！

2022/01/05(水) 14:47:28.15

昔OSも乗ってない小規模組み込みをアセンブリでずっと書いてたけど、
アセンブリには当然型なんて概念そのものが存在しないが、
だからintとBCDを間違えたり、構造体のポインタを別の構造体のポインタと勘違いする
ミスが多いかと言うと、そこは意外とそうでもなかったりする。
それより生産性に対する影響の方が大きい印象だね。

まあこれは小規模かつ基本1人の開発だったからそうだっただけで、大規模かつチーム開発だと
話が変わってくるのかもしれない。
この辺はゲーム業界の人が詳しそうだね。
あの世界は下手したら90年代の終わり頃までアセンブリでやってたはず

2022/01/05(水) 15:04:40.06

バグには様々な要因があるから、不正な型が代入された場合だけを過度に心配してもね

2022/01/05(水) 15:08:39.22

型を気にしない馬鹿はテストも当然にしないから

2022/01/05(水) 15:14:15.12

>>384
自分が守らなければそりゃ保証もされないだろ。
C#ならある型にはある値しか入らないと思ってそう。

例えば構造体につっこんでFieldOffsetで上書きすればあっさり壊れるぞ。

[StructLayout(LayoutKind.Explicit)]
struct XXX {
　[FieldOffset(0)] public DateTime Value;
　[FieldOffset(0)] public ushort Tag;
}

でXXX.Tagに適当なもの入れたらValueは無茶苦茶になる。

2022/01/05(水) 15:54:13.43

参照型の変数にnullが入ってるかもしれないし、C#の場合は例外の型もドキュメントの記載を信じるしかないよね
結局は程度問題なんだよ
前者のnullの問題についてはnull許容参照型を使えば型として区別できるけど、null非許容だからといって絶対にnullが入らないわけではなく簡単にnullを混入させることができる
彼の大嫌いなTSと同じく、特にランタイムチェックのない紳士協定だ

2022/01/05(水) 16:24:00.16

っていうかこれたしか元はvarの話だよね。
繰り返しになるけど、元々の問題提起、つまり
「右辺の型が推測しづらいケースでもvarを使うのは不適切じゃないのか？」は正しいよ完全にw

匿名型を受ける場合以外のvarの目的は、「見れば分かる」冗長な繰り返しを避けて
シンプルにすること。

「かっこ悪い」みたいな中二病的動機で意地でも型を明示しないことに固執する奴はアホだが、
困ったことに現実にはそういうアホが結構いる。

この辺LINQの乱用が嫌われるのと同じなんだろうねw
シンプルにするための道具を使ってわざわざ難解にするバカw
たぶん彼はシンプルとは文字数が少ないことだと倒錯している

2022/01/05(水) 17:12:39.57

varの型が分からん分からんってこいつメモ帳で開発してんのか？

2022/01/05(水) 17:24:59.67

IDEだけでしかソース見ない奴は問題ないんだよ
ぐぐってブラウザ上で見るソースなんてマウスあてても型表示してくれないからな

2022/01/05(水) 17:28:23.80

どんだけ小さなプロジェクトしか関わったことないのか知らないが
code reviewするときに数百、数千というvarをおまえはいちいちマウス乗せてチェックしてるのか？

型を気にしないならオープンソースもコードを確認せずビルドして使うタイプだろう。
OSS品質=誰かがチェックしてくれるはず=テストしてない=今のMSのコード品質

2022/01/05(水) 17:32:31.52

var使ってるぐらいで崩壊するようなとこは大きいの作れないから気にする必要ないよｗ

2022/01/05(水) 17:43:11.47

varなんて大抵は右辺見たら型わかるやろ？
何が分からんのだ？

2022/01/05(水) 17:48:48.78

実験結果は分かった気になって実は全然分かってないでした。
でも分かった気になってるのでいつまでもなぜ分からないのだ？と問い続ける。

2022/01/05(水) 17:52:58.23

いやマジで何が分からんの？アホの子なの？

2022/01/05(水) 17:58:12.21

つか、変数名見ればクラス名も分かる程度にしておくのが普通だから
マウスで調べなくてもだいたい分かる

2022/01/05(水) 17:58:55.28

自演じゃないよ、彼はそう信じてるんだ。笑わないでほしい。

2022/01/05(水) 18:09:44.71

>>421
このスレの住人はお前のことを笑っているぞ

2022/01/05(水) 18:09:55.54

staticおじさんみたいなもんだな

2022/01/05(水) 18:21:06.82

そして彼は笑いながら未テスト納品を繰り返す。そしてまたスパコンのデータを吹き飛ばす。

2022/01/05(水) 18:39:16.92

コードレビュー時にローカル変数の型をいちいち調べる意味がよくわからん
必要になるのってバグの原因調査する時だけでしょ

2022/01/05(水) 18:41:30.05

TS、JSの型がゴミなのはわかる
c#のvarも俺は嫌い
普通に読みにくい

最近は派遣先会社のVSに仕込まれた強制変換スクリプト？で保存すると勝手にvarが明示的な型に置き換えられて
久しく見ない問題だったが

2022/01/05(水) 18:42:19.84

何も知らないなら喋らなきゃ無知はバレない。

2022/01/05(水) 19:07:10.79

>>425
人のソース読むのにvarで省略されてるよりも、型が使われてる方が理解しやすい
もちろん>>420のようにしてくれればvarでも変わりゃしないけど、世の中そういうソースばかりじゃないし酷いのになると名前で型を騙されることあるからな
整数型にn、floatにfついてるからdがついてたらdoubleかと思ったらそれも整数だったり。そりゃないだろ・・・

2022/01/05(水) 19:19:51.10

限度の問題では？
MSの規約にあわせれば良いでしょ。
IEnumerable<T>で受けるべきなのにList<T>で受けてるとかそういう不適切な状態になってない限りvarで良いと思うけどな。
varは省略の為に使うのではなくて推論の為に使うんよ。

2022/01/05(水) 19:53:56.06

varなんて右クリックメニューで元に戻せるから書くだけ書いたら明示的な記述に直しちゃった方がいいよ

2022/01/05(水) 19:57:59.86

>>429
推論はするよりしない方が脳への負担が低いはずなので、
君の説を採るとvarは全面禁止すべきという結論になってしまうよw

少なくともコードの読み手（書き手ではなく）にとってのvarのメリットは
右辺の型が分かりきっている時に左辺の方でもくどくどそれを繰り返される冗長さが回避されることだ。

2022/01/05(水) 20:04:49.66

型推論
https://ja.wikipedia.org/wiki/%E5%9E%8B%E6%8E%A8%E8%AB%96

2022/01/05(水) 20:09:49.34

書くやつは楽
コピペ盗作するやつは脳味噌が必要

var大勝利じゃん

2022/01/05(水) 20:11:27.06

>>432
そもそもこれがゴミなのか有効なのか？
って議論がなされないまま突然導入されてほら使えだからな
VSの右クリックメニューにもvarを元に戻す機能が付いたってことはあんまり評判よくないだろコレ

2022/01/05(水) 20:16:51.17

議論に参加できるぐらい出世しろ

2022/01/05(水) 20:20:48.72

>>435
お前の会社は社長が1番技術力高いのか？

2022/01/05(水) 20:41:21.39

varで推論しないほうが脳への負担が低いというのはどういうことですか？

2022/01/05(水) 20:42:40.80

>>437
型が分からなくてもイライラしない人はそもそも負担がありません。

2022/01/05(水) 21:00:44.67

アホが作った無意味なマトリョーシカクラス追わなくて済むからな

2022/01/05(水) 21:16:57.60

15年近く前から導入されてるものに対して
いまだに文句を言い続ける「熱量」には感心する

2022/01/05(水) 21:20:57.24

>>440
正直、クラスから嫌いです
構造体以上のメリットを全く感じたことない