16/08/28 01:33:21.98 +mkoP4gZ.net
>>384
以下見る限り、virtual付けたら普通にOOPできるとしか読めないが。
てか当たり前だが。
引き数渡ししたら出来なくなるって事もないと思うけど。
> しかし、動的な型に基づいて呼び出されるメソッドを決定したい場合があります。
> （というより、ほとんどの場合、メソッド呼び出しは動的に決定した方が都合がいい。）
> 動的な型に基づいて呼び出されるメソッドを選びたい場合、
> 以下のように、 メソッドに virtual という修飾子を付けます。
> URLﾘﾝｸ(ufcpp.net)
その上にvirtual付けなかった場合も書いてあるから見比べれば分かると思うよ。
405:デフォルトの名無しさん
16/08/28 01:37:09.54 +mkoP4gZ.net
>>388
まあその通りだ。今は最新環境がないので試せない。
確かにこれ以上やっても意味無いので、後日最新環境で試せば良いだけだね。
「拡張メソッド」ってのに俺が夢を見すぎているのかもしれんし。
406:デフォルトの名無しさん
16/08/28 02:08:02.18 hQF+q+Zk.net
>>389
何度も行っているように、拡張メソッドではオーバーライドできない。
なぜなら拡張メソッドはただのC#限定のstaticメソッドのシンタックスシュガーに過ぎないから。
そのURLではどこにも拡張メソッドのことは書いてないでしょ
class Triangle : Shape{}
ってプラグインみたいに外部のDLLで宣言されて、それを動的に読み込んで、hogeに渡ってきたらどうするの？
外部のDLLのことなんてコンパイルの地点では知らないので存在しない拡張メソッドを呼べるはずがない。
夢を見すぎているんじゃなくて、ただ無知でC#とかCLIをよく理解してないだけだと思う
javascriptで言うならprototypeの存在も知らないでjavascriptはウンタラカンタラ言っている状態なので、基礎から学び直したほうがいい
407:デフォルトの名無しさん
16/08/28 08:45:51.40 UJTSRlJK.net
>>385
そういう事か…確かに面倒だな
それならnull可メソッド的な物を作ればいいんじゃない
public null void Hoge(){
//thisがnullの可能性あり
}
408:デフォルトの名無しさん
16/08/28 09:58:20.62 +mkoP4gZ.net
>>391
試したぞ。VS
409:Community2015はサインインしないと使えなかったから、VS2008EEだが。 その範囲では確かに出来なかった。コードは以下ページを参考に改変した。 > http://ichitcltk.hustle.ne.jp/gudon2/index.php?pageType=file&id=cs002_ExtensionMethods しかし理由は拡張メソッドがstaticだからだよ。以下コードで、 class SampleClass1 {} class SubClass : SampleClass1 {} static class hoo { static public void SampleExtensionMethod1(this SampleClass1 sampleClass1) { Console.WriteLine("super_ex"); } static public void SampleExtensionMethod2(this SampleClass1 sampleClass1) { Console.WriteLine("super_ex2"); } static public void SampleExtensionMethod1(this SubClass subClass) { Console.WriteLine("sub_ex"); } } static void test(SampleClass1 sampleClass1) { sampleClass1.SampleExtensionMethod1(); // (A) sampleClass1.SampleMethod1(); // (B) } static void test3(SubClass subClass) { subClass.SampleExtensionMethod2(); .// (C) }
410:デフォルトの名無しさん
16/08/28 09:59:05.95 +mkoP4gZ.net
(B)は通常メソッドで、SubClassが与えられると当然SubClassのメソッドが呼ばれる。
ただし(A)は常にSampleClass1（親クラスというより「そこに記述された」クラス)の拡張メソッドが呼ばれる。
なお(C)はSampleClass1の拡張メソッドが呼ばれる。
(つまり子→親に関しては辿れる)
(B)が動作する以上、thisポインタは正しく渡っている。
あとは拡張メソッド側に継承関係を明記し、実行時型でこれを解決すれば良いだけなのだけど、
C#はどうやら文法的にこれを禁止している。(技術的には全く問題なく出来るはず)
今回出来ないのは、拡張メソッドがstaticだからコンパイル時にそこにリンクされるからだ。
そこでvirtual指定してみたが、これはSyntacErrorで落ちる。
どうやらそれ以前にC#は静的クラスは継承禁止で、当然virtualには出来ない。
しかしそもそも静的クラスが継承出来ないのが問題だ。
何故これを禁止しなければならないのかは分からない。
結局>>378の「static縛り」或いは上記「staticクラスは継承出来ない」のが問題。
とはいえこの仕様では「拡張メソッド」がイマイチなのはC#開発側も認識出来るだろうから、
何らかの理由があってこの仕様なのだとは思うが。
したがって>>364の指摘どおり、
> >>329で多態が必要なのに>>352は拡張メソッドでいいというのは矛盾してるよ。
これは間違いだった。拡張メソッドが多態出来ないのは知らなかったから。
となると>>352は
・Shapeクラスにメソッド追加---（α）
・GUI側でShapeクラスを継承したクラスを作って対応---（β）
・>>384方式で is XXXX 形式で全部書く---（γ）
のどれかになるが、俺ならαかβであって、γはないね。
411:デフォルトの名無しさん
16/08/28 10:08:01.32 acJIbkh4.net
スクリプトコーダーらしいパフォーマンス無視の考え嫌いじゃないよ
412:デフォルトの名無しさん
16/08/28 10:18:04.05 +mkoP4gZ.net
釣りか？
仮想関数とif/switch分岐でのコストはC++の連中が死ぬほど議論しているが、
結論はどっちもほぼ同じだよ。
だからαもβもγも動作速度は大して変わらないはずだけど。
しかしそもそもC#ってパフォーマンス重視出来る言語じゃないよね。
413:デフォルトの名無しさん
16/08/28 10:21:51.48 acJIbkh4.net
>>396
そこじゃない
414:デフォルトの名無しさん
16/08/28 10:24:49.86 +mkoP4gZ.net
じゃあどこだよ？
てかチャットじゃねーんだから意見があるのなら分かるように書けよ
415:デフォルトの名無しさん
16/08/28 10:26:20.15 acJIbkh4.net
>>398
それ君が言うんだ？
416:デフォルトの名無しさん
16/08/28 10:32:20.35 1sBWhH04.net
>>396
>C#ってパフォーマンス重視出来る言語じゃないよね
これ免罪符に糞コード生み出す奴多いから困る
417:デフォルトの名無しさん
16/08/28 10:34:33.21 acJIbkh4.net
入門書も読まないスクリプトコーダーはdynamicでも使ってろってこった
418:デフォルトの名無しさん
16/08/28 11:04:12.58 h1JFz9az.net
ウザイから質問者と回答者以外が3行以上書いたら死刑な
419:デフォルトの名無しさん
16/08/28 12:58:05.84 0rJ/vUpY.net
ひょっとして結局拡張メソッドからは型の外のスコープからアクセスできるメンバーにしか
アクセスできない、っていう糞当たり前の話を延々やってだけなの？
そんなのちょっと我慢して拡張メソッドの解説記事を5分も読んだら猿でも分かる話だろw
420:デフォルトの名無しさん
16/08/28 13:59:05.59 ZfPDxmLp.net
フロントエンドコーダーってろくな人材いないよな
421:デフォルトの名無しさん
16/08/28 14:35:00.94 hQF+q+Zk.net
>>394
実行時に解決するのは非常にコストが高い。
多分仮想関数を理解してないんだと思うけど、静的メソッドはC++やC#の方式だと仮想関数テーブルに無いので仮想関数になり得ない
また、呼び出しに失敗する可能性があるというリスクがあり、静的型付け言語の良さを殺している
>そもそもC#ってパフォーマンス重視出来る言語じゃないよね。
大きな勘違い。Roslynとかではパフォーマンスをかなり重視してる。
実行時はネイティブコードになるので書き方によってはC++と同等の速度が出る。
(ただし、C++は危険な操作を行ったりできるのでその分有利)
>staticクラスは継承出来ない
なぜなら、staticクラスは「インスタンス化、継承できない」という指定付きのクラスだから。なぜintは数値しか表せないのかみたいな意味不明な主張
>・Shapeクラスにメソッド追加---（α）
Shapeクラスが汎用的に使ったり、ライブラリとして公開するクラスならどうしようもない
WPF、WinForms、Xamarinなど、プラットフォームによって描画方法は全然異なるのでDrawメソッドを決められない
>・GUI側でShapeクラスを継承したクラスを作って対応---（β）
手間が掛かり過ぎるし、構造体やsealedクラスなら継承はできない。
クラス内にフィールドで保持してもいいが、Int32WrapperとかStringWrapper、加えて列挙体や関数、タプルなんかのラッパークラスができて複雑に。
状況によってはInt32WrapperWrapperみたいなものも爆誕
422:デフォルトの名無しさん
16/08/28 14:43:51.29 hQF+q+Zk.net
普通にココらへんのリンクで十分か
URLﾘﾝｸ(www.buildinsider.net)
>GUI側でShapeクラスを継承したクラスを作って対応
これは構文解析ライブラリは継承前のクラスを返してくるわけだから、無理があった
423:デフォルトの名無しさん
16/08/28 14:55:35.63 14dFRx50.net
拡張メソッドで話がだいぶ逸れたけどなに話してたんだっけ
424:デフォルトの名無しさん
16/08/28 14:56:21.93 QOlzH7cc.net
できない君か
425:デフォルトの名無しさん
16/08/28 15:27:24.87 +mkoP4gZ.net
>>405
先に了解事項を書いておく。
> >staticクラスは継承出来ない
> なぜなら、それが定義だから（意訳）
これは了解。こちらも調べている限り、どうやらそのようだと分かった。
staticクラスはシングルトンの糖衣かと思っていたが、わざわざ別物を用意しているね。
> 静的クラスはシールされるため、継承できません。
> URLﾘﾝｸ(msdn.microsoft.com)
> staticクラスとSingletonでは以下の違いがあります。
> URLﾘﾝｸ(takachan.hatenablog.com)
したがって、疑問は何故staticクラスにしか拡張メソッドを置けないか、になり、
つまり>>378と同じで、そちらの見解は>>385というのもいい。
ただ俺はこの回答に納得しているわけではないが、
結局これはどこまでやるかということだから。
426:デフォルトの名無しさん
16/08/28 15:30:05.25 +mkoP4gZ.net
次に今回の実装方式について、
(α）についてはその通り。
（β）については「継承」が出来ればそっちの方がいいが、無理なら「内包」でも問題ない。（β＋）
コンストラクタでShapeを与えて内包したRectangleDraw、CircleDrawクラスを作り、
ShapeDrawクラスを継承する。
つまりラッパーオブジェクトを作成して同階層構成でXXXXDrawクラスを構成する。
これだと自前クラスなので何も問題なくOOPできるが、
コンストラクタ内では1回だけ is XXXX でswitchしなければならない。
それでも毎回記述が必要な（γ）よりマシ。
> クラス内にフィールドで保持してもいいが
後の文を読む限りこれはばらしてということだと思うが、
(β＋)はばらさすにそのまま保持する。（フィールドとして Shape shapeを持つ）
そして各Drawメソッドからは this.shape.xxxxとしてアクセスする。
こうすれば、アクセサに関してもShapeの定義そのままであり、追加記述は必要ない。
これにより、外枠以外の本質的記述が（γ）に対して増えることはない。
これでどうだ？
最後に以下だが、
> 実行時に解決するのは非常にコストが高い。
> 多分仮想関数を理解してないんだと思うけど、静的メソッドはC++やC#の方式だと仮想関数テーブルに無いので仮想関数になり得ない
> また、呼び出しに失敗する可能性があるというリスクがあり、静的型付け言語の良さを殺している
これはいろいろだいぶ違う気がするが、確認も時間がかかるし、後回しでいい。
427:デフォルトの名無しさん
16/08/28 15:40:18.87 xWdxGs/J.net
パターンマッチング推進派の巧妙なアンチ書き込みか！
428:デフォルトの名無しさん
16/08/28 15:50:02.41 +mkoP4gZ.net
>>406
リンク先読んだ。筆者の考え方とは同意する。
結果、俺は以下に該当するのでオブジェクト側に突っ込みたいと考える。
> 型だけを見た単純な分岐しかしない場合、
> 仮想関数を使う方が実行性能面でも保守しやすさの面でもいいだろう。
そちらは以下に該当すると考えてパターンマッチングというのも了解だ。
> 1つは、型の外に実装を書く方が好ましい場合だ。（中略）
> 特定の種類のアプリでしか使わないような機能を書く場所としては （型は)【追補】
> 不適切となる。
429:デフォルトの名無しさん
16/08/28 16:06:33.60 +mkoP4gZ.net
>>405
ちなみに以下について俺の疑問点を先に挙げておく。
> 実行時に解決するのは非常にコストが高い。
> 多分仮想関数を理解してないんだと思うけど、静的メソッドはC++やC#の方式だと仮想関数テーブルに無いので仮想関数になり得ない
> また、呼び出しに失敗する可能性があるというリスクがあり、静的型付け言語の良さを殺している
・静的メソッドはvtableに置く必要はないが、普通はそこに置いているはず。
それが一番簡単だし。
(クラス自体がstaticではないのでコンパイル時にリンクは無理）
したがって、virtualメソッドとstaticメソッドの実行速度差は無いはず。
・呼び出しに失敗って何？C#ならコンパイルが通っている限りあり得ないと思うが。
(C++みたいな<reinterpret_cast>とかは無しで)
・実行時に解決って言ったって、vtableの場合は解決済みのthisポインタを持っているわけであって、
何かを比較したりすることはない。間接呼び出しになるだけ。
コストはゼロではないが、リフレクションとかとは全く違う。
URL付きのツッコミは歓迎。
430:デフォルトの名無しさん
16/08/28 16:30:05.10 +mkoP4gZ.net
追記
俺の間違いが分かったので書いとく。
× > ・静的メソッドはvtableに置く必要はないが、普通はそこに置いているはず。(>>413)
○ 置いてない。静的メソッドは直接呼び出し。
× > したがって、virtualメソッドとstaticメソッドの実行速度差は無いはず。
○ 直接呼び出しする非virtualの方がvirtualよりは速い。
staticメソッドには言及されていないが、多分非virtualと同じ。
> メンバ関数
> URLﾘﾝｸ(www.microsoft.com)
他の下2件はどこを調べればいいか分からないのでツッコミ待ち。
よろしく。
431:デフォルトの名無しさん
16/08/28 18:36:26.78 hQF+q+Zk.net
>>410
>1回だけ is XXXX でswitchしなければならない
その時にパターンマッチング使えば楽だよねって話でしょ
毎回使うかどうかは好みや書き方次第かと
>呼び出しに失敗
拡張メソッドの実装を理解してる？
ExtensionAttributeを静的クラスに付与して、コンパイルの時にそれを見てるだけ。
URLﾘﾝｸ(msdn.microsoft.com)
継承関係とは違って共通言語仕様に定められていない（はず）なので、全言語が対応していない
例えばShapeクラスとかをライブラリとして公開したとすると、他の言語がShapeクラスを継承した時に必ず拡張メソッドを書いてくれることは保証できない
そうすると、存在しないメソッドは呼び出せないので失敗することになる
何なら、動的に新しい型自体を作成してメソッドに渡すことすらできる。
>実行時に解決
拡張メソッドはそもそもサポートしてない言語もあるし、全く独立したクラスなのでそもそも動的に解決するのが困難
やろうとすればたぶん共通言語仕様とかの変更が必要で影響ばかりでかくて利点が皆無
432:デフォルトの名無しさん
16/08/28 19:17:00.51 +mkoP4gZ.net
>>415
いや>>352に対する君の主張は「毎回べた書き」だろ。すり替えるなよ。
それはさておき、通常はクエリメソッドを用意しておいてそれで対応だ。
例えば Shape.type で 'rectangle' や 'circle' が取れるとか。
だからパターンマッチング自体の記述は要らんよ。（見た目は同様ではあるが)
というかそれが絶対に必要ならこれまでどうしようもなかったことになっちゃうだろ。
> ExtensionAttributeを静的クラスに付与して、コンパイルの時にそれを見てるだけ。（中略）
> そうすると、存在しないメソッドは呼び出せないので失敗することになる
だから何？コンパイラが通らないだけだろ。
話がずれているか？
上記話のすり替えをしてくる奴だから信用はしていないが。
>>405を見る限りこちらは「一般」の仮想関数だと認識して回答した。(>>413,414)
そちらは
・「拡張メソッド」の動的解決はコストが高くて、仮想関数になりえなくて、呼び出しに失敗する
ことを言っていたか？
それなら「一般メソッド」について記述した>>413,414については見解の相違なしということでいいな。
> 他の言語がShapeクラスを継承した時に必ず拡張メソッドを書いてくれることは保証できない
当たり前。というか静的にリンクするんだから、namespaceに名前がない時点でコンパイルが通らないだけ。
使う気なら自前で定義なりusingしなければならないし、無ければ使えない。
多態する気なら、例えば多重継承として実装すればいいだけ。特別なコストはかからない。
実装方式は>>414のリンクに記述してあるとおり。
拡張メソッドを多重継承として実装出来ない理由があるか？
> 利点が皆無
どこがだよ？やけくそになってないか？
拡張メソッドが多態出来ればメリットがあるのは見たら分かるだろ。
今多態出来ていないのは何か理由があるか手を抜いているか（今後対応するか）だよ。
433:デフォルトの名無しさん
16/08/28 19:49:44.91 hQF+q+Zk.net
>>416
>毎回べた書き
その主張は俺じゃないが？
>クエリメソッド
何を言っているんだ？今でもできるぞ??
if( hoge is Rectangle){ ((Rectangle)hoge).Draw(); }
とか。状況によってもっとわかりにくくなるから、もっと簡潔に書きたいね、という話なんですが・・・
流石に語るのにC#を知らなすぎじゃないか？
>静的にリンクする
静的にリンクしないこともある。わざわざプラグインとかDLLとか言ってるでしょ？
C#では言語仕様上、コンパイル時に継承した型をすべて把握できない
あと、「他言語は対応していない」の部分を完全に無視してるみたいだけど、そこも要点なんですが
>「一般メソッド」について記述した>>413,414については見解の相違なし
訂正が入って主張がわかりにくくなってるが、一般メソッドに関しては問題ないと思われる
拡張メソッドはC#の言語仕様ではなくて共通言語仕様の方で対応してないので、同じ仕組を実現できない
>多重継承
全く独立したクラスのstaticメソッドをどうやって多重継承するの?
>拡張メソッドが多態出来ればメリットがあるのは見たら分かるだろ
ほぼ拡張メソッドじゃなくてさっき君が言ったShapeDrawクラスを使うべき案件
僅かにメリットがあっても、共通言語仕様を置き換えて、多言語のコンパイラ(VB.NET,F#,C++/CLI,JScript.NET等)を書き換え、UnityやMono、Xamarinを対応させ、後方互換を除去してまで導入する機能かというとそうは見えないな
.NET Frameworkが始まる前とかに提案すればよかったかもしれんが
本気で完璧な利点があると思うなら、Roslynにissueを立てると良い
434:デフォルトの名無しさん
16/08/28 20:04:28.22 hQF+q+Zk.net
>Shape.type で 'rectangle' や 'circle' が取れるとか。
ちなみに、これは一番危険
標準ライブラリにあるShapeクラスをA社とB社が継承し、AライブラリとBライブラリを作ったとする。
そのどちらのライブラリも必要だったので同時に使おうとすると、rectangleの名前が衝突して区別できない！となる。
そこで使うのが「型」なわけだ。
現在でも出来てるけど、コンパイラ制作とかだと頻繁に出てくるよね～、なら、パターンマッチング導入しよう！という流れかと。
ちなみに、ShapeDrawクラス見たいのにも問題はあって、例えば構文解析した要素が10000を超える巨大な木構造があるとする。
それをGUI側ですべてNodeDrawみたいなクラスにラップするとその変換にかかる時間とメモリが馬�
435:ｭにならなくなってくる さらに、ライブラリの木構造が変更されると、GUI側ではすべて構築しなおし 手間を防ぐためにキャッシュしたり差分のみを変更して・・・という状況になる場合もある
436:デフォルトの名無しさん
16/08/28 20:23:46.58 5A6j7Ufp.net
なんでこんな荒ぶってんのこいつ
とりあえず落ち着いて猫でもわかるC#でも読みなって
437:デフォルトの名無しさん
16/08/28 20:23:47.93 +mkoP4gZ.net
>>417
こちらの認識は、ID:gXVhUUHW = ID:hQF+q+Zk だ。
違っていたのならすまんかった。
> クエリメソッド
クラスの中に複数種が入ることがある場合、（多態される場合）
一般的に「何が入っているか」は分かるようになっている。だからそれを使う。
C#の文法による解決は必要ない。（というかそうじゃないと動的型を取れない言語で使えない）
> あと、「他言語は対応していない」の部分を完全に無視してるみたいだけど、そこも要点なんですが
これについては関係ないとしか思えない。
拡張メソッドを自動的にエクスポート出来ると思っているのならそれが間違いだろ。
namespaceの中に拡張メソッドが見えていないと使えないのだから、
使う側が全部管理しないといけない。
同じ拡張メソッドを他でも使いたければ、その拡張メソッドを格納したクラスを使う側がusingしないといけない。
現在の実装はあくまで「コンパイラがstaticクラスのstaticメソッドに対しての関数呼び出し」に変更するだけ。
それがコンパイル時に出来なければコンパイルが通らない。他言語はどこに関係あるんだ？
> 全く独立したクラスのstaticメソッドをどうやって多重継承するの?
多重継承は全く独立したクラスを継承することですが？
当然これをやる時はvirtualにする（今現在のC#の制限事項をはがす）のだが、ついて来れているか？
元々「継承出来ないクラス」(stat;icクラス)にしか拡張メソッドを置けないのが問題であって、
拡張メソッドをシングルトンに置ければ何も問題なくなる。
そしてそれが実現出来ない技術的障害はない、というのが俺の主張。
この辺を最初から知っていて傍観してるのが>>378だろ。
> ほぼ拡張メソッドじゃなくてさっき君が言ったShapeDrawクラスを使うべき案件
いやそっちの意見は何なんだよ？
君はパターンマッチングが一番良いと思ってるんだろ？
俺は、「拡張メソッドで多態」（α）(β）(β＋）の順で検討する。
ただ第一候補が今は駄目なことを知らなかったから迷走したが。
438:デフォルトの名無しさん
16/08/28 20:32:09.16 +mkoP4gZ.net
>>418
> そのどちらのライブラリも必要だったので同時に使おうとすると、rectangleの名前が衝突して区別できない！となる。
それは最初からポインタの型が違うから区別出来るだろ。
> ちなみに、、、、以降(ry
それがないように、本来は「直接クラスを拡張」（α）するなり「継承」（β）するべきだろ。
やむなく内包（β＋）なりパターンマッチング（γ）になった場合は変更の影響は受けるのは当たり前。
ただ、（β＋）よりも（γ）の方が記述の変更量は多いよ。
その辺はMSDNにもそのまま書いてある。
> 拡張メソッドは、一般的に、必要な場合に限り注意して実装することをお勧めします。
> クライアント コードで既存の型を拡張する必要がある場合、
> 可能であれば既存の型から派生した新しい型を作成することで行ってください。
> 詳細については、「継承 (C# プログラミング ガイド)」を参照してください。
> 拡張メソッドを使用して、変更できないソース コードのある型を拡張する場合、
> 型の実装の変更により拡張メソッドが破損するというリスクを負うことになります。
> URLﾘﾝｸ(msdn.microsoft.com)
439:デフォルトの名無しさん
16/08/28 20:34:15.18 veN4TyYm.net
>>420
何を言ってるのかよく分からんけどなんか盛大に勘違いしてる気がするw
440:デフォルトの名無しさん
16/08/28 20:43:32.81 lqCVK6M2.net
彼は拡張メソッドに夢をみすぎてるんだ
現実を知らないキッズには良くあることさ
拡張メソッドで多態()
441:デフォルトの名無しさん
16/08/28 20:56:44.18 hQF+q+Zk.net
こういうサンプルで示せばいいのかな？
細かく書くと面倒なので擬似コードだけど、(拡張メソッドを通常メソッドと同様に呼び出す以外は)同じことが実際にできる
URLﾘﾝｸ(ideone.com)
Main.exeではShapeクラスとRectクラスが定義されている。
これ単体ならすべてのShape継承クラスが拡張メソッドDrawを持ってる
Main.exe用のプラグイン、plugin.dllを他の人が後から作り、Main.exeのShapeを継承したTriangleクラスを実装している。
442:Main.exeはdllを動的に読み込み、インスタンスを作り、Hogeメソッドに渡している。 ここで、plugin.dllでは拡張メソッドDrawが定義されていない。そして、この拡張メソッドの定義を強制する手段が存在しない
443:デフォルトの名無しさん
16/08/28 21:08:44.28 hQF+q+Zk.net
>君はパターンマッチングが一番良いと思ってるんだろ？
いや、状況次第。ラッパークラスを作るほうが良い場合も多いと思うよ。
そのラッパークラスのインスタンスを作る時にパターンマッチ構文があれば簡潔にかけるので非常にありがたい
あと、今気づいたけど、そもそも構造体は仮想関数テーブル持ってないから多様性をもたせようが無かった
>>394でもthisポインタって言ってるけど、構造体の場合は仕組み上コピーが渡る
444:デフォルトの名無しさん
16/08/28 21:37:38.11 +mkoP4gZ.net
>>424
それが、「コンパイルには通るが拡張メソッドを呼ぶと失敗する」例だというのなら、
言いたいことは分かった。
ただ、それは失敗して当然というか、
「知らない図が書けない」だけであって、実装してない部分が動かないだけ。
丁寧にやるのなら、拡張メソッドがない場合に□を
出力して対応するしかないし、それだけでしかない。（文字化けのようなもの）
(C#に実装の有無を確認する方法があるかどうかは知らない。
JavaScriptでは問題なく出来る。
拡張メソッドが多態出来るのなら、親(Shape)に□を表示させるメソッドを実装しておく）
別にそれは正しく全てを実装する時に手間が増えるわけでもない。
dllが他言語から供給されたとしても関係ない。
そもそもそちらの言うとおりShapeが演算用クラスであった場合、
クラスを追加する側にこちら『だけ』で使っている拡張メソッドを実装してくれと言うのが無理。
拡張メソッドは使う側が全部管理しなければならないだけ。実装も。
実装を強制する方法はないが、その必要もない。
自前で実装済みかどうかを判定して対応するのみ。
(定義を確認する方法がないのなら困ったことになるが、
それでも最悪try-catchは出来ると思うが、駄目なのか？)
445:デフォルトの名無しさん
16/08/28 21:46:13.45 +mkoP4gZ.net
>>425
> 構造体
これはShapeがクラスではなく構造体だった仮定か？
それは最初から間違いで、クラスにしてもらうしかない。
どのやり方がいいのかは合意をとる必要はないけど、
俺が思うには「拡張メソッドで多態」が出来れば全て満足で上手く行く。
現状の拡張メソッドの仕様では旨味が無く、使いどころがない。
正直C#でこの手の「残念仕様」を見るのは初めてで、少し驚きだ。
(C#の仕様はどれもこれも何を意図しているか大体分かるものばかりだった）
ただ、やる気だけの問題だと思うから、今後拡張される可能性はあると俺は思うけど。
446:デフォルトの名無しさん
16/08/28 21:52:14.06 veN4TyYm.net
>>427
そんな自分で自分の足を打ち抜くような機能が入るわけないじゃんw
447:デフォルトの名無しさん
16/08/28 21:55:53.66 +mkoP4gZ.net
追加
>>424
その場合、仮にdll側で拡張メソッドを実装してくれていたとしても、インポート出来ないだろ。
こちら側がコンパイル時に見えてないと駄目なんだからさ。
だから今の仕様は「全部自前で用意しろ」なんだよ。
俺もそれでいいと思うし。
拡張メソッドを実装したクラスをインポートするっていうことも出来る(ようになる）のかもしれんが。
448:デフォルトの名無しさん
16/08/28 22:01:29.02 xWdxGs/J.net
これを15年前の世界から書き込んでるのだから、彼は凄いよ。
virtualも拡張メソッドも理解出来てなくて仕方ない。まともな動作環境すらない世界で仕様を理解しようと、間違ったことをワザと書いて、我々に答えさせてるんだから。
449:デフォルトの名無しさん
16/08/28 22:20:25.25 23NihOTg.net
C#の拡張メソッドをJavaScriptのプロトタイプ拡張と同じ感覚で考えてんのかね
スクリプト言語やりすぎると頭おかしくなるってのは本当だったんだ
450:デフォルトの名無しさん
16/08/28 22:24:20.01 ev9L5f83.net
javascriptでもプロトタイプ拡張は99.9%バッドプラクティスだけどな
気づくのに数年掛かった(prototype.jsが持て囃された期間を考えてみたまえ)程度にあいつらフロントエンジニア共は馬鹿だ
451:デフォルトの名無しさん
16/08/28 22:46:16.98 hQF+q+Zk.net
>>426
それがC#の設計思考とずれてるんだよ。
できるならば静的に解決したい。コンパイルに通ったならメソッドが存在し、存在することを前提に最適化したい。
ただの静的メソッド呼び出しだったのに、動的に確認する分かなりコストが高くなる。数万の木構造にやるなら1msが命取り
あとは、それを実装すると名前解決が異常に複雑になり、今後の言語拡張の障害にもなるな
その程度で良いならRoslynを使ってVSのプラグインでshape.Draw()ってコードをパターンマッチングに展開するプラグインを作ればいいんじゃないかな。
452:デフォルトの名無しさん
16/08/28 23:08:26.53 +mkoP4gZ.net
>>433
何について言っている？
「拡張メソッドの多態」についてなら、既に言ったようにローカルに多重継承させればいいだけ。
実装自体も無理はないし、動作速度も問題ないと思うよ。
各クラスのvtableをコピーすることにはなるけど、
オブジェクトを直接vtableに載せていることはないだろうし、
コピー領域は、sizeof(void*)*フィールド個数 Bytes でしかない。
もちろん他の実装も出来るだろうし、いずれにしても必要になればMSが検討すればいいだけ。
多分ここら辺の話が通じないのは、君がvtableの実装を理解出来ていないのだと思うよ。
それは>>414にあるURLを全部読めばいい。
C++やC#のコンパイル言語は、メソッドは動的に名前で解決するわけではないんだよ。
(なおJavaScriptは全面的に動的解決だが、それでもC#の1.5倍ほど遅いだけ。)
俺は「拡張メソッドの多態」は欲しいと思う。
君はこれについて「要らない」のか「欲しいけど出来ないという意見」なのかはっきりしないが。
453:デフォルトの名無しさん
16/08/28 23:14:10.11 rlU+i3Q+.net
そんな極々ニッチな需要のためにMSが動くわけないだろ
そんなに自分のアイデアが優れてると思うなら実装して然るべき場所で評価してもらえよ
今やコンパイラもオープンな時代だから出来ないことはない
良い加減うっとおしいんだよ
攻撃的な口調で長文連投すんなハゲ
454:デフォルトの名無しさん
16/08/29 00:39:03.09 0+IBopma.net
>>434
こちらのvtableの知識を疑う前に、staticがvtableにあると勘違いしていた理由を考えるとかC#の勉強するとかしたほうが良いかと
プラグイン等により拡張メソッドを持たないインスタンスが渡ることを考慮し、vtableの実行の前に存在判定が必要で結構コストになる
また、Javascriptが早いのはJITが鬼のように最適化してるからで、そこまで考えるとstaticメソッドのインライン展開が妨害されるとか、
質問としては、vtableのコピーでなんでフィールドの個数が出てくるの?
あと、別のファイルだと別の拡張メソッド呼び出しになるかもしれんが、どのタイミングでインスタンスのvftable書き換えるの?
その場合、拡張メソッドの呼び出しはすべてスレッドセーフじゃなくなる？
今のところメリットが0とは言わないが、メリット<<<実装の手間、影響
455:デフォルトの名無しさん
16/08/29 00:58:40.06 bQrj623w.net
C#でアスペクト注入したい
RealProxyか実行時コンパイル以外に手段はある？
456:デフォルトの名無しさん
16/08/29 14:42:36.92 iNmqLiUV.net
c#を主に使っていて時々php書くとphpが使いにくいてイライラするのですが、皆さんそういう事有りますか？
457:デフォルトの名無しさん
16/08/29 14:53:02.96 fXL0TTLw.net
>>438
フツー
458:デフォルトの名無しさん
16/08/29 15:11:05.94 yhjzEVuM.net
歯ブラシでプログラムを書こうとしたら辛いのは当たり前だろう
URLﾘﾝｸ(en.m.wikiquote.org)
＞PHP is about as exciting as your toothbrush.
459:デフォルトの名無しさん
16/08/29 18:41:52.94 IWCj2egw.net
ASP.NET CoreでWEBアプリを作っています
機械的に処理を行うためHTMLの代わり
460:にJSONを返さなくてはいけません この場合MVCで作るべきでしょうか(ViewでJSONを生成)
461:デフォルトの名無しさん
16/08/29 18:45:13.24 zht9j9T7.net
>>441
なぜViewで？
462:デフォルトの名無しさん
16/08/29 18:52:19.01 IWCj2egw.net
>>442
どのような設計が正しいのかを聞きたいです
簡単に言うとTwitterのUIは作らずにJSONを返すAPIだけをASP.NET Coreで作る感じです
463:デフォルトの名無しさん
16/08/29 18:54:32.44 zht9j9T7.net
>>443
Web API（CoreではMVCと統合されたけど）を使いたいってこと？
464:デフォルトの名無しさん
16/08/29 18:57:50.47 IWCj2egw.net
>>444
そうです
ASP.NETの無印はWEB APIがあるみたいですが、Coreだとないみたいなので…
465:デフォルトの名無しさん
16/08/29 19:04:08.33 zht9j9T7.net
>>445
Coreではライブラリが統一されただけだから普通に使えるよ。
URLﾘﾝｸ(docs.asp.net)
466:デフォルトの名無しさん
16/08/29 19:10:38.42 IWCj2egw.net
>>446
ありがとうございます
WEB APIはCoreでも使えたんですね
もう一ついいですか？
ASP.NET無印を使ったことがなく、いきなりCoreから入るのですが、
まだCoreがリリースされてあまり経っていないらしく情報が少ないのですが、
無印の情報はCoreにもある程度は応用出来るのでしょうか？
467:デフォルトの名無しさん
16/08/29 19:35:09.64 zht9j9T7.net
>>447
無印って、ASP.NET Web APIのことを言ってる？基本は一緒だけど、Coreが出た以上、特に今までのWeb APIはオワコン
Coreを使わなければならない理由があるの？
468:デフォルトの名無しさん
16/08/29 20:37:32.13 IWCj2egw.net
>>448
Linux鯖を使いたいから
WinVPS高いし
469:デフォルトの名無しさん
16/08/29 21:18:16.62 shRUR2oh.net
高いのは嫌だリスクは取りたくないってガキじゃあるまいし
470:デフォルトの名無しさん
16/08/29 21:19:28.87 rWWvEZg8.net
>>450
ここは普通にガキが来る板だぞ
471:デフォルトの名無しさん
16/08/29 21:33:00.30 oeiBIMAZ.net
ガキだろうが年寄りだろうがケチりたい人はケチりたいんじゃね
472:デフォルトの名無しさん
16/08/29 21:34:22.99 IWCj2egw.net
>>450
ガキだから金がない
さくらVPSでも結構きついし
473:デフォルトの名無しさん
16/08/29 21:49:29.10 1G08D0Wz.net
お金が無い分、努力でカバーだね。
情報少ないから、ぜひ先駆者となってくれ！
474:デフォルトの名無しさん
16/08/29 21:52:42.08 IVf1OSSE.net
>>450
> 高いのは嫌だ
はわかるけど
> リスクは取りたくない
ってどこから出てきたんだ？
Linux 鯖で .Net なんてリスクだらけだと思うが
475:デフォルトの名無しさん
16/08/29 22:01:53.90 HSXk2xhn.net
Node.jsとかでよくね?
ちょっとしたAPIにC#とか大袈裟すぎでしょ
476:デフォルトの名無しさん
16/08/29 22:14:41.24 IWCj2egw.net
>>456
ちょっとしたじゃなくて結構大規模になる予定
あと動的型付けは苦手(TypeScriptはあるけどC#の方が好き)
477:デフォルトの名無しさん
16/08/29 22:55:39.71 AyW9Pu98.net
>>457
Linuxには精通してるってことでいいんだよね？
478:デフォルトの名無しさん
16/08/29 23:00:29.13 IWCj2egw.net
>>458
ラズパイで鯖建てする程度なら出来るけど
479:デフォルトの名無しさん
16/08/30 10:16:24.70 8eGP8u09.net
まあコンソール使えりゃどうにかなるかな
480:デフォルトの名無しさん
16/08/31 22:36:07.93 0fzmkTEU.net
C# 7、そしてその先へ： 非同期処理（前編） － Task-like
URLﾘﾝｸ(www.buildinsider.net)
C# 7、そしてその先へ： 非同期処理（後編）－ 非同期シーケンス
URLﾘﾝｸ(www.buildinsider.net)
481:デフォルトの名無しさん
16/08/31 22:39:34.64 97WvllZy.net
コピペマンって本人は親切のつもりなんだろうし、本人気づいてないだろうけど不気味だよw
482:デフォルトの名無しさん
16/08/31 23:35:57.85 +hoACOJG.net
パフォーマンスをシビアに意識するのはもはやライブラリ作っている人やそういった
高速化を専門にしている人だけあって毎日コード書いてる人間としては書きやすさだけが気になる
483:デフォルトの名無しさん
16/08/31 23:46:34.06 +hoACOJG.net
今後もまた無駄な名前空間がぼこぼこ増えていくんだろう
MSはnamespaceをごちゃごちゃさせ過ぎてる
すっきり数本の柱にしておけばよかったのに細分化させすぎだ
484:デフォルトの名無しさん
16/08/31 23:56:22.35 lLnW0vHt.net
新しいおもちゃが手にはいると遊びたくなるものさ
485:デフォルトの名無しさん
16/09/01 00:11:33.35 Xz8sejsg.net
Scalaの糞の山に比べたらこの程度可愛いもん
486:デフォルトの名無しさん
16/09/01 00:44:15.01 YmetP/KJ.net
大きすぎるnamespaceよりマシ
487:デフォルトの名無しさん
16/09/01 04:01:29.40 rDaq2Eci.net
毎日コード書ける仕事したい。
机上で数ヶ月会議して設計して、作って仕様変更とか無駄なことやめたい。
488:デフォルトの名無しさん
16/09/02 15:05:01.55 oqbH3zDE.net
今 Microsoft Visual Studio Community 2015 だかってのをインストールした
C#は全く知らない。
この統合環境の使いかたもほぼ分からなくて困ってる。
CUI のhello worldだけは出力させてみた。
こんな俺に学習用のいいサイトよろしくお願いします。
489:デフォルトの名無しさん
16/09/02 15:13:59.98 LbMFm82d.net
とりあえず ++C++; 未確認飛行 C でいいんじゃないでしょうか
490:デフォルトの名無しさん
16/09/02 15:29:48.83 oqbH3zDE.net
ありがとう。ではそこで学習する事にします。
今とりあえず
int i = 10;
Console.WriteLine(i + " " + "hello_world");
これを実行させてみたのですが、
スクリプトのごとく数値が都合よく文字に変換されて実行されました。
数値と文字は暗黙の自動変換なのでしょうか？
491:デフォルトの名無しさん
16/09/02 15:41:30.76 Pni+o0iv.net
+ 演算子 (C# リファレンス)
URLﾘﾝｸ(msdn.microsoft.com)
492:デフォルトの名無しさん
16/09/02 15:53:07.39 oqbH3zDE.net
ありがとう
493:デフォルトの名無しさん
16/09/02 18:32:47.06 Q71J+JAr.net
Microsoft.Office.Interop.Excelのcomを使って、既存のグラフシートを編集しようと思うのですが、
下記のコードを実行すると、エラー0x8002000Bが出てアクセスできません。
Worksheet ws = wb.Sheets["graph1"];
既存のグラフシートにアクセスするにはどうしたらいいのですか？
494:デフォルトの名無しさん
16/09/02 18:41:51.61 hbWVf6eK.net
>>474
そんなことやったことないんでよく知らんけど、ここ見る限りSheetsじゃなくてChartsの方
使わないとだめなんじゃないの？
URLﾘﾝｸ(msdn.microsoft.com)
495:デフォルトの名無しさん
16/09/02 19:22:01.67 VaHoIWRz.net
IDE使えないって人に++c++進めるのはどうかと思うけどｗ
496:デフォルトの名無しさん
16/09/02 21:17:39.97 oqbH3zDE.net
なんでボールから入るんだよ
497:デフォルトの名無しさん
16/09/02 21:17:56.50 oqbH3zDE.net
ごめんスレ間違えた
498:デフォルトの名無しさん
16/09/03 01:22:42.31 PSgZ0shn.net
いままでvbaで開発してて最近c#勉強してるんだけど
visual studioで開発するときvbaでいうモジュール単位（vb editor上でmoduleっていわれるやつ）に分ける方法教えてクレメンス
クラスとか作ればソリューションエクスプローラに自動的に追加されるっぽいけど
コードが縦に長くなって開発しづらい
たぶんvbeなんかよりもよっぽど開発しやすい方法があるんだろうけど
プログラミングの仕方というより開発の仕方みたいなのを解説してくれているhpとか本があったら教えてほしい
てかoopの考え方を理解出来てな�
499:｢のが問題かもしらん スレ違いだったらごめんなさい
500:デフォルトの名無しさん
16/09/03 01:27:37.27 Jo2eCVzY.net
>>474
結局質問だけしてトンズラか。どうせマルチくんなんだろうな。
>>479
君はVBAも良く分かってないと思うw
とりあえずC#にモジュールはない。
VB.NETにはあるけど普通はまず使わない。
501:デフォルトの名無しさん
16/09/03 01:33:50.12 PSgZ0shn.net
>>480
いわゆるモジュールじゃねーっす
エクセルとかもってるならvbe開いてモジュール追加って出来るあれです
んで、開発の仕方みたいなのの情報しりませんか
502:デフォルトの名無しさん
16/09/03 02:08:46.56 AuZUWRpv.net
>>481
OOP学んで適当にファイル分割するのが基本かな
あとは、クラスビューとか定義に移動とかいろんな機能があるから好みの使い方を見つけるしかなさそう
オープンソースとか読むと参考にはなる
こんなに細分化するかーとか、この書き方は初めて見たというのも時々あるので、人の好みがそれなりに強いかも
503:デフォルトの名無しさん
16/09/03 02:11:08.15 FcIsU4jd.net
>>481
ソースファイルを追加したいなら
プロジェクトを右クリックして
追加 - 新しい項目
コード - クラス
で、名前を入れて出来上がり
504:デフォルトの名無しさん
16/09/03 02:21:21.74 PSgZ0shn.net
>>482
あじゃっす
王道なしってことっすね
vbaでつくった1万行程度のプログラムをc#で作り直そうとしたら
にっちもさっちもいかなくて
（最初はbutton click event以下に超長いコードかいてたｗ）
c#サンプルコードでググったやつをいくつか見たんですけどどれも短めで
オープンソースっすか、とたんに難しくなりそうで敬遠してたんですけど、見てみます
>>483
コレダ！
あざーす！
505:デフォルトの名無しさん
16/09/03 02:50:32.40 GFDCUR4+.net
>>483
全然関係ない俺だけどそれ知りたかったありがとう
統合環境超むずい
506:デフォルトの名無しさん
16/09/03 07:36:39.22 FcIsU4jd.net
「新しい項目」って言うのがちょっと思い付きにくいかな
新しい項目って言うのを覚えておけば、右上の「クイック起動」に新しい項目って入れると
プロジェクト-新しい項目の追加...
って表示されるから覚えておくとなんかの役に立つかも
追加でも同じように表示されるけど、追加は他にも
ファイル-ソース管理に追加
とか似たような項目がいっぱい出てきてちょっと探しにくい
507:デフォルトの名無しさん
16/09/03 10:32:43.91 08YRGffV.net
>>485
プログラミングはやめた方がいい。
言語のセンスなさすぎ。
508:デフォルトの名無しさん
16/09/03 12:15:30.20 is8rsJHF.net
波カッコってひょっとして必要なかったんじゃないか
インデントが有ればブロックは表現できるし
波カッコを使うとタイプ量が増えるしネストするとスコープが逆にわかりにくい
C# 8.0ぐらいで良いから波カッコを使わないように仕様を変えて欲しい
509:デフォルトの名無しさん
16/09/03 12:18:06.98 e1RDrry0.net
だったらC#やめてPython使ってろ
510:デフォルトの名無しさん
16/09/03 12:18:56.50 vfo9HhT2.net
pythonが静的言語だったらな
511:デフォルトの名無しさん
16/09/03 12:23:53.71 XJfcWEgm.net
>>488
変えられるわけ無いだろアホか
512:デフォルトの名無しさん
16/09/03 12:28:46.83 is8rsJHF.net
後ろ波カッコのうっとおしさは異常
なんでこんなゴミみたいな記号のために丸々1行も使ってんだと怒りを覚える
513:デフォルトの名無しさん
16/09/03 12:32:05.43 vfo9HhT2.net
ironPythonを静的言語に改造したようなのない？
ないなら作ろうぜ
514:デフォルトの名無しさん
16/09/03 12:49:16.86 bNt+mNAy.net
後ろ波かっこぐらいでうっとおしいと言うのは甘い
XAML見たら発狂するぞ
515:デフォルトの名無しさん
16/09/03 12:49:41.16 h2wll6jz.net
>>492
ブロックの終端を明
516:示するためだろ。導師も言ってるじゃん、「暗示より明示」って。
517:デフォルトの名無しさん
16/09/03 12:53:38.71 28oZslrG.net
作ろうぜって誰に向かって言ってんだ
勝手にテメェでウンコ排出してろボケ
518:デフォルトの名無しさん
16/09/03 13:10:16.03 NvcWw3DB.net
>>492
お前が!存在に状態遷移すれば解決するよ
519:デフォルトの名無しさん
16/09/03 13:29:53.52 vv4I0YMm.net
Pythonのフォーラムで定期的にインデントブロックの代わりに
ブレースブロックを採用して欲しいって要望が出てるくらいには、あれも好かれてないよ
実際にブレースブロックに改造している奴がいるくらいだ
結局は隣の芝が青く見える現象だと思われる
520:デフォルトの名無しさん
16/09/03 13:32:32.69 is8rsJHF.net
要するにどっちでも良いわけだろ
だったらコンパイルオプションで選べるようにしろよ
521:デフォルトの名無しさん
16/09/03 13:33:39.23 XJfcWEgm.net
>>499
お前が実装してプルリクしてみろよカス
522:デフォルトの名無しさん
16/09/03 13:36:43.12 l/8ShBlw.net
ぶっちゃけC言語が嫌われるトップ理由が
｛ ｝ だと思う
523:デフォルトの名無しさん
16/09/03 13:42:35.19 is8rsJHF.net
だよね
{}は利便性が悪いだけでなく見た目も美しくない
524:デフォルトの名無しさん
16/09/03 13:44:11.62 HDnGX34n.net
ネタ投入のつもりなのか、それとも今時パスカルな人なのかな。
そんなにブレース嫌いならVB選べばいいよ。
どうせ出来ることはほとんど違わない。
ラムダ式とか死ぬほど冗長だけどw
525:デフォルトの名無しさん
16/09/03 13:52:01.54 e++gk4lZ.net
後ろ波カッコっていうから
てっきり
if() { ←後置のことかと思ったら
} ←こっちのことか
526:デフォルトの名無しさん
16/09/03 14:36:21.94 bNt+mNAy.net
beginとendを｛と｝に書き換えるプリプロセッサでも作れよ
527:デフォルトの名無しさん
16/09/03 15:17:16.22 e++gk4lZ.net
そういえば大昔のC言語の本では
beginとendを#defineでカッコに置換するというネタが普通に書かれてたとか…？
528:デフォルトの名無しさん
16/09/03 15:24:50.13 HDnGX34n.net
>>506
普通かどうか知らんけどこれだよね
URLﾘﾝｸ(www.pro.or.jp)
529:デフォルトの名無しさん
16/09/03 15:39:03.09 vfo9HhT2.net
インデント>=括弧>>>>>>>>>>>>>>begin,end
begin,endのメリットは全く分からない
530:デフォルトの名無しさん
16/09/03 15:40:48.38 08YRGffV.net
>>508
他の言語との違いを出すための苦肉の策。
531:デフォルトの名無しさん
16/09/03 16:15:14.95 is8rsJHF.net
>>508
目に優しい
532:デフォルトの名無しさん
16/09/03 16:21:08.95 teO92MZf.net
{ }
を透明色にするエクステンションを作れば解決するだろうが！
533:デフォルトの名無しさん
16/09/03 16:44:05.68 GPAGDQ3+.net
バグ死
534:デフォルトの名無しさん
16/09/03 18:58:56.20 abnGTaRM.net
>>507
そうだよ
診断室とここのスレタイの相談室を掛けたんだよ
535:デフォルトの名無しさん
16/09/03 19:57:10.80 i/vdkCcD.net
ASP.NET WebFormsってあるじゃん
入力値の検証コードを書く仕事をやらされてるんだけどさ
何回も何回も同じような(でも微妙に違う)コードを書かされる拷問みたいになってるんだけどこれうまいことDRYできないの？
クライアントサイドのイベントハンドラで検証
サーバーサイドのイベントハンドラやページメソッドで検証
入力モデルにバインドしてローカルサービで検証
といったように少なくとも1リクエストで3回はよく似たコードを書いてる
コントロールが多いエンドポイントだと死んでしまう
536:デフォルトの名無しさん
16/09/03 21:23:26.09 NvN4PBVL.net
>>514
モデルクラスに入れてからまとめて検証すりゃいいでしょ
クライアントサイドはサーバー側でREST API用意しといてAJAXで呼べばいい
537:デフォルトの名無しさん
16/09/04 03:17:01.13 Q23f0Xjy.net
>>514
WEBフォームだろ？
カスタムの検証コントロール作ればいいんじゃないかね
538:デフォルトの名無しさん
16/09/04 14:51:52.34 0IhXUzhb.net
>>516
それは試したけど柔軟性がないから断念した
カスタム検証コントロールではまずクライアントサイドのカスタム検証ができない
それに検証前後に簡単に処理をフックする事ができない
やろうと思えばできない事もないけど自動生成されたコードにアクセスする必要があるからメンテナンスの不安がある
539:デフォルトの名無しさん
16/09/04 19:22:49.84 NWup8pYR.net
>>517
全部サーバーサイドでやればいいんじゃないか？
540:デフォルトの名無しさん
16/09/04 20:26:43.89 Q23f0Xjy.net
>>517
もしかして、CustomVaidatorの話かそれ？
祖じゃなくて、自分で検証するコントロール作れって話だぞ
クライアント用のスクリプトも全部自分で出力できるぞ
これで柔軟性がないってなら、WEBフォームじゃ無理ってことだ
541:デフォルトの名無しさん
16/09/04 20:57:02.22 0IhXUzhb.net
>>519
CustomValidatorの事を言った
もしかしてCustomValidatorってみんな使ってないの？
542:デフォルトの名無しさん
16/09/04 21:18:42.69 Q23f0Xjy.net
>>520
CustomVaidatorでもクライアントスクリプトでのカスタム検証ぐらいできるけどな
毎回似たようなコード書かないとダメだが
この手間と検証タイミングの問題だけクリアできるならCustomVaidatorでも充分だろ
543:デフォルトの名無しさん
16/09/04 21:41:36.27 0IhXUzhb.net
>>521
CustomValidatorもうちょい調べた
クライアントサイドの検証は出来た
でも検証前後に処理をフックするってのがやっぱり出来ない
結局のところカスタムコントロールで検証もやってしまった方が良さそう
544:デフォルトの名無しさん
16/09/10 16:11:25.20 Wm1HNmHU.net
ファイル選択ダイアログを使ったプログラムを組んでいます。
OpenFileDialog ofd = new OpenFileDialog();
.csv ファイルのみ選択可能な状態にしたいのですがこの指定では
エラーになってしまいます。どう修正すれば良いでしょうか？
ofd.Filter = "CSVファイル(*.csv)";
545:デフォルトの名無しさん
16/09/10 16:14:00.08 /+pbEB3C.net
MSDNの解説読もう
546:デフォルトの名無しさん
16/09/10 16:14:42.14 nYtOzCtO.net
openfiledialog 拡張子 制限
でぐぐれ
547:デフォルトの名無しさん
16/09/10 17:18:14.52 Wm1HNmHU.net
>>525
サンクス
解決
548:デフォルトの名無しさん
16/09/10 17:40:43.95 qbdJrNQP.net
っていうか、F1叩くだけでMSDNがすぐ見られるのに
なんでわざわざより手間をかけて2chで質問するのよw
そこが理解できんよw
549:デフォルトの名無しさん
16/09/10 17:47:35.88 nYtOzCtO.net
そら無能だからだよ。そんなこともわからないのかよｗ
550:デフォルトの名無しさん
16/09/12 17:41:15.35 tEgJE/3d.net
素人です
CommonSaveFileDialog で [ファイルの種類] を変えてもファイル名に反映されません
SaveFileDialog のように拡張子を自動で付加できるようにする方法を教えてください
551:デフォルトの名無しさん
16/09/12 17:43:59.26 aOoYdSpX.net
初心者むけのスレがあるよ
ふらっと c#って名前
552:デフォルトの名無しさん
16/09/12 17:45:44.98 6Vx7Y6GR.net
FileAsShellObject.ParsingName
553:529
16/09/12 18:17:48.59 tEgJE/3d.net
>>530
ありがとうございます
今後利用します
>>531
ありがとうございます
しかしながらこちらを使っても結果が FileName と変わらないのです
ShowDialog の後に取得していますが当方の使い方が違ってます？
554:529
16/09/12 18:34:28.38 tEgJE/3d.net
すみません解決しました
DefaultExtension を指定するとおｋなようです
そうしてたつもりがちゃんと出来てませんでした
555:デフォルトの名無しさん
16/09/15 14:24:50.81 NBzoNAq4.net
すみません。Moq について質問です。
インタフェースをMock化した時とか、Setupしていないメソッドやパラメータが呼ばれた時に例外を吐くように設定したいのです。
入り組んでいて、何が呼ばれるのか追いかけるのに疲れました。
例外を吐いてくれれば、Setupしなくちゃと分かるので、デフォルトで例外を吐くような機能があるんじゃないか？
と、ググろうとして・・・思いつきませんでした。
どうすれば良いでしょうか？
・・・とか書いていたら、自己解決してしまいました。
URLﾘﾝｸ(github.com)
に
var mock = new Mock<IFoo>(MockBehavior.Strict);
としろと。
ちなみに
var mock = new Mock<Foo>(MockBehavior.Strict);
とインスタンス化出来る実体があると、そいつのインスタンスを作って、Proxyとして動いてしまった・・・
インターフェース抽出してMock作る必要があるのか。
そして、このレスは某所に誤爆していたものを転載・・・
556:デフォルトの名無しさん
16/09/15 14:32:21.46 QeXjnd/u.net
そういうつぶやきはTwitterがいいと思うぞ
557:デフォルトの名無しさん
16/09/15 14:53:11.09 Spuf+iD1.net
アロエにでも聞いてもらえー
558:デフォルトの名無しさん
16/09/15 21:14:03.89 gHnq4He4.net
Mockフレームワークは仕事を増やすだけ
559:デフォルトの名無しさん
16/09/15 21:57:08.07 Cj/yMtkH.net
モックは自分に都合のいい脳内彼女を相手に恋愛の練習してるようなもんだからな
560:デフォルトの名無しさん
16/09/15 22:11:05.27 18iMvBey.net
夢から覚めなきゃあそれで十分だあ
561:デフォルトの名無しさん
16/09/15 22:28:27.16 xWhZtUbs.net
おじさんが子供の頃樫木モックってアニメがありました
562:デフォルトの名無しさん
16/09/16 07:26:46.50 LunKPrNc.net
脳内彼女が正しい応答をすることをどうやって保証するんだろうな
(return thisを除く)メソッドの戻り値やgetterをあまり使わない「言いっぱなし」が基本の
ガチなOOPならインラインのモックは有効だけど、そうでないなら
普通にボトムアップでやるか、どうしてもモックが必要なところ(IOなど)はちゃんと正しく実装した再利用可能なクラスを作ったほうがいい
563:デフォルトの名無しさん
16/09/17 00:22:09.05 cOwk44uY.net
ユニットテストは品質保障ではなく開発者のためのテストの意味合いが強い
だからモックが正しい動作をするという保障は必要ないんだよ
開発者が納得して開発の助けになればそれでいい
564:デフォルトの名無しさん
16/09/24 11:32:54.80 oYgGfkv1.net
ロジックの奥の方でたまにしか使わないようなのを隅々までテストするには有効
565:デフォルトの名無しさん
16/09/24 14:00:54.96 yvgHPK9s.net
C#のファイナライザって同時に複数のスレッドで走る事ってあるんですか？
またはアプリケーションのスレッドと同時に動く事はあったり？
ファイナライザでスレッドセーフ意識していないコードを書いても特に何も問題は起きていないようなのですが、たまたまでしょうか。
URLﾘﾝｸ(msdn.microsoft.com)
「このため、Microsoft は将来的に、CLR で複数のファイナライザ スレッドを実装することを選択するかもしれません。」
とありますが、これが書かれたのは2005年です。もう変わっていたりして？
566:デフォルトの名無しさん
16/09/24 16:29:11.82 78bORDZY.net
ファイナライザは最後の手段だから、そんな複雑さを伴う処理は書かないのが無難。
567:デフォルトの名無しさん
16/09/24 16:49:31.44 g/gfVTwZ.net
複数のスレッドからファイナライザを呼び出すような作りって、あまり良い作りとは思えないけどな。（ボソッ
568:デフォルトの名無しさん
16/09/24 18:16:20.97 KT7brPF3.net
スレッドセーフかどうかと、再入可能かどうかをごっちゃにしてる気がする。（ボソッ
569:デフォルトの名無しさん
16/09/24 18:45:43.08 K7zHMZhh.net
（ボソッ
↑何これ
570:デフォルトの名無しさん
16/09/24 19:38:48.75 Ww4Eww29.net
プライドと承認欲求と予防線を混ぜて発酵させたもの
571:デフォルトの名無しさん
16/09/24 19:59:25.35 hsY2X9yo.net
(^o^)ﾉ＜つぶしあえー
572:デフォルトの名無しさん
16/09/27 00:41:50.01 rJ2xXuAE.net
階層構造もいい具合に空気読んでマッピングしてくれるマッパーってないの？
573:デフォルトの名無しさん
16/09/27 03:04:59.08 D+6ASUN2.net
string[] arr = { "aa", "bb", "cc" };
として、
var dic = new Dictionary<string, string[]>{
{ "1", arr },
{ "2", { "aa", "bb", "cc" } } // エラー
};
とすると二番目でエラーが出るのですが何故でしょうか？
574:デフォルトの名無しさん
16/09/27 03:19:47.71 w5gpFchP.net
String[]がnewされてないから
575:デフォルトの名無しさん
16/09/27 03:22:44.52 D+6ASUN2.net
>>553
でも一番目はエラーしないのですが。
なぜでしょうか？
576:デフォルトの名無しさん
16/09/27 03:26:44.53 0EtDfixS.net
>>552
{ "2", new [] { "aa", "bb", "cc" } }
{ "aa", "bb", "cc" }だけじゃ、型推論で(stringの)配列か判断出来ない。
arrの方は宣言時に型を指定してる。
577:デフォルトの名無しさん
16/09/27 03:29:00.59 D+6ASUN2.net
>>555
>{ "aa", "bb", "cc" }だけじゃ、型推論で(stringの)配列か判断出来ない。
でも最初に
new Dictionary<string, string[]>{
としているので、二番目の引数はstring[]だと推論出来るんじゃないですか？
578:デフォルトの名無しさん
16/09/27 03:42:17.76 0EtDfixS.net
言われてみたらそうだね。
579:デフォルトの名無しさん
16/09/27 04:22:18.90 9c0zm0tq.net
エラーメッセージ見て推論できないのは頭が悪い
580:デフォルトの名無しさん
16/09/27 04:36:36.79 w5gpFchP.net
確認したら型推論関係なくただの文法エラーだった
581:デフォルトの名無しさん
16/09/27 04:55:56.67 D+6ASUN2.net
>>559
エラーしない一行目のarrをそのまま置き換えたのが二行目なのに
なぜ文法エラーになるのでしょうか？
582:デフォルトの名無しさん
16/09/27 05:04:50.31 w5gpFchP.net
エラーが出た部分をコンパイラが配列初期化子として認識していない模様
同じ文でも構文解釈の位置によって意味が変わることはままある
583:デフォルトの名無しさん
16/09/27 05:35:54.50 jYmbv1HX.net
new string[] {"a", "b"}
を
{"a", "b"}
のように省略できるのはフィールドとローカル変数の宣言時だけ
584:デフォルトの名無しさん
16/09/27 08:16:29.35 l7d7Fmom.net
今時new省略の配列初期化子なんか使わない方がいいよ
型推論が無かった頃の遺物で一貫性がない
585:デフォルトの名無しさん
16/09/27 09:35:34.37 w5gpFchP.net
language specificationを改めて見返したら
配列初期化子のnewが省略できるって記載はないのな
前の版にはあったのかな
586:デフォルトの名無しさん
16/09/27 10:51:33.37 l7d7Fmom.net
>>564
記載があるとしたら変数の宣言や初期化のところじゃない?
new省略の配列初期化子は最近のC#でいう初期化子とは別物で、正確には配列初期化子というより配列型の変数宣言の特別な形だと思う
587:デフォルトの名無しさん
16/09/27 22:01:53.19 SnclXywq.net
Cから入ってテキスト何冊か終わらせてからC♯にきたけど、
Cよりも感覚的に理解できるように作られていると感じた。
だがやっぱりCと混同してしまう部分が多くて困るな
学習が進めば頭の中で区分できるようになるんだろうが
相談じゃないな すまん
588:デフォルトの名無しさん
16/09/27 22:33:12.99 zETe1SmY.net
CもC#も大差ない
便利な構文やクラスが沢山あるってだけ
明確な違いはメタデータぐらいじゃないかな
589:デフォルトの名無しさん
16/09/27 22:42:28.47 0EtDfixS.net
GCは?
590:デフォルトの名無しさん
16/09/27 23:15:25.90 +YkJQBGH.net
*や[]や関数ポインタが絡んだときの宣言みたいな汚くて読みづらい文法がないだけ
C#の方が理解しやすいよね。
配列も文字列も普通に型だし。
591:デフォルトの名無しさん
16/09/27 23:44:37.52 YTcGpOzN.net
>>567
大差ある
592:デフォルトの名無しさん
16/09/27 23:46:25.85 tLj3yCec.net
文字列はchar配列らしいけど、配列は型じゃないの？
Cって配列型じゃないの？
593:デフォルトの名無しさん
16/09/27 23:48:59.35 l7d7Fmom.net
Cに配列型なんか無いよ
連続領域の先頭を指すポインタを配列に見立てているだけ
594:デフォルトの名無しさん
16/09/27 23:50:01.43 tLj3yCec.net
それC#でも同じじゃない？
C#でも
var arr=new int[n];
でarrに入るのは参照だし
595:デフォルトの名無しさん
16/09/27 23:51:25.88 l0rgfbC+.net
文法とか変数とか型とかポインタはどうでもいいがイベントが楽だからC#からCに移ろうとは思わないな
596:デフォルトの名無しさん
16/09/28 00:16:59.13 2rDNP5fm.net
>>570
ないよ
出来ることは変わらない
書くのが楽か面倒か
それだけ
597:デフォルトの名無しさん
16/09/28 00:55:28.97 x7JpDQQH.net
>>575
それってc#もCOBOLも大差ないって言うのと同じことだよね
598:デフォルトの名無しさん
16/09/28 01:03:23.10 CvBOyBja.net
大差ありすぎてワロタw
599:デフォルトの名無しさん
16/09/28 04:44:15.09 y3I7X+UO.net
大差の定義によるな
600:デフォルトの名無しさん
16/09/28 05:07:27.92 ksAc0l/t.net
ネイティブコードにコンパイルできるか否か
弱い静的型付けか強い静的型付けか
オブジェクト志向か否か
GCあるか否か
ぱっと思いついた違い
601:デフォルトの名無しさん
16/09/28 06:19:58.62 2rDNP5fm.net
全部同じじゃんそれ
602:デフォルトの名無しさん
16/09/28 07:16:59.51 6UKmmY9W.net
>>575
> 書くのが楽か面倒か
大差あるやん w
603:デフォルトの名無しさん
16/09/28 08:00:45.42 Iarxs+Xo.net
>ネイティブコードにコンパイルできるか否か
これはまあ、言語じゃなくて環境の問題ではあるけどな
理屈の上では、C#からネイティブコードを吐き出すコンパイラを作る事も出来る
絶対やらないだろうが
604:デフォルトの名無しさん
16/09/28 08:02:41.33 Iarxs+Xo.net
……と思ったけど
Microsoft .NET Native とかあったなそういや
605:デフォルトの名無しさん
16/09/28 08:31:46.55 hdyJqyrv.net
とっくにUWPアプリはネイティブですよ。
606:デフォルトの名無しさん
16/09/28 08:34:31.32 Ks5fZMDV.net
なにそれおいしいの？
607:デフォルトの名無しさん
16/09/28 09:05:27.32 ksAc0l/t.net
型付けの強さ弱さを同じって言われて俺びっくりしちゃったよ
608:デフォルトの名無しさん
16/09/28 09:37:17.20 nPlGLTXy.net
>>585
レイアウト変更のもたつきなどの、C#特有のもっさり感がないよ
609:デフォルトの名無しさん
16/09/28 09:47:06.51 JharV+Ri.net
作ったUWPアプリ環境によってインストールできなくて挫折したな
610:デフォルトの名無しさん
16/09/28 11:10:40.15 RDlboUCA.net
Cって静的言語だから型は同じじゃないの？
611:デフォルトの名無しさん
16/09/28 16:45:21.87 wFbSwOZd.net
汎用デリゲートのEventHandlerを使用した場合のメリットについて教えてほしいのですが、これを使用するとデリゲート定義の1行を省けることを超えるメリットはあるのでしょうか？
612:デフォルトの名無しさん
16/09/28 17:43:08.72 t2Y8uX7u.net
>>590
発想が逆立ちしてるよ。
普通は、標準で用意された方法を超えるメリットがないのであれば
あえて独自のデリゲートを使う理由はないと考えるんじゃないの？w
それって車輪の再発明そのものだよねw
613:デフォルトの名無しさん
16/09/28 18:34:02.96 1e7C4OQD.net
いやまて、イベント以外のデリゲートに使おうとしてるのかもしれんぞｗ
614:デフォルトの名無しさん
16/09/28 18:55:03.29 wFbSwOZd.net
そうか、標準のもので済めばそれを使うのが当然なのか
根本が間違ってた
ありがとう
615:デフォルトの名無しさん
16/09/29 15:45:21.13 GKXbaAQ5.net
>>569
それを汚ないと感じる人と
美しいと感じる人もいるんじゃないか？
616:デフォルトの名無しさん
16/09/29 18:05:53.95 42KzZhvK.net
>>594
void (*signal(int sig, void (*func)(int)))(int);
美しいかどうかは美的感覚の問題だから人それぞれとしか言えないが、
少なくとも俺は上みたいな宣言を見せられたとき、これが何を意味しているのか
瞬時には理解できない。
「汚い」っていうのはそういうことを表現したつもり。
617:デフォルトの名無しさん
16/09/29 19:40:25.50 wDlER99I.net
URLﾘﾝｸ(kmaebashi.com)
これを読んだうえでCのポインタの文法が美しいと感じる奴がいたら逆に凄い
618:デフォルトの名無しさん
16/09/29 19:54:22.23 iqK/HxMj.net
コード見たときにそれが何を指してるのか分かりやすいのはCの方だな
619:デフォルトの名無しさん
16/09/29 20:14:20.56 /kH+f7Ja.net
>>595
ああああああ
なつかしいいいいい
UNIXもしくはLinuxか何かでみたぞおおおおおお
もう絶対こんな仕事に戻りたくないぃいいいいいい
620:デフォルトの名無しさん
16/09/29 20:22:33.12 1Mz/tgYS.net
コードの動作が分かりやすいのはC
コードの意図が分かりやすいのはC#
言語の差というより、コードをマシンへの命令と考えるかプログラマの意図を表現するものと考えるかという意識の違いが大きいと思う
do if (*src != ' ') *(dest++) = *src; while (*(src++));
Cはこういうの平気で書き散らす基地外が多い
621:デフォルトの名無しさん
16/09/29 20:29:29.53 /kH+f7Ja.net
K&Rの時代は終わったんだよ
622:デフォルトの名無しさん
16/09/29 21:34:42.13 IEWEZKBK.net
20年前にFM-TOWNS()でCから入ったが今の時代にガキだったらCだのC++だのは一切触らなかっただろうなーと思う
かといってphpやjavascriptから入るのはアレだしc#最高＾＾
623:デフォルトの名無しさん
16/09/29 21:37:33.67 o/Z16MWz.net
>>599
いやそのコードはおかしいけどな。多分以下。
while (*src!=0) *dest++ = *src++;
それをキチガイというのは自由だが、Cならこれを読めない奴は馬鹿扱いだよ。
初心者は常に「自分の読めないコードは、コードが悪い」としか言わないのだけど、
実際はその初心者の技術レベルに問題がある場合の方が多い。
599はこれだね。
624:デフォルトの名無しさん
16/09/29 21:57:51.11 iqK/HxMj.net
読めないのは馬鹿ってのは同感
そういうのを書き散らすのは基地外ってのも同感
625:デフォルトの名無しさん
16/09/29 22:01:24.13 1Mz/tgYS.net
>>602
いや599はスペースを除去してるんだけどな
正直わざと分かりにくく書いたから602の技術レベルを疑うつもりはないけど、
分かり難さを証明してくれてどうもありがとう
626:デフォルトの名無しさん
16/09/29 22:02:54.74 Js+ntQYt.net
>>602
完全にスレ違いだけど、そういう同じポインタを2回手繰ってるのって
コンパイラは最適化してくれるのかな。
っていうか
while ((*dest++ = *src++) != 0);
って書いても読みやすさは変わらないと思うんだけど
627:デフォルトの名無しさん
16/09/29 22:05:00.53 Js+ntQYt.net
ああ、0コピーしたらダメな場合は使えないのかw
ボケてるな
628:デフォルトの名無しさん
16/09/29 22:37:37.49 o/Z16MWz.net
>>604
ああよく見ればそうだな。てかスペース見えんかった。
俺はプログラミングは固定ピッチフォントでやる派なので。
つか脱線でさらにスレチだがC++の開祖がプロポーショナル派で、
「プログラミング言語C++」もそれで印刷されているのだが、読みにくくてかなわん。
>>605
俺は余り詳しくないのだが、その範囲で話をすると、
K&R第2版P129には、そういう場合は
while (*dst++ = *src++)
にしろと書いてあるわけだが、実際はこの書き方はwarinigが出る環境の方が多いと思う。
したがっておそらく最適化はやってもらえる（はず。volataileでない限り。）
>>595も本来はtypedefやマクロを使えばもっと綺麗に書けるし、多分それが普通。
悪い例を出しても言語間の比較にはならないよ。
どの言語でも糞な書き方は出来るから。（比較的C#はそうなりにくいのは認めるが）
629:デフォルトの名無しさん
16/09/29 22:39:05.84 o/Z16MWz.net
>>607
すまんセミコロン抜けてた。
while (*dst++ = *src++);
630:デフォルトの名無しさん
16/09/29 23:01:59.93 AR+VWIbJ.net
なんのスレなんだここ
631:デフォルトの名無しさん
16/09/29 23:05:32.42 URePwP35.net
Swiftでも++は削除されたし、考え方次第なんだよなー
近代的な文法がないCではしょうがないんだろうが
632:デフォルトの名無しさん
16/09/29 23:40:01.94 o/Z16MWz.net
>>610
マジ？と思って調べたら、どうやらそのようだ。つか、Pyshonも無いんかよ。
URLﾘﾝｸ(github.com)
Cとは生まれた時期も目的も異なるからどちらがいいという問題ではないが、
Cで問題だった箇所を一つずつ潰すのも新しい言語のやるべき事だよ。
主張はそこに書いてある。同意するわけではないが、まあそういう見方もあるわなくらいには思う。
ただCは何だかんだで多分生き残る。
あれはほぼアセンブラで、限界までチューニングするにはあの記法が必要だから。
対してC#やSwiftやPythonは生産性/可読性重視だから、
おそらく次の新しい言語が出てきたら取って代わられる。
「近代的」っていうのはそういうこと。時間が経つにつれて「前近代的」になる。
これは近代的言語の宿命だね。
そしてCは「前近代的」でも生き残る価値があるから現存している。
ただ、++で問題を感じたことはないんだけどな。
そこの例に挙げられている
> foo(++a, a++)
をやる奴は死ねでいいけど、
これは引数の評価順を規定してないのが問題で、別問題。
633:デフォルトの名無しさん
16/09/30 00:10:14.41 cU7plTv4.net
Pyshonて何だよ？と思ってggったら、ホントにあるのな。
634:デフォルトの名無しさん
16/09/30 00:22:32.29 WN9yrU4I.net
Cがわかりにくいのって記号が物理的に見にくいだけだろ
概念的な難易度はC#と変わらん
635:デフォルトの名無しさん
16/09/30 00:51:09.49 27JQ5kO2.net
Perl「特に見にくくなんて無いよ」
636:デフォルトの名無しさん
16/09/30 03:34:02.05 gTc+8iAX.net
>>595
調子こいたラムダ式とかもだめだよな！
637:デフォルトの名無しさん
16/09/30 06:37:26.14 4hxo3I+i.net
結局プログラマの能力の問題
現状だと調子こいたラムダ式書ける奴は比較的スキルが高いからコード綺麗だよ
638:デフォルトの名無しさん
16/09/30 06:55:45.86 Y6l190wq.net
c#でウオッチ１には表示されるのですが、
ウオッチ２や３のウインドウにもウオッチさせる方法を教えてください
639:デフォルトの名無しさん
16/09/30 08:30:41.85 2XfoFLHG.net
コードのキレイ汚いは感覚論だから議論しても仕方がない
でもラムダを使ったコードはコードの重複が少なく結合が弱いから誰が扱っても保守しやすいプログラムになるのは確かだね
640:デフォルトの名無しさん
16/09/30 09:34:42.41 2XfoFLHG.net
何より言語やライブラリ、フレームワークがラムダを当たり前の存在として扱っている以上使わないという選択肢はない
キレイ汚いという個人的感情によるワガママは通じないのだ
641:デフォルトの名無しさん
16/09/30 09:50:48.57 XrkqBYg2.net
○○を使ってたら汚いコードになるってことじゃないんだよな
そういうことがわかってないと汚いコードになる
642:デフォルトの名無しさん
16/09/30 10:10:00.28 Ik8fs/0i.net
それより審美眼の足りない奴を蹴り出した方が効果的
643:デフォルトの名無しさん
16/09/30 20:45:54.67 0SPCdJff.net
審美眼でコードを書くやつはプロジェクトから追い出したほうがいいって
20年前から言われてる
K&Rのコードはさんざん批判されてる
ここは20年前のスレか
保守性の高いだれでも理解しやすいコードを書ける奴が優秀
644:デフォルトの名無しさん
16/09/30 23:00:54.25 bXY+Fxkm.net
× > 保守性の高いだれでも理解しやすいコードを書ける奴が優秀
○ 馬鹿な俺でも読めるコードを書ける奴が優秀なことにしたい
K&Rのコードが「汚い」という批判はないと思うが。あれはあれで美しい。
勘違いした馬鹿が闇雲にトリッキーなコードを書いたり、
(今まさに関数型()の奴らが同じ事をやっているが）
或いはタイプミスなのか意図的なのか分かりにくかったりするのが問題なだけ。
これらは色々warning等を出して対応されてきた。もちろん最初からSyntaxErrorならそれでよい。
そして「コードが汚い」ってのは今言っているようなせいぜい10数行の局所区画のことではなく、
もっと大きな上位区画での話だろ。意味不明なクラス構成とか。
というか、10行程度のコードなら多少汚くても読めるし、
正しく抽象化されて階層が分かれていれば、
そういうローレベルコード（何かのメソッド等）は一度読んで動くのが分かればそれでおしまいだろ。
問題はそれらを駆使するミドルレベルコードがグダグダな方だと思うし、
それを「コードが汚い」と表現するのだと思うが。
645:デフォルトの名無しさん
16/09/30 23:01:33.75 bXY+Fxkm.net
というか多分お前らは「自分が読めるコードが綺麗なコード」とする初心者に近い奴が多いのだと思うが、
実際の所、腕のいい奴は「書ける範囲で綺麗なコード」にしているわけで、
結果的に綺麗なだけなコードならいくらでも綺麗にかけるし、
高速化が必要なら多少汚くなっても最適化を施していく。
だから「汚い」と批判するのはそれ以上の物を自分で記述できるときだけにした方がいい。
K&Rに関しては実行速度/リソースについて最適化を施されているわけだから、
それよりも少ないリソースで速く動くソースが書けないのなら、「汚い」とは言うべきではない。
それが読めないのはお前が馬鹿だから。
少なくともそれを書いた奴はお前よりも腕前は上なわけで、
お前でも読めるようなコードを彼等が書くことは可能なわけだし。
例えばソートとか。
APIとして呼ぶ分には中身がどうであれ正しく速く動いてくれればそれでよし。
それが非常に読みにくい物でも、正しく動く限り、速い方が選ばれる。
それを読み�
646:ﾉくいだけの理由で「汚い」とするのはナンセンスでしょ。 K&Rのトリッキーなコードは本来はこういう区画にしか現れないものだよ。 そしてそれは「ソート」として分離されるから、その中身がどんなに汚くても、開発の障害にはならない。 「コードが汚い」ってのは、つまり「これじゃあ今後手を付けられません」って意味だろ。 ソートみたいな局所区画でこれがあてはまることはない。 （実際「汚い」＝「読みにくい」のと、 「コードが汚い」との批判＝「開発の障害になる」との意見は別物のはず） 問題は、例えば、「ラムダを使うべき場所でラムダを使ってない」とか、逆に、 「ラムダを使うべきでない場所でラムダを使っている」とか、だろ。 要するに簡単な方を使えばいいだけなのだけど、 意識高い奴は「○○の方がいい(ｷﾘｯ」とか言って無理に使うからおかしな事になる。
647:デフォルトの名無しさん
16/09/30 23:05:31.58 GrCnAQwz.net
ポエマーきもっ、まで読んだ。
648:デフォルトの名無しさん
16/09/30 23:08:03.45 Fmt1sBQd.net
コードだけでなく2chレスも読みにくいわw
649:デフォルトの名無しさん
16/09/30 23:08:46.30 IoizK4x5.net
もちろん昔と同じように考える分野もあるけど、多くの場面じゃ昔と今は考え方が違うのよ
650:デフォルトの名無しさん
16/09/30 23:10:25.66 GrCnAQwz.net
っていうか、説明的な文章を簡潔かつ過不足なく書く能力と
可読的なコードを書く能力はおそらく無関係じゃないと思う
何が言いたいかはお察しくださいw
651:デフォルトの名無しさん
16/09/30 23:13:28.59 EbLE8W48.net
・ソースが汚いとはクラス構成が変などの大きな区間の事であり10行程度なら問題ない
・多少汚くても速い方がいい
・新機能を無理に使うと汚くなるからやめろ
でおｋ？
652:デフォルトの名無しさん
16/09/30 23:15:30.37 OobEUz+z.net
むしろこんなに書き込めるんだな
あれか？最新に出てくる画面に1レスだけで全部埋めたりできるのか？
653:デフォルトの名無しさん
16/09/30 23:28:51.36 IoizK4x5.net
>>629
行数の問題じゃない。1行でも汚いのはあるし、変数名一つとっても汚らしいのがある
今は遅くても可読性、拡張性、保守性を重んじるケースの方が多い
新機能は汚いわけじゃない。互換性とかそれまで認知されてなかったトラブルを産む原因になるだけ
654:デフォルトの名無しさん
16/09/30 23:41:02.45 bXY+Fxkm.net
>>629
・「ソースが汚い」と批判される場合は
全体的にナンセンスか必要のない箇所で最適化をしている場合。
必要な箇所での最適化で結果的に著しく可読性が落ちたとしても
「ソースが汚い」と批判されることはない。
・速さが必要ない箇所では最適化せずに、一番単純な記述にしろ。
・新機能は便利だから追加されたのだから、積極的に使えばいい。
ただし使えばいいって物ではない。
655:デフォルトの名無しさん
16/09/30 23:44:22.04 Mpnnp+Nc.net
仕様上どうしても実行速度が必要な部分を除いては、可読性の高さは実行速度より優先されるべき
656:デフォルトの名無しさん
16/09/30 23:56:07.59 bXY+Fxkm.net
>>633
同意。
なんか早すぎる最適化はうんたんってのがあるんだろ。
コードの9割以上は速度はどうでもいい箇所なので、可読性をとるべき。
糞どうでもいい箇所をこねくり回してワケワカメなコードにする奴はハゲろ。
(言っちゃあ悪いが関数型()な奴はこれをやっている気がものすごくする)
あと言語のポリシーにもよるでしょ。
C#はC程のチューニングをする為の言語じゃない。
それこそ、C#なら全箇所で(速度は全く気にせず）可読性重視というのもありだと思うよ。
そもそもどうしても速度が必要ならCでDLL書いた方が速いし早い。
657:デフォルトの名無しさん
16/10/01 01:11:38.55 TCy40dPy.net
コードの綺麗さは実は定量化できる
わかりやすいので言えば重複するコードがどれぐらいあるかとかな
658:デフォルトの名無しさん
16/10/01 01:26:55.75 5I4x+GEM.net
関数型は親の仇、まで読んだ。
いつの間にか老害になってた、ってのもよくある話。
659:デフォルトの名無しさん
16/10/01 02:28:35.54 tNbhSEQ7.net
>>623,624の可読性は定量的に表すといくつですか？
660:デフォルトの名無しさん
16/10/01 02:48:45.62 MIaIeT8n.net
3
661:デフォルトの名無しさん
16/10/01 04:34:25.08 Cx/cD9Km.net
評価に価しない
662:デフォルトの名無しさん
16/10/01 07:03:52.26 aUiPvlDm.net
要するにアンチパターン
663:デフォルトの名無しさん
16/10/01 13:30:51.56 b8SZy0Th.net
>>623
コードに審美眼とかうるさい奴は死にかけのPerlに行けよ
死ぬ程美しいコードだらけだぞ
副作用だらけの可読性や保守性が全然ない糞みたいな世界にいけばいい
664:デフォルトの名無しさん
16/10/01 17:32:33.06 YSehcX6B.net
>>615
調子こいたラムダ式ってどの程度のものを指していますか？具体例を教えて下さい。
665:デフォルトの名無しさん
16/10/01 17:44:54.07 uFiZxscE.net
たぶん「調子こいた『ラムダ式』」では。
666:デフォルトの名無しさん
16/10/01 17:45:58.08 j4WTV/sN.net
ラムダ式の中でも特に調子こいてる物、って事でなくて
ラムダ式自体が調子こいた代物だ、って事かい
667:デフォルトの名無しさん
16/10/01 17:49:57.84 oe6ViUtA.net
匿名メソッドはOKなんですねよかった
668:デフォルトの名無しさん
16/10/01 17:53:16.74 aSQFFfFE.net
>>644
ひでーｗｗ
669:デフォルトの名無しさん
16/10/01 18:08:55.65 j4WTV/sN.net
俺の意見じゃなく、>>643を噛み砕いただけだからね
まあ俺も酷いと思うわｗ
670:デフォルトの名無しさん
16/10/01 18:13:22.35 r6T55aIp.net
ラムダ式「今夜はザキンでシースーよ」
ということですね
671:デフォルトの名無しさん
16/10/01 18:27:04.12 uFiZxscE.net
ザンギにソース？（北海道民感）
>>647
その言い方だと俺が酷いようにみえるんだけどｗ
672:デフォルトの名無しさん
16/10/01 18:27:22.17 73eR6yvK.net
牛乳を買ってきて卵があったら6個買ってきてね
これで牛乳を6個買ってきた話のようだ。プログラマーってのはめんどくせーなw
673:デフォルトの名無しさん
16/10/01 18:36:06.66 uFiZxscE.net
それは解釈の違いの問題じゃなく、
単なる勘違いというか記憶ミスの話じゃないのか
674:デフォルトの名無しさん
16/10/01 18:47:50.99 MIaIeT8n.net
変なパーサー使ってるんだな
675:デフォルトの名無しさん
16/10/01 19:02:47.22 hMWB8YVJ.net
最後の買ってはコンパイルエラーにしてほしいな
676:デフォルトの名無しさん
16/10/01 20:25:31.09 YSehcX6B.net
ラムダ式使うと調子こいてるヤツと思われるのはit業界の常識ですか？
677:デフォルトの名無しさん
16/10/01 20:27:03.31 R05VqS28.net
>>654
うんにゃ
678:デフォルトの名無しさん
16/10/01 20:34:55.43 roKi/w2g.net
コードの流れに唐突にラムダ式入ってくると邪魔だなって思う
長い奴はメソッドにしてにラムダ式で呼べって思う
679:デフォルトの名無しさん
16/10/01 20:35:59.82 rH9xy5Nb.net
>>654
イテレーター業界？
680:デフォルトの名無しさん
16/10/01 20:38:04.48 roKi/w2g.net
メソッド書かないで引数内で追加できてよかったと思う人もいるんだろうか？
681:デフォルトの名無しさん
16/10/01 20:41:46.11 rH9xy5Nb.net
ラムダ式なしでWhere()とかSelect()使うの苦痛だわw
682:デフォルトの名無しさん
16/10/01 20:44:48.07 wmtSdepv.net
>>650
それとぃってｒで見た
683:デフォルトの名無しさん
16/10/01 20:52:06.40 roKi/w2g.net
>>659
そういうのは調子乗ってると思わないけどｗ
684:デフォルトの名無しさん
16/10/01 22:32:32.05 uFiZxscE.net
普通にメソッド書いたほうが見通しスッキリするんじゃねー？
と思うコードはある、かな……
685:デフォルトの名無しさん
16/10/02 00:04:13.32 ROqN57Sm.net
delegateの演算子オーバーロードは出来ない？
例えば
Func<string, int> f1 f2
な時に
f = f1 | f2;
stringの値によって、f1またはf2を呼び出すfをつくる
みたいな事がしたい。
686:デフォルトの名無しさん
16/10/02 00:31:44.31 jkLbSgMw.net
デリゲートはクラスじゃないから無理でしょうね
c#は関数呼び出し演算子()のオーバーロードもできないからクラスで実装するのも無理
c++なら出来るんだがね
687:デフォルトの名無しさん
16/10/02 04:26:34.74 jWIE31Om.net
トリッキーな脱出条件の再帰コードを見た事がある
見た目はスッキリしてるけどバグを誘発しそうで怖い
688:デフォルトの名無しさん
16/10/02 06:52:07.42 2n6hXS15.net
>>664
そんなトリッキーなことするバカが出ないようにってこと
689:デフォルトの名無しさん
16/10/02 10:05:52.02 jkLbSgMw.net
個人的には別にトリッキーだとは思わないけど
むしろ美しい
URLﾘﾝｸ(ideone.com)
690:デフォルトの名無しさん
16/10/02 10:54:34.82 eq6TYNRH.net
>>667
"個人的"だね、ほんと
691:デフォルトの名無しさん
16/10/02 11:55:26.61 O3UtDhl/.net
個人的だねとの判断も明らかに個人的なものであるが、これいかに
692:デフォルトの名無しさん
16/10/02 12:01:52.13 RfLsthU9.net
>>667
分かりやすくて良いと思う
この辺りをどう感じるかは文理学歴の差が大きいと思う
693:デフォルトの名無しさん
16/10/02 12:07:04.04 aauDOAhV.net
>>667
それって記法上のメリットしかないだろ？
だってベタに書こうと思えば書けるし、大した手間でもない。
だからそういう糞ユーザーの「俺カッケー」を出来なくしてあるのがC#だよ。
inline f
f1(f2(3))
3*f2(3)
3*f1(3)+2*f2(3)
そのコードはテンプレート部(40行目以前)が完全に動くならそれでいい。
ただしそれが保証出来ないのなら、いちいち見ないといけなくなる。
つまり糞ユーザーの「俺カッケー」に付き合わされることになる。
そういうのが開発効率を落とすと判断し、C#は出来なくしてある。
そういうのも含めて全部出来るようにしているのがC++。
C#の判断も一理ある。
694:だから賛同するならC#を使えばいい。 いやならC++を使えばいいだけ。 このケースに関しては、やっていることはOOPスレの10と同じ。 http://echo.2ch.net/test/read.cgi/tech/1467992113/10 便利なことをしているつもりが余計に手間を増やしている。 初心者はこの判断が付かないんだよ。だから1行/1文字でも減らそうとする。 なお俺はその記法について文句を言っているわけではない。 それがシステム側で「バグのない物」として提供されていれば、使えばいい。 ただ、オレオレ記法をしたいだけの為にバグがあるかもしれない物を出されたらウザイだけ。
695:デフォルトの名無しさん
16/10/02 12:25:34.26 OGpfvvty.net
こういう流れを見るとやっぱ文理学歴の差って大きいんだなって実感する
696:デフォルトの名無しさん
16/10/02 12:42:14.69 jkLbSgMw.net
オレオレ記法じゃなくて数学的な記法をプログラムに持ち込んだだけなんだけどね
後バグがあるならやめてほしいと言うけど特にc++規格に明示されてない文法を使ってるってわけでもないし
関数オブジェクトとか（この場合可変長テンプレートとか）を見慣れない人にはトリッキーに見えるだけだと思うな
697:デフォルトの名無しさん
16/10/02 12:52:17.12 +f7TOXbf.net
分かりにくいというか曖昧すぎて理解のしようがない
関数の和や合成と言われても、引数適用や合成の仕方は無数に考えられる
全てがオレオレのフィーリングに基づいた暗黙脳内ルールじゃん
むしろ理系こそ拒否反応起こすわ
698:デフォルトの名無しさん
16/10/02 12:54:43.75 I2UZY42b.net
そう言うことを頻繁にやるならアリだと思うが過去そう言うことをやったことない俺にはできてもできなくてもあまり変わらん
バグまで持ち出して反論してる >>671 はちょっと頭弱い子だと思う
699:デフォルトの名無しさん
16/10/02 12:57:57.60 aauDOAhV.net
>>673
数学の合成関数は f(g(x)) だろ。アホなのか？
700:デフォルトの名無しさん
16/10/02 13:07:15.54 aauDOAhV.net
>>673
なお俺はトリッキーだとは言ってない。
バグを誘発する糞コードを読まされる手間が増えるだけだからウザイと言っている。
その件に関してはベタで書いた方が「全体的には」楽だろ。それだけ。
初心者はこの「全体的」が分からないから局所的な最適化コードに異様にこだわるだけ。
それだけで済んでいればいいけど、通常はそれだけじゃ済まないんだよ。
そして泥沼化するから、C#では最初から禁止している。それだけ。
まあ妥当だと思うよ。
701:デフォルトの名無しさん
16/10/02 13:08:59.70 FGg7v3h+.net
まあラムダがあれば簡単な関数合成する上で特に不便はないな
C++はラムダがない時代が長かったからオペレーターオーバーロードなどを駆使して表記の簡略化、統一化を考える必要があった
702:デフォルトの名無しさん
16/10/02 13:17:42.00 +f7TOXbf.net
演算子オーバーロードの濫用の問題は、全く一般的でないオレオレルールが+などの非常に一般的な表現でコードに撒き散らされることだよ
少なくとも俺には f=f1+f2 と書かれても何のことかさっぱり分からん
うまいこと空気読んで共感してあげるという高度な文系的センスが求められる
703:デフォルトの名無しさん
16/10/02 13:34:10.10 aauDOAhV.net
ちなみにC#からの見方に変えると、
C#の開発時には既にC++があったわけだから、
templateの有効性や演算子オーバーロードの利便性を知らなかったわけではない。
ただ、馬鹿が調子こいて余計に手間が増えることの方が多いと判断したから、落とした。それだけ。
「出来る」ことと「便利になる」は別なんだよ。だから結局の所プログラマ次第。
そして「自前クラス」まで禁止するとstaticおじさんになるというわけさ。
これについてはJava側からの視点で批判的な物が多いけど、
おかしなクラス構成ばかり見せられたら自前クラスも禁止したくなるだろ。
実際、OOPスレ10に対してなら
「お前がクラスを作ることは禁止、どうしても欲しければ相談しろ」というのも現実的な線だよ。
要するにメタプログラミング系は本来は熟練者しか使っちゃいけないのさ。
初心者が「template使える俺カッケー」をするからおかしな事になる。
それってtemplateを使うこと、或いは短く書くことが目的になってるだろ。
手間を減らすこと、コンパクトに書いて規模の限界を緩和することを目的にしろって事だよ。
(クラスも程度は軽いけど結果的に自前フレームワークを用意するという点でメタプログラミングと似ている)
704:デフォルトの名無しさん
16/10/02 13:39:28.09 jkLbSgMw.net
関数の合成といえば(f◯g)(t)=f(g(t))だし
「線形結合できる関数」クラスの例で
関数の和といえば(f+g)(t)=f(t)+g(t)だし数学的にこれ以外ないでしょ
合成はc++に◯記号がないから|を代わりにしただけ
あとあのコードがまるで「普通」のコードよりもバグを誘発しやすいみたいな言い方してるけどなぜそう思うの？
単に見たことない書き方だからそう思ってるんじゃないの？
数学についても、プログラムについても単に知らない人が拒否反応を起こしたり分かりにくいといっているように感じるんだが
705:デフォルトの名無しさん
16/10/02 13:41:46.38 aauDOAhV.net
>>681
てかお前数学知らないだろ？
○って何？ドットなら関数内積で、合成関数ではないぞ。
706:デフォルトの名無しさん
16/10/02 13:43:56.45 aauDOAhV.net
あ、2chで表示できないのだろうからunicodeで頼むわ。
707:デフォルトの名無しさん
16/10/02 13:49:48.57 jkLbSgMw.net
U+2218
URLﾘﾝｸ(www.fileformat.info)
708:デフォルトの名無しさん
16/10/02 13:56:01.58 Tg5OdweU.net
コードの細かい記述方法であれこれルール作りたがるとかチラ裏でやってほしいわ
他人から見たら全く役に立たない
709:デフォルトの名無しさん
16/10/02 14:03:39.03 aauDOAhV.net
>>684
ああこちらでも確認した。そういう表記をすることもあるようだ。
俺は知らんが。
ただ、そういうのを | で代用するようなことをするから演算子オーバーロードは駄目なんだよ。
それが欲しければ、そのコードをそのまま使わないといけない。
そうじゃないと、お前のオレオレクソコードを全員が読まないといけなくなるだろ。
例えばJavaScriptなら、ソースコードはunicodeなのでそれが出来る。
function ○(func0, func1){}
だからその件に関する正しいやり方は、unicode版C++で○を演算子としてサポートすることだ。
ただ、f(g(x))と書けばいいだけのことを新しい演算子を定義するのは無駄だ。
だから現実的にはunicode版C++で○をマクロ等で合成関数に置換することだろう。
(unicode版C++があるかどうかは知らん）
710:デフォルトの名無しさん
16/10/02 14:04:19.38 FGg7v3h+.net
>>680
cppからcsへの変遷の際に危険だが柔軟性の高い機能が取り除かれた理由は、調子こいたバカが増えるからではなく、基本的なスキルのないプログラマが使うことを前提にしたってだけだろう
上で出た関数合成の例だってまともに仕事してるcppプログラマならなんの苦もなくよめる
おや、数値型以外の型に+演算子が定義されているぞ
ああ、オーバーロードしたのね
まっ、文脈から関数合成で、よほどひねくれてなきゃ線形結合だろう
いちお、確認するか…仕様書は…ない
ならソースみよか…(10秒ほど定義を眺める)…うん、さっきの解釈で良いみたいだね
よし、じゃあ楽に見やすくなるならガンガン使おう
cppが出来るレベルではこれが普通の反応であって、読めないという泣き言はプロである以上通じない
csだと逆に、Linqとかあたらしいのわたしよくわからないので禁止！といったようにバカがわからないというだけで、自作の便利なライブラリどころか、標準的なライブラリすら使えなくなってしまう
世間的には同じプログラマとして分類されるけど生きる世界が違うんだよ
711:デフォルトの名無しさん
16/10/02 14:06:04.74 ROqN57Sm.net
自己が見慣れないものを、一見汎用性のありそうな�
712:ｳ知な屁理屈つけて拒否しるのって、老化の始まりなのかな。 自戒の意味も込めて。
713:デフォルトの名無しさん
16/10/02 14:09:00.42 FGg7v3h+.net
>>686
さっきからちょっと気になってたんだが
関数を合成するのと関数の評価を続けて行うのは全く別の処理だぞ
どの記号を使うべきか、そもそもオバロすんなとかいう議論以前の話で間違ってる
714:デフォルトの名無しさん
16/10/02 14:20:35.82 +f7TOXbf.net
>>687
そういう考えは規模が大きくなると破綻する
関数合成をする操作があっちゃいけないとは思わないが、定義を思い出すのに十分なラベルを付けるべき
1,2文字の記号と、離れた場所にある型宣言だけではあまりにもヒントが少なすぎるし、演算子は名前空間が小さすぎる
715:デフォルトの名無しさん
16/10/02 14:25:11.07 aauDOAhV.net
>>687
なんかC++の奴らは「選民思想」を持っているようだけど、それは違うと思うんだよ。
そのコードを書いた時点で、バグがある可能性が残ってしまう。
だから見ないといけない。俺はこれが嫌なんだよ。
コード自体は「打ち間違いがない」という前提でなら10-30秒程度だよ。中身は何もやってないから。
だからそれが既に実績のあるライブラリとして提供されていて、その中身の確認ならまあいい。
ただしそれを自前で書かれたら、詳しく確認しなければならないし、全てに当てる検証も必要になる。
そして得られるメリットはちょっと短く書けるだけ。
これは明らかに手間が増えているだろ。
.NET公式で関数合成の演算子として提供されていれば、それを使うことに問題はない。
仮にバグがあったとしても公式側が修正してくれる。(中身の実装について見る必要がない)
自前で書いたら上記の通り手間が増えるだけ。だったらベタで書いた方がマシ。
基本的にC#は「馬鹿が使う」ではなく「ここら辺まででいいよね」という思想だとおもうし、
その判断自体も割と妥当だとは思う。ちょっと窮屈な点はあるけど、致し方なし。
なお俺はC#派ではなくかなりC寄りのC++派ね。（お前らがbetter-Cと言っている奴）
これとは別に、「馬鹿でも使える言語」として使っている奴もいるし、
そいつらが調子こいているのも事実だけど、それは別問題。
716:デフォルトの名無しさん
16/10/02 14:27:32.07 FGg7v3h+.net
>>690
まあ別に俺も演算子を積極的に推奨するわけじゃないけどな
ちゃんとしたcppプログラマなら標準の型に対する演算子の挙動に準ずる動作で演算子を定義するのが良い習慣だってのが常識として知っているわけだし
717:デフォルトの名無しさん
16/10/02 14:28:49.54 aauDOAhV.net
>>689
関数ポインタを返せばいいだけだろ。
いずれにしてもtemplateは静的展開なんだから、ベタに書けない処理はないだろ。
ベタに書くのがいいか、テンプレートを使うか、
これを検証まで含めた「手間」基準で判断しろというのが俺の意見。
718:デフォルトの名無しさん
16/10/02 14:40:47.92 FGg7v3h+.net
>>691
依存先にバグがあるかも～とかそんなんでプログラマやっていけるのか？
演算子使おうが使わないが、やりたいことが関数合成だろうが何か別の処理だろうが、プログラミングするなら、関数やメソッドを定義してモジュール化するのは当たり前の事だろう
むしろ同じ処理をモジュール化しないで、同じようなコピペコードを大量生産するほうが圧倒的に悪じゃん？
この悪を突き詰めるとUIのイベントハンドラに全ての処理をぐっちゃぐちゃに詰め込むようなキングオブバカになるんだよ
そんなものは誰も望んでいない
処理の重複があればモジュール化するのが当たり前
モジュールにバグがあるのも当たり前でモジュールの保守をするのも仕事のうちだ
演算子がどうのこうのってレベルじゃねえぞ
719:デフォルトの名無しさん
16/10/02 14:42:08.34 FGg7v3h+.net
>>693
レス番間違ってないか？
720:デフォルトの名無しさん
16/10/02 15:00:21.56 aauDOAhV.net
>>694
お前がそう思うのならそれでいいじゃん。
俺は「手間」がかからない方を選ぶ。それだけ。
関数の線形結合なんて普通のプログラミング（例えばブラウザ等の製作）では不要だろ。
だから俺はそれにオーバーロードなんてしないし、必要ならベタに書く。
普通のプログラミングで、その線形結合って何回使うと思っているの？
余程数学的なことをするのであれば関数の線形結合も必要になるのかもしれないけど、
そういうところは既にライブラリなりフレームワークが用意してあり、
演算子も既にオーバーロード済みだったりすると思うよ。
とはいえ、俺とお前は特に何の関係もないわけで、別にお前がそうすることを止めはしない。
それをOSSとして公開してあれば、「馬鹿がいきがってるな」と思うだけ。
そういう俺に対してお前が「馬鹿だな」と思うのも自由だよ。
そういう意味ではいい時代になったね。
721:デフォルトの名無しさん
16/10/02 15:08:10.02 aauDOAhV.net
>>695
間違ってない。
> 関数を合成する (>>689)
に対して「関数ポインタを返せばいいだけ」
俺が671で
> 関数の評価
つまり値を算出したのが気に入らなかったんだろ？
Cでも「関数ポインタを返す関数」というのは普通に定義出来る。
関数合成ってのは別に難しい話でも新しい話でもない。
722:デフォルトの名無しさん
16/10/02 15:25:03.83 FGg7v3h+.net
>>696
なるほどそっちの認識では線形結合のみかつ再利用の機会も少ないという前提の話題だと思っているのね
関数合成や線形結合はあくまで一例であってもっと一般論的な話をしてるつもりなんだが>>694読んでわかんなかったかな？
723:デフォルトの名無しさん
16/10/02 15:30:13.53 aauDOAhV.net
ああすまん、696はレス相手を勘違いしていた。
>>694向けに再度書き直す。
>>694
それは単にDRYなりOAOOだし、基本中の基本だろ。
今更何を言っているんだ？
俺は無駄なコードを書くなと言っているだけ。
使いもしない演算子オーバーロードのコードとかね。
724:デフォルトの名無しさん
16/10/02 15:36:24.07 FGg7v3h+.net
>>697
わからなくなってきたな
君は関数合成をカスタム演算子を使う方法ではなくf(g(x))と表記出来ると言っている
これは関数合成ではなくg(x)を評価した結果を引数にしてfを評価しているだけであって関数を合成する処理ではないよと返した
さらにその返しとして関数ポインタを使えば良いというよくわからない返事が来たのでレス番間違ってないか？って聞いたの
関数ポインタを使ってf(g(x))の表記でfとgを合成するにはどう書けば良いんだろうね
当然だけど|を使った表記より実装がシンプルになってバグがなくなるんだよね君のポリシーからすると