C#, C♯, C＃相談室 Part93©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/
■コードを貼る場合はこちら
http://ideone.com/
■前スレ
C#, C♯, C＃相談室 Part92
http://echo.2ch.net/test/read.cgi/tech/1485589613/
■次スレは>>970が建てる事。
建てられない場合は他を指定する事。
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured >>354
さっぱりわからない
処理変えたくないメソッド実行
↓
その結果次第で別のメソッド実行
何故これで済まないの？ それでも済むよ
例えば繰り返し処理
forなくても書けるだろ。だからforなんて要らないって言ってるようなもん
なくてもプログラミングできるが、あれば楽できる 済まないw
>>355-356は-π/2〜π/2の範囲の実数の数だけ、それに対応する
sinの値を返すメソッドを用意すれば汎用的なsin関数なんかなくて済むと言ってるのと同じ。
だから、どうしてdoubleの変数が必要なのかと。
っていうかこの質問者、本当は分かってて質問してる変な奴だろうね8割方w
たぶん2chの他の板によくいる、サヨクを演じて自作自演やってる頭のおかしいネトウヨと似たようなメンタルの持主なんだろうと想像 >>355
voidだったら"その結果"ってどう受けとる？ なんか揚げ足取りしようとして引っ込みつかなくなってる感 つまりメソッドにラムダ式を渡して処理した結果を使ってメソッドの処理をさせるのか？ 結局デリゲートの非同期処理BeginInvokeを使用するってのが
従来大きな役割だったんじゃない？
でも今Taskクラスできたから必要なくなった デリゲート（委譲）って名前が悪いのかな
メソッドを他に渡しておいて適宜実行してもらうから委譲ともいえるけどそれは機能の一面しか表してない
MVPの人も過去にデリゲートいらねえって言ってたけど理解力が足りてない
c#は結構いろんなものがオブジェクトだけどメソッドはオブジェクトじゃない
デリゲートを使えばメソッドをオブジェクト（変数）みたいな感じで扱える
普通の変数とは違って+=で複数のデリゲートをいれることができるのが特徴的
コールバックとして使えるしeventはデリゲートをもとに作られてるので基本的な使用範囲は広い >>367
真面目な話、そういう衒学趣味の文系学生みたいな
文章が一番人を混乱させる。
「c#は結構いろんなものがオブジェクトだけどメソッドはオブジェクトじゃない 」って何やねんw
関数ポインタが分かればデリゲートがどんなものかはその類推でだいたいイメージできる。
機械語をやった経験があれば、関数ポインタなんか、なんだこんなのただのcall命令の
アドレッシングモードのことかってすぐわかる
でも重要なのは、「デリゲートとは何か」なんか分からなくてもデリゲートは使えるってこと。
「何か」なんか理解しなくていい。それを使って何が出来るかだけ理解すればいい。 ホビーじゃないプログラマ「c#は結構いろんなものがオブジェクトだけどメソッドはオブジェクトじゃない 」 >>370
この文何か変か？
メソッドはobject型から派生したクラスではないっていう当たり前のことを言ってるだけだろ >>368
他の言語ではメソッドもオブジェクトとして扱えるものもある
c#はメソッドはオブジェクトじゃない
その類推が間違ってるからダメなんだけどなあ…
デリゲートは関数ポインタじゃない
callでもアドレッシングとも全然無関係だわ
機能的には似たようなものに見えるけど全然別物だ >>368
文系学生もプログラミングする時代になったって事だよ。
> 「何か」なんか理解しなくていい。それを使って何が出来るかだけ理解すればいい。
これな。最近の「○○って何ですか」っていう奴らは何なんだ？
お前らだって、日本語の全ての漢字を読めるわけでもないだろうに。
「デリゲート」は失敗作だから新言語を作る気がないのなら理解する必要はない。
あれはthis+関数ポインタで、一番近いのはC++の「メンバ関数ポインタ」だが、
無駄に「クラス」「関数ポインタ」「ラムダ」を抽象化しようとしておかしくなってる。
結局ラムダを導入してしまったし、当初の方針は間違いだと認められたことになる。
今後「デリゲート」を採用する言語はないだろうよ。 .NET Core で過去の遺産が全て無くなるかと思ったけどそんなことはなかったぜ もともと関数がオブジェクトである言語はデリゲートを導入するメリットは少ない
c#にデリゲートが無かったらjavaの様に専用のインターフェイスを継承した無駄なクラスを作らなければならなかった
ActionやFuncやラムダがあればデリゲートが必要なかったと言ってるのは何かを誤解してる >>376
理解してなくても使えれば問題ないんだよ。
お前だってPCの起動方法（BIOSとか)知らなくてもPC使ってるだろ。
MSIL読めなくてもC#使えるだろ。
CPUの例外/割り込み機構を知らなくてもtry/catch使えるだろ。
一般プログラマにとってはプログラミング言語は道具であって、それ以上でも以下でもない。
新言語を作りたいのなら学術的に正確に理解することが必要だが、普通の人はそうではない。
それ以前にC#が死ぬ可能性を考えた方がいい。
C#専用の「デリゲート」の理解はつぶしが利かない。
他言語にもある「ラムダ」の理解のほうが重要だ。
デリゲートは「クラス」と「関数ポインタ+バインド」で対応した方が良かったと思う。
C#には未だに「バインド」がない＝デリゲートでの対応になるが、
実際、後付でバインドすることが出来ないだけ不便だろ。
>>377
Javaみたいなそもそも「関数ポインタ」がなかった糞言語と比較したら駄目だよ。
Cには関数ポインタはあった。
C#はそれを「デリゲート」として拡張した。
他言語は「第一級オブジェクト」として拡張した。
今のところ、後者の方が正解っぽいだろ。
(俺自身にはイマイチ「第一級オブジェクト」である利点/必然性は見えないのだが) 関数がもしobjectクラスから派生したオブジェクトになるとメンバーを持てることになるんだけど
A.B().ToString()のToStringが
B()というメソッド自体に係ってるのか
B()の返した戻り値にかかってるのかがよくわからないことになる Javaってstaticメソッドを関数インターフェースに渡すときは最適化してくれんの？ 1+2*3
こんな計算式があったときに1+2をしてから3かけて答えは9
こうはならないだろ。それは優先順位を定めてるから。(1+2)*3のようにかけば期待通りになる
それと同じで関数がオブジェクトでメンバー持ててもそれに合わせた処理の優先順位を定めればいいだけ 理解しないのと誤解してるのではわかっていないという点では同じだけど
理解してない場合は理解していない前提で行動できる
一方の誤解してる場合は悲惨だ >>383
じゃあどういう風に記述したらオブジェクトである関数のプロパティやメソッドにアクセスできるかここに書いてもらいたいが >>382
お前は日本語を勉強しろ。
俺達は「理解しなくていい」＝「完全に理解してはいないという自覚の元で使え」と言っているのであって、
それは「誤解」には繋がらない。
「誤解」ってのは、「理解してない馬鹿が理解しているつもりになっている」事を言う。
例えば、右結合と左結合を知らないお前みたいな馬鹿のことだ。 >>384
意味不明。何を書いて欲しいのか分からん。
> A.B().ToString()
これはAのメソッドB()を呼んでその戻り値に対してToString()を呼ぶ。
少なくともJavaScriptではそう。
で、何をしたい場合の記述が欲しいんだ？ >>386
思い違いをしていた
A.B().ToString()とA.B.ToString()で区別できる
クラスにフィールドとメソッドを同名にできないから区別できる
右結合と左結合は関係なかったけど >>384
エスパーすると、言いたいことは分かった。
お前は「第一級オブジェクト」も理解しておらず、「誤解」している。ちゃんと勉強しろ。
「第一級オブジェクト」ってのは、通常のオブジェクトと関数オブジェクトを区別しない。
だから書式は当然同じだし、正しく理解していればこの点が疑問になりようもない。
>>387
なら日本語を勉強しろ
> B()というメソッド自体に係ってるのか
これで何を表現しようとしたか言ってみろ。それは
> A.B.ToString()
ではないだろ。 >>385
誤解は悲惨
delegateを削除しろと言って削除してみたらActionもFuncも使えませんでした
eventも使えませんでした
もちろん言語レベルで変数としてのデリゲートの代わりになるものもありません
>>388
＞ > A.B.ToString()
＞ ではないだろ。
いやいやそこはそのままであってるし普通にそう理解できないのか？
A.B.ToString()が正解
逆にどう勘違いしたのか聞きたい 本当にC#からdelegateを削除しろって言ってるんだったらどこかおかしい
何にも理解してない プロパティなんて関数オブジェクトみたいなもんだな
プロパティに引数渡してぇ >>389
日本語で言うと、
> B()というメソッド自体に係ってるのか
と理解したって事だよ。
>>390
お前がな。
他言語にはdelegateなんて無いが、何も問題ないだろ。
あれ？って思えないのか？
(今すぐ廃止していいかどうかはまた別だが)
>>387
> クラスにフィールドとメソッドを同名にできないから区別できる
これは先見の明があったかもな。
関数を「第一級オブジェクト」に昇格させるのに文法的制約がない。
Javaに対しての利点にはなり、生き残る道かも。 >>391
JavaScriptではオーバーライドすれば出来る。
フィールド/メソッドの区別がなく、名前だけだから。
C#的には派生クラスで「プロパティ」「を同名の「メソッド」でオーバーライドだが、
これが型チェック的に無理なのか？
しかし名前の重複を許していないのだから、今後の拡張は可能のはずだが。
JavaScriptのデタラメ文法はどうかという奴もいるが、慣れてしまうと、
型あり言語の「型が違うだけ」で色々制約されるのも相当な糞だと気づけるぞ。
型検査はエラーではなく警告に留めるべきで、
プログラマがOKすれば型が不一致でも通してくれた方がマジで楽。
一番近いのはCってことになってしまうが。 友人ゼロのキモオタオッサンは他にやることないのかい 他の言語はともかくC#はGUIのイベントの管理にデリゲートのマルチキャスト使ってるんだから無かったら困るだろ だからメソッドがオブジェクトかどうかなんて話はただの衒学趣味的な無益な話w
そんな話は「ではオブジェクトって何？」って不毛な議論になるだけでしょw
初心者がデリゲートを理解して使えるようになるための屁の役にも立たないよw
>>397
素直に考えればデリゲート自身にマルチキャストの機能を持たせるんじゃなく、
シングルキャストのデリゲートのリストとして実装する方法もあったはず
なんか理由があって「こういう」風になってるんだろうが俺には積極的理由はよくわからんね。
ジェネリックをデリゲートで制約できないことと関係があるのかもしれないが
なまじマルチキャストなんて機能があるせいで何だかわかりづらくなってる面は否定できないと思う >>397
GUIに関してはdelegateの導入は不要だったで決着してる。
GUIにはOOPよりMVCの方が数段マシで、WPFもそうなってるだろ。
onclickにthisがバインドされている意味がそもそも無いんだよ。
決着が付いてないのはデータフロープログラミングをするときだ。
JavaScriptではObject.observeの導入が計画され、一部フィーバーしていたが、ポシャった。
https://www.html5rocks.com/ja/tutorials/es7/observe/
以下によると、非同期なのが使えなかったらしい。
http://tech.nitoyon.com/ja/blog/2015/11/18/death-of-oo/
JavaScriptの非同期は最早宗教だが、
はっきり言って無駄に非同期すぎて、余計にやりにくくなっているケースもある。これもそう。
C#は独自eventを実装出来るし、そのためにdelegateが用意されているから、
「データフロープログラミング」を文法的にサポートしているとは言える。
ただ、それ以前に、「データフロープログラミング」が主流ではないが。
お前らも実際、やってないだろ。
関数型の次に来るって事もなさそうだし。
とはいえ、上記の通り、今のJavaScriptではデータフロープログラミングは面倒だし、
getter/setterを頑なに拒むC++ではものすごくウザくなって事実上無理だ。
次の波が来ればevent/delegateも再評価されるかもしれん。 >>398
> シングルキャストのデリゲートのリストとして実装する方法もあったはず
同感。 理解してなくても問題なく使えるからって、それを理解しようとするのは悪い事じゃないけど
もとの発端はなんだったんだこれ 誰かさんの大好きなLinqはdelegateの塊なんだけどdelegateなくなっていいのかな
他の実装ではdelegate使ってないけど今の.netではデリゲートで実装されている デリゲートにラムダ式にLinq大好きだ！
これ無くして生きてけない！
チームの誰も読めないから放置されて我が道を歩んでいる。
生産性と品質が高いから客には好評です。 >>405
チームの誰もが読めないという事は保守性に欠けると言う事ですね そうだね。
でも、Linqバリバリ使ったらそうなるよね。
みんなの勉強しろよってこと。 Linqが分からないってのはラムダ式を理解できないってことなの？ 行列計算ライブラリ書いてるときに
おれ掛け算わからんからおれに合わせて全部足し算で実装して
おれはいまお前の案件に関わってないけど将来そのライブラリメンテするかもしれんからヨロシクな
とか言う同僚がいたらこいち頭おかしいのかなって思うじゃん
いやいや掛け算を勉強してからっていうか最低限の単位を取ってからメンテしろよってなるじゃん普通
これがLinqやλやデザインパターンになると当たり前のように底辺至上主義がまかり通る不思議な業界 LINQはC#にしかないからまだわかるけどラムダ式はいまどきの言語ならほぼ実装してるから知ってないとまずいよね Linqにも類似品あるよ
Javaのstreamやpythonのリスト内包表記など
というかそもそも単なるiterator patternでしかないからC#が起源ってわけでもない Linq以前にIEnumerableの意味が解らない人がいるからどうしようもない
.NET2.0から順に教えろってことかよ・・・ >>409
と、底辺至上主義がまかり通る所の意識高い系が申しております
>>412
どう見てもSQLが起源だろ >>414
クエリ形式の文法はSQLが起源かもしれんが
実装はSQLとは全く関係がないよ
C#などの実装はまさしくiterator patternだけど
SQLの実装をiterator patternでやろうとしたら遅すぎる そもそも書けない奴は論外として、使うなってのは同意できる
簡潔に判りやすいラムダ書いてくれりゃいいが、わざとやってんじゃねってぐらい難読化する奴いるからな
正規表現、SQ、掲示板の長文も同じだな Linqに限らず最近のソフトウェア技術は高度で生産性も高くなってる。
昔も人によって生産性に差が出たが、最近だと理解出来るか出来ないか？ぐらいの圧倒的な格差だ。
理由出来ない人は辞めればいい。
生産性が飛躍的に上がってるので理解出来る奴だけで間に合うよ。 自称プログラマー(趣味)ならともかく職業プログラマーでLinqすら理解出来ないやついんの？ Linqを十分に理解できても、可読性や保守性を大事にする人は
多少冗長でも他人が理解しやすい易しいコードを書くんじゃないの？ Linqてそんな可読性悪くないと思うけどなぁ
コメント書いときゃ何となくわかるべ >>417
出来ない人にも生活あるから辞めろとは言えないけどチームは分けて欲しい
使えて使いたい人がどんどん流出して出来ない人だけの会社になると悲惨 >>419
圧倒的に生産性が高かったらどうなの。
最近の案件は短納期になってるし、昔のコボルみたいに何十年もメンテして使うシステムも少ないと思う。 LinqよりSQLの方が難しいぞ。
SQLは難しいから使うなって言うのか？ 業務でいじるレベルのコードなんて知らないものでもグーグル先生いりゃ大抵なんとかならない？
linqも初めて見たときはとっつきにくくてわかりづらかったけど使ってりゃ嫌でも覚えちゃうよ
つっても当然すべてを使いこなしてるわけじゃなくて自分に必要な範囲のみ理解してる程度
業界によってだいぶ差はありそうだけど 生産性は保守運用まで含めてトータルで考えるべきで
保守性が損なわれればトータルコストも引き上がる >>423
あんたの書き込みがゴミだから。
オレらのやりとりがゴミだって言うなら、そう感じさせる様な高踏的な書き込み頼む。 保守性の低い Linq のコードってたとえばどんなの？
自分は他人のを読む場合でも特に困ったことないけどな〜。 >>415
イテレータの起源なら、C++(1983)は最初から持ってた。
C++のOOPはSimula発で、そっちが持ってたかは知らん。
いずれにしても、Java発の技術は存在しないぞ。
C#はLinqと、多分asyncもか？頑張ってる方だと思うが。
(あとちょっと違うがIDEのインテリセンスもC#が初のはず） クソカスの分際で人間様に話しかけてくるな
クソカスが引っ付くわ >>429
> (あとちょっと違うがIDEのインテリセンスもC#が初のはず）
インテリセンスはVB5.0の時代からあるんだが... >>425
> 自分に必要な範囲のみ理解してる程度
多分これくらいが適正で、これなら大して問題にならないんだよ。
問題は、意識高い系馬鹿の>>417
> 昔も人によって生産性に差が出たが、最近だと理解出来るか出来ないか？ぐらいの圧倒的な格差だ。
みたいな、おかしな奴がいることだよ。
Linq自体でそんなに格差が出来るはずもない。
仮に、Linq部分を関数呼び出しに変えたところで、本体のコード構造は全く変わらないだろ。
便利機能だが、その程度でしかないんだよ。
逆に言うと、制御構造の違いで勝負出来ない、
新文法が読めることしか威張れない馬鹿がそこに無駄に拘っている気がする。 linq で Where と OrderBy 使ったところをチームリーダーから For と List<T>.Sort() に書き換えられたことはある。理由は「他と違うから」
他と書き方を合わせておくのが大事なのはわかるけど… >>433
他と違うからって理由で直すのは良くないと思うな
本来関係ないはずのクラスの間に存在しないはずの関係性を作りこんでしまう
その結果、必要ない作業や、縛りを生み出して生産性を下げることになる
俺が経験したものだと
すでに書き終えたforeachをすべてforに統一
テスト済のDAO、DTOのsnake_caseを他レイヤに合わせてCamelCaseに統一
この2つが最高にバカバカしかった カプセル化を知らない人が少なくないのかな
「publicメンバーはクラス間のコミュニケーション円滑化のために規約として形式化しましょう」ぐらいならまあ理解できるが
「Linqはやめてループにしてくれ」なんて内部実装の形式にまで踏み込んでくるなよな
クラススコープで違和感なければそれでいいだろ >>433
俺はC#erではないが…。
単発のLinqも認めてもらえないのならご愁傷様。あれは普通に読める範囲だ。
見た目、Linq自体にはサブクエリ無しか？ならそんな酷いことにはならないはずだが、
例えばSQLでは再帰呼び出しが出来たりして、
マンデルブロだパズル解くだとか、おかしな事になってる。
https://www.sqlite.org/lang_with.html
Linqでどこまで出来るか知らんが、こんなん書かれたら殴りたくもなるだろ。
基本的には関数呼び出しにしてその先は隠蔽、
つまりLinq実装かFor/List/Sort実装かは上位からは見えない、ってことにすれば関係ないはずだ。
ただ、その場にベタで「何を選択しているか」が書かれている方が読みやすいことは多々あり、
Linqもその局面で使われているとは思うので、全面書き直しだと余計に読みにくくなるとも思うが。 >>436
どうでもいい議論だけど、一言。
カプセル化っていうのは「メソッドの中は可読性考えなくてよい」って意味じゃないよw
LINQ（というかクエリ式）嫌いの大半は批判してる人間がそもそも理解してないだけだと思うが一理はある。
それは使い方によっては複数の処理が有機的につながった、適切に分割統治されてない、
可読性の低いコードになるからだ
実際、筋の悪いプログラマが好む100行オーバーのメソッドに近い物になりうる >>439
どう読んだら「メソッドの中の可読性は考えなくていいよ」になるんだろ
外部の都合を内部実装にまで持ち込むな
クラス内での可読性が十分ならそれでいいだろ
って主張な
正しく動いて綺麗なコードを他のクラスの都合で書き直す
俺はこれある意味カプセル化破壊と言っていいと思う
もちろん本来の意味でのカプセル化とは違うのはわかってる >>440
どう読んでもそうとしか読めません
自分で自分の書いてあることが理解できないのかw
「メソッドの中は可読性考えなくてよい」と言っているのでなければ
>>436の1行目と4行目はつながらない。
カプセル化を理解していてもメソッドの中の可読性、例えば
「Linqはやめてループにしてくれ」と言うことはあり得る。
なぜなら、カプセル化とは「メソッドの中の可読性は考えなくていいよ」という意味ではないからだ >>441
いきなり訂正
× >>436の1行目と4行目はつながらない。
〇 >>436の1行目と3行目はつながらない。 ランダムな指定回数オブジェクトを作成する方法ないですか
7時まで待つ >>441
横からだけど、そう思えるのはお前さんがLinq使ったら可読性悪くなるって決めつけてるからじゃないの? >>435
コーディング規約を読んでないお前か
コーディング規約を定めてないお前の組織がバカなだけ 変数を関数の先頭に書く
returnは1つまで
変数名の先頭に型の略字を書く
varは使ってはいけない
こういうひと昔前まで大衆が信じてたバカ規約
システム全体で統一感のあるコードを書くって規約もいずれその仲間入りするとおもう
いまはまだIT業界全体が未熟だからみんな気付いてないだけ ちょっといいですか、この関数100行超えてます。
規約違反で可読性なくなります！
レビューで積極的に発言するサル、何も知らないで自分は立派なプログラム書いてると思っている。
ちなみににLinqの方が可読性上がるよ。
Linqはやりたいことをズバッと書ける。
古いやり方だと、このforループなに？ってなる。
forループは実装手段であって目的じゃないから。
単に慣れ、新しいこと勉強したくない連中が可読性だの規約だの持ち出す。 分割すれば良いじゃん
それが出来ないことを相手のせいにするな ■ このスレッドは過去ログ倉庫に格納されています
