C#, C♯, C＃相談室 Part95

C#, C♯, C＃相談室 Part95 at TECH

C#, C♯, C＃相談室 Part95 - 暇つぶし2ch359:
19/12/22 15:47:44.02 EAnHyDWL0.net
>>344
gcc は確か C++ で記述されていたはず、C++ のサブセットなんてどんなものなんですかね？

360:デフォルトの名無しさん
19/12/22 16:11:14.32 5lkZulIS0.net
元々はただのCだぞ

361:
19/12/22 16:23:54.21 EAnHyDWL0.net
>>348
ずいぶん昔に gcc は c++ になってしまいましたよ…

362:デフォルトの名無しさん
19/12/22 16:45:16.31 lRvby7lea.net
元々はって日本語わからんのかな

363:デフォルトの名無しさん
19/12/22 16:46:38.86 uiOI59Hv0.net
昔のc++はcのコードを一旦出力してcコンパイラでバイナリを作っていたな

364:デフォルトの名無しさん
19/12/22 17:21:58.53 4GpMlcpo0.net
>>341
> アセンブラは不要。
と書きながら
 >>344
> なお、最初のCコンパイラはBで書かれたものとDECマシン向けのアセンブラで書かれたものがあり、Bコンパイラはすべてアセンブラで書かれていた。
とか自称博識がアホすぎるw

365:
19/12/22 17:31:31.94 EAnHyDWL0.net
>>350
では質問を変えましょう
その昔の to C トランスレータの頃のC++は、控えめに言って C++98/03 の範囲の何パーセントくらいがカバーできていたのでしょうか？

366:デフォルトの名無しさん
19/12/22 18:56:50.05 5lkZulIS0.net
かわいそうに、馬鹿なのだな

367:デフォルトの名無しさん
19/12/22 19:39:34.09 tqOBQt+/0.net
>>354
コテでググったら各所で問題児扱いされている奴だったわ

368:デフォルトの名無しさん
19/12/22 21:03:00.98 0l5I7UXk0.net
>>352
よーく読んでみ

369:デフォルトの名無しさん
19/12/22 21:43:42.23 la1jzM750.net
>>352
バーンドブレードアタッチメントな僕の知識に反論しようとは笑止千万。
前者は今後出てくる新しいPFに関する記述で、後者は当初のコンパイラに関する記述なので、なんの矛盾もない。

370:デフォルトの名無しさん
19/12/22 21:55:06.63 4GpMlcpo0.net
>>357
> 前者は今後出てくる新しいPFに関する記述で
誰もそんな話はしてない
Wikipediaレベルのチンケな知識自慢は要らんよw

371:デフォルトの名無しさん
19/12/23 00:11:53.87 GXjcw1770.net
だめだこいつ…ｗ

372:デフォルトの名無しさん
19/12/23 06:44:48.06 AlxEeRKZM.net
>>359
自己紹介乙ww

373:デフォルトの名無しさん
19/12/24 19:15:18.17 fgilpQiTl
XMLを知る前に、気づいたらJSONを使ってた。関数があるから便利だよな。
しかも今はJSON.NETがあるからデータ構造すら気にしなくていい。。

374:デフォルトの名無しさん
19/12/24 19:20:31.43 fgilpQiTl
>>141 扱うデータ量にもよりそう。

あんまりたいしたことがないデータ量なら for のほうがとても早いが、
あるオーダーから指数関数的に for のほうが遅いということもある。

for だって最適化されてるし、関数にはオーバヘッドがある。

375:デフォルトの名無しさん
19/12/24 19:22:22.08 fgilpQiTl
まあ一般的に業務ならデータ量は多いはずだから関数のほうが早いんだろうな。

趣味レベルだと扱う量がたいしたことないから、極端に言えばＳＱＬを使うよりも
テキストのデータベースのほうが遥かに早い。

データインサートのときは適当に自分なりの符号を作ってテキストを挿入し、
引くときは正規表現で引くみたいな。

376:デフォルトの名無しさん
19/12/24 19:34:26.35 fgilpQiTl
しかし言語系って同じ概念なのに用語がいっぱい作られていて一々用語の意味を
調べるたびに「一緒ジャン」ってなるな。

データ型名や関数名からそのまま新しい用語ができてい�

377:驍ﾁて感じがする。。

378:デフォルトの名無しさん
19/12/25 16:59:22.64 Zg8ebJFL0.net
今日もつまらないことで5chは盛り上がっております

379:デフォルトの名無しさん
19/12/26 11:49:58.62 2UlJm9YS0.net
using/disposeについて確認したいんだが、
あれって厳密には「リークする」ではなくて、
「解放のタイミングが不明で、場合によっては問題が発生することもあり得る」なだけだよな？
URLﾘﾝｸ(docs.microsoft.com)
具体的にはGDI+オブジェクトのGraphicsやBrush等について、
MSDNのドキュメントもほぼusingなしで記述されているので気になっている。
URLﾘﾝｸ(docs.microsoft.com)
一応、using使えということになっていたはずだが？
そこで色々ググって見ると、どうやら以下のようだが、あってるか？
・try-catch で finally にdisposeが入ってなかったとき、（≒つまりusing使わなかったとき)にも、
　例外が発生したその時のリソースも、参照が切れ次第、いつかはGCによって回収される。
・GDI+リソースはシステムリソースで、場合によっては枯渇するから、作法としては不要になり次第解放すべき。
・とはいえ32bit化でこの辺の問題は大幅に緩和され、GDI+はプロセス毎の上限は10,000になってる。
　だから余程酷いことをしない限りこれに引っかかることはない。
結果、作法としては正しいがほぼ命中しない問題に関して一々using使うのもウザイ、
ということでMSDNのドキュメントがusing無しになってる、ということで合ってるかな？
(なお関係ないとは思うが俺が使っているのはVC++/CLIとForms)

380:デフォルトの名無しさん
19/12/26 12:35:29.16 WMR2NHe80.net
サンプルプログラムに厳密性を求めるな　ってだけ

381:デフォルトの名無しさん
19/12/26 12:37:11.96 Fsuom43iM.net
サンプルだから本質には関係ないところをバッサリ省略してるだけでしょ
ガチな例外処理とか入れられても見辛いだけだし
それと同じ話

382:デフォルトの名無しさん
19/12/26 13:02:58.04 Wx+k6OqqM.net
まあサンプルをコピペしちゃうレベルなら他にもっとまずいところはいくらでもあるだろうから、
少々Disposeが先延ばしになるくらいは無視しても問題ないかと

383:デフォルトの名無しさん
19/12/26 13:36:36.96 2UlJm9YS0.net
>>255
周回遅れだが一応参戦。当該院生が冬休みでもう一度読んでいることを期待する。
他の人も言っているとおり、設計としては253で正しい。直す必要はない。
なおその点はForms->WPFで思想が修正された点であり、（つまりFormsが駄目だった点）
これも他の人が既に言っているとおり、「最新のフレームワークの流儀」で設計するのが妥当。
判断する能力がないなら、とにかく「最新の流儀」に乗っかるのが
無駄に嵌るのを未然に防ぐ適切な方策となるのでそうすべき。
構成としては、おそらく、
「設定値変更画面(V)」「設定値保管用クラス(M)」「他クラス（多分演算ルーチン）(EXE)」で、
これはMVCの通りであり、V-M, M-EXE 間は結合しているがV-EXEは結合していない。
これに対して、誰か（≒老害）に指摘されたのだと思うが、君が253の時点でいいと思っている構成は、
「設定値変更画面(V+M)」「他クラス（多分演算ルーチン）(EXE)」となっており、Mが分離していない。
（=EXE側がVを知っている必要がある）
この

384:構成の利点は、・コードが多少少なく済む点であるが、結局使い勝手が悪いので、ずっと改善していくと最終的に253みたくMVCに分離することになる。

385:デフォルトの名無しさん
19/12/26 13:37:07.04 2UlJm9YS0.net
>>261
といっても分かりにくいだろうから具体的に指摘すると、
君の問題は、間違った方策で解決しようとして、余計におかしくなっていることだ。
> 他クラスで使用しているときに値を変更されないように2、3を実装したんですけど、単に画面を入力できないようにロックすればよかった。
これは「画面をロック」ではなく、演算開始時に「設定値保管クラスのコピーを演算ルーチンに渡す」とすべき。
これにより、一つの実行画面から多数の演算ルーチンを並列に起動したり、
或いはGUI無しでコマンドラインから起動することも普通に可能となる。
（つまりプログラムとしての汎用性/柔軟性が上がっている）
「クラスのコピー」ってのはディープコピーだが、単純に値が入っているクラスなら、
Cなら構造体の代入、つまり
SomeClass myCopy = reference;
の1行で事足りる。或いは通常、関数呼び出しには構造体への「ポインタ」を用いているはずだが、そこを構造体の「値」に変えればいいだけ。
C#だとstructは値型だったと思うので、設定値保管用『struct』なら自動的に上記が常に行われる構造になるが、
余程小さくない限りそれでは使いにくい筈なので、設定値保管用『クラス』で正しく、何らかの方策でディープコピーをした方がいい。
インミュータブルに組んでいればシャローコピーでも行けるようには出来るはずだが。

386:デフォルトの名無しさん
19/12/26 14:38:18.82 2UlJm9YS0.net
>>367-369
つかこれ、どれくらいgraphicsヘビーにすればヒットするんだ？
以下はヒットしているようだが、俺はヒットしない。
URLﾘﾝｸ(sorayukinoyume.hatenadiary.org)
俺のは40k個Brushを作ってそのまま放置、それを1秒ごとに再描画、
みたいな感じだが、OutOfMemoryなんて起きない。
（ただし、カクつく事があったから今はDisposeを入れてしまったが)
プログラムは演算結果をGUIで表示するもので、演算ヘビーだが、
演算自体はC++ネイティブなのでGCは行われない。
（演算ルーチンではマネージドメモリを消費しない）
なお以下とかは正しいように思う。
URLﾘﾝｸ(uchukamen.com)
URLﾘﾝｸ(ladybug.hatenadiary.org)
URLﾘﾝｸ(ufcpp.net)
URLﾘﾝｸ(divakk.co.jp)
URLﾘﾝｸ(www.codeproject.com)
（なお最後はシステムで10,000が上限だと言っているが、これはプロセスの間違いだと思う。《他でそう書いてあったところもあった》
また、タスクマネージャーで見る限り、俺のPCでは全体で10,000は越えているし。
なお一番使っているのはJane2chの8,653だった。Jane糞だなオイ。
chromeは各プロセス毎に600-800位、俺のプログラムはどうやっても50-70を推移してる）
MSも馬鹿じゃないからサンプルコードはそれなりに正しいはず。
絶対にこう書け、なら必ずそう書く。そうでないのはその必要が「普通は」ないからだ。
逆に、普通にサンプルコードで問題が発生するようなら、クレーム来まくりで大変だから、当然のように修正される。
それが為されてないのは、それなりに使用に耐えるコードだからだ。
という感じ�

387:ﾈのだが、お前らこれヒットするのか？ VC++/CLIとC#だとGC周りがだいぶ違うって事か？

388:デフォルトの名無しさん
19/12/26 14:50:50.75 +pzqFzNua.net
>>372
DC(Graphics)は不要になった時点でDisposeした方がいいと思うけど、
PebとかBrushとかFontとか、このあたりがIDisposable実装してるのは
たぶんWin9xを想定してるんだろうねw
.NET 1.1とかの時代に、Win2kやXPではそこまで神経質にならなくていいよ、
って記事を結構読んだ記憶がある

389:デフォルトの名無しさん
19/12/26 14:53:40.92 g3TV29VW0.net
多いから糞って単純な話でもないだろ。表示しているオブジェクトが多いなら仕方がない。
explorerもウィンドウを大量に開くとモリモリ消費する。

390:デフォルトの名無しさん
19/12/26 15:25:02.44 2UlJm9YS0.net
>>374
いやJaneはガチでリークしてると思うぜ。
俺のPC内での今の順位
1. Jane2ch 8,677 ←増えてやがるし
2. explorer 1,340
3. chrome 826
以下chromeが20個ほど続く。
字しか表示しねえJaneでどうやって8,677個になるんだよ？
フォントや色でも精々100だろ。
そもそも複数ページ表示してるchrome越えてる時点でだいぶおかしい。

391:デフォルトの名無しさん
19/12/26 15:25:33.99 2UlJm9YS0.net
>>373
そのわりにusingガーというのが多いのはなんでだ？
若干Java的オブジェクト指向（オブジェクト指向が唯一絶対神であり、それ以外は認めない）に近い偏見を感じる。
GCなんて手抜きの為の機構であり、逆に言えば、GC使っている以上、書かなくて済む事は書かない、というのが正しいだろ。
全部書け、ならC++を使って全部書き、GCなんて使っている軟派野郎は死ね、とあるべき。
C#でusingって、なんか違うくね？
まあ現実的にヒットするなら致し方ないとして、俺が試した限りでは、どうにもヒットしないように見える。
それとも
> DC(Graphics)は
これはdevice context だけは即時解放した方がいい、ということか？
具体的にはGetHdcメソッドを有する連中だが、見た目Graphicsだけかな。
だとすると俺がやってるBrushでは再現しないのも納得だが、
かといってGraphicsを10,000取得とかいう使い方もないとも思うが。

392:デフォルトの名無しさん
19/12/26 15:49:32.19 8rtfbEtYp.net
何をグダグタと気にしてるのかよーわからんな
どうせそのうち回収されるんだから無駄に残ってるのが気にならねえならどうでもいいだろ
精々Janeみたいに過剰に確保されてるのを観測されてクソクソ言われるのが自分のアプリになるだけだ

393:デフォルトの名無しさん
19/12/26 16:01:00.94 Wx+k6OqqM.net
つか本来は実際に画面に表示されてる間だけアンマネージリソースを確保すればいいわけで、設計が手抜きなんだよ
まあ、そういう思想でスマートなリソース管理をしてるWPFはゴミのように遅いわけだがw

394:デフォルトの名無しさん
19/12/26 16:08:06.67 +pzqFzNua.net
>>376
なんかちょっと被害妄想激しいよw
IDisposableを実装してたら絶対Disposeすべき、という教条主義を展開してる記事って
あんまり読んだ記憶ないけど、まあusingブロックは十分コンパクトに書けてかつ便利なので、
Disposeしなくてもいい、という確信が持てないなら素直にDisposeするのが普通に安全牌だよね。
※ 個別にDisposeを呼ぶんじゃなくてusingを使え、という趣旨の記事ならいくつか読んだことある

395:デフォルトの名無しさん
19/12/26 16:15:52.27 2UlJm9YS0.net
>>377
俺自身は「usingを使うべき」とされる解説ページでお約束的に出される
・そこで例外が発生してdisposeされずに抜けてしまった場合、リークする
が間違い（というか誇大)だと見ているのだが、これが間違ってるかどうかをここで尋

396:ねている。俺の認識に間違いがないとすると、俺が試した限りではヒットすることが難しいのに、何故ここまでusingにこだわるのか？というのが疑問になる。勿論こだわるのもありだが、C#ってそういう言語でもないし。なお俺のはdisposeしてなくて50-70だぞ。そこで上記の通り、Brushを40k個作ってもだ。 (もっとも、多すぎてGCが常に速攻行われているだけかもしれないが) JaneStyleは調べたところOpenJaneからの派生で、OpenJaneはDelphiで、これはGC無しらしい。つまりモロにリークしてるだけだよ。

397:デフォルトの名無しさん
19/12/26 16:30:20.52 bzjIw0U90.net
尋ねてるって言うけど、君の求めてる通りの回答以外は認めないんでしょ
聞くだけ無駄じゃん

398:デフォルトの名無しさん
19/12/26 16:40:38.25 2UlJm9YS0.net
>>379
> Disposeしなくてもいい、という確信が持てないなら素直にDisposeするのが普通に安全牌だよね。
つまりこれ。
実はDisposeしなくていいんじゃねえの？というのが俺の疑問。
ヒットしている人がいるから何か要件はあるのだろうけど、俺が試してる限りではヒットさせようがないように見える。
とはいえ、ヒットする可能性がある限り、解説ページ等では「Disposeしなくていい」とは書けない。
だけどほぼ必要がないことはMSも認めてるからサンプルページではusingなんて使っておらず、
usingについてのリンクすらない、というように見える。
(つまりサンプルページを確認しているレベルの奴がヒットさせようがなく、
余計な混乱を防ぐ為にも書かない方がいい、とMSが判断してる。
まあ >>367-369はモロにそう言ってるわけだが)
ただこの状況でも、自分だけが使うならともかく、他人も使うとなると、
using使わないわけには行かない、というのは認める。
だからなんだかなあ、みたいな感じになってる。
結局のところ、これは俺の環境のみならず、
.NETが動くありとあらゆる環境に於いて問題なく動くプログラムを作る為の作法であって、
MSがusing使えと言う以上、書くしかない、ということか。
それが俺のPCでは再現不能だとしても、それはたまたまでしかない、ということであって。

399:デフォルトの名無しさん
19/12/26 16:47:16.53 BHrZHcGr6.net
c#のListをイテレーションするサンプルをウェブで探していたんだけど、インデックスでアクセスして回しているコードがよく見つかるんだけど、
Listのデータ構造はリストではないの？

400:デフォルトの名無しさん
19/12/26 16:48:04.03 +pzqFzNua.net
>>382
上に書いたWin9x環境を特に想定した実装、というようなケースを除けば
そのクラスを作ったプログラマは「不要になったらDisposeを呼んで欲しい」と思っているから
IDisposableを実装している。
だからDisposeしなくてもいい、という確信が持てないなら（以下略

401:デフォルトの名無しさん
19/12/26 16:55:18.99 WMR2NHe80.net
>>383
「リスト」だとデータ構造が説明できてないと思うのだが
List<T>は配列で実装してるよ

402:デフォルトの名無しさん
19/12/26 16:59:42.72 F8ujXl8x0.net
GC任せではなく明示的にメモリを開放していかきゃ動作に支障をきたすような少メモリな環境だって世の中にはある

403:デフォルトの名無しさん
19/12/26 17:03:28.05 Wx+k6OqqM.net
>>383
.NETではIListは順序が定義され効率的なランダムアクセスの可能なデータ構造
従って、リンクリストはIListを実装しない

404:デフォルトの名無しさん
19/12/26 17:07:04.85 2UlJm9YS0.net
>>384
なるほど確かにその通りだ。
設計者が想定したとおりに使うのが安牌であり、
書いておけば済む物を、特段メリットもないのに書かずに済ませて後で嵌るのは生産性が悪い、というのはC#的には当たりだ。
呼ぶか呼ばないかは使用者が判断するものではなく、設計者がIDisposableを実装するかどうかで示し、それに従え、ということか。
まあ長期的に見てその思想が正しいんだろう。
なるほど納得した。

405:デフォルトの名無しさん
19/12/26 17:10:19.42 2UlJm9YS0.net
>>383
つURLﾘﾝｸ(docs.microsoft.com)

406:デフォルトの名無しさん
19/12/26 18:35:58.39 EoULV8Z50.net
disposeされなくてもデストラクタで解放されるが、
かなり高コストな処理が発生するそうな
URLﾘﾝｸ(ufcpp.net)

407:デフォルトの名無しさん
19/12/26 19:21:56.18 2UlJm9YS0.net
>>390
それは嘘。というか誇大広告。
オブジェクトの寿命が1GC分伸びるだけ。それが深刻になる状況なら、
ファイナライザリストをそもそも作らず、必ずusing/disposeしろ、という設計思想が妥当。…(A)
或いは、ファイナライザリスト内だけ2GC世代分GCするとか、そういうフレームワーク設計も可能。…(B)
いずれにしても、.NETはそうしてない＝それは大した問題ではない、とMSが判断している証拠。
といってもGCも進化しつつあるし、この辺もじきに整理されるのかもしれん。
C#8.0のusingはソースコードとしてはほぼ完成型だし、
> using var font1 = new Font("Arial", 10.0f);
> URLﾘﾝｸ(docs.microsoft.com)
型によっては using var でしか宣言出来ない（＝静的に確保出来ない＝ローカルでしか持てない）ようにすれば、
上記(A)の思想を体現出来る。それが本筋かもね。
形式的にはVC++/CLIのpin_ptrと同じだから、実装する気になればMS的にはすぐだ。
URLﾘﾝｸ(docs.microsoft.com)
制限はそこに書いてあるが、以下。
> 固定ポインターは、スタックの非静的ローカル変数としてのみ宣言できます。
> 固定ポインターは、以下として使用することはできません。
> 関数パラメーター
> 関数の戻り値の型
> クラスのメンバー
> キャストのターゲット型
「関数パラメータ」に使えない、と書いてあるが、これは言い方が悪くて、
「関数の仮引数の型には使えない」が正しく、実引数として渡す場合はキャストされるので普通に使える。
言葉だと分かりにくいが、
pin_ptr<double> ptr_d;
を void somefunc(double*) に渡すとdouble*に自動的にキャストされるので普通に使える。
これと同様の制限だと、「その関数を抜けた後も保持していて欲しい」オブジェクトには使えないが、
GDI+オブジェクトに関してはこの方向でもコーディングは可能のように思える。

408:デフォルトの名無しさん
19/12/26 21:56:25.88 Ag2MBuDI0.net
>>391
> オブジェクトの寿命が1GC分伸びるだけ。それが深刻になる状況
じゅうぶん現実的な状況でなり得るよ。Gen1以上のGCを舐めてる
それが許容できるかは要件次第
ゲームプログラミングでなくとも極力排除すべき要素
そういえば「ガクガクするから結局Dispose呼び出した」とか自分で言ってたね
なんでガクガクしたの？
> 型によっては using var でしか宣言出来ない（＝静的に確保出来ない＝ローカルでしか持てない）ようにすれば、
論外。ネイティブリソースを持った時点でスタックにしか確保できない型しか作れない言語の出来上がり
ファイナライザを作らずDisposeを強制するというのはそういこと
大した問題じゃないから、ではなく潜在的に負荷を抱える可能性の排除とリソースリークへのセイフティを天秤にかけた結果だよ
> VC++/CLIのpin_ptr
それC#で言うunsafeなfixed相当。関係無い

409:デフォルトの名無しさん
19/12/26 22:28:04.26 9AkEaWNs0.net
Disposeしないで挙動を調べた結果、問題ないんだったらそのリソースに関してはDisposeしなくていいってことがわかるだけじゃない？
それを一般化してusingなんか使う必要がないのだ/Disposeはファイナライズのときにされるので十分なのだってのはおかしいような。
一々いろんなIDisposableのオブジェクトの挙動を調べてたら検証時間がかかってしょうがないし、
今調べた挙動が将来的にずっと同じである保証もないから、Disposeしてね、と言われているものに関しては、
Disposeされるものだと思って設計変更される可能性がある、と考えて、
問題のないタイミングで行儀よくDisposeしてトラブルの種を潰すってだけの話だと思うんだけど
逆に、使い尽くして

410:Disposeしなくていいってわかってるんだったら（例えば自作クラスで、なんかのハンドルを握ったままになったりしないという保証があるなら）どうぞご自由に、って思うけどね「自転車ってうちの近くの舗装の綺麗で平坦な道路では手放し運転できるのに、なんでハンドルなんかついてるんだ？いらなくね？」って言ってるようなものだと思うけどね。

411:デフォルトの名無しさん
19/12/26 23:04:21.26 qz8G02Zg0.net
なるほど！と読んでたら最後の例えでよくわからんようになった…

412:デフォルトの名無しさん
19/12/26 23:08:24.18 2UlJm9YS0.net
>>392
いや多分、みんな求め過ぎなんだよ。
C++erが特にそうだが、C++を何でも出来る言語にしようとしてる。
それと同じく、君もまた、C#を万能言語にしようとしてないか？
つまり、簡単に書け、かつ、最速な言語に、ということだ。
> それが許容できるかは要件次第
俺に言わせれば、ゲームプログラミング等のパフォーマンスクリティカルな状況でC#を使う選択自体が間違ってる。
実際、ゲームは今でもC++が主流で、それはパフォーマンスの問題からだろ。
そういえばUnityはC#だが、（俺はゲーマーでないから詳しくないが)
あれは紙芝居ゲーとかそういう全くパフォーマンスとかどうでもいい系向けではないのか？
グラゴリゴリのゲームをC#で書いて、C++に勝てるとでも思っているのか？
> なんでガクガクしたの？
知らん。ただ、Disposeしてなかったから試しにしてみたらとりあえず直った。
だからGCなのだろうとは思うが、それ以上は確認してない。
ただ、2-3画面毎だったから、Brushで言うと100k毎くらいだ。

413:デフォルトの名無しさん
19/12/26 23:09:24.48 2UlJm9YS0.net
> 論外
いやお前の不勉強具合が論外だよ。少なくともRustはそっちを目指している。
もうちょっと単純簡潔な表現のページもあったはずだが見つからないので、グダグダしているが以下。
> 意味論への影響
> スタックアロケーションはRustの言語自体へ影響を与えており、したがって開発者のメンタルモデルにも影響しています。
> Rust言語がどのように自動メモリ管理を取り扱うかは、LIFOセマンティクスに従っています。
> ヒープアロケートされユニークに所有されたボックスのデアロケーションさえも、
> スタックベースのLIFOセマンティクスに従っていることは、この章を通して論じてきたとおりです。
> 非LIFOセマンティクスの柔軟性（すなわち表現能力）は一般的に、
> いつメモリが解放されるべきなのかをコンパイラがコンパイル時に自動的に推論できなくなることを意味するので、
> デアロケーションを制御するために、ときに言語自体の外部に由来するかもしれない、動的なプロトコルに頼らなければなりません。
> （Rc<T> や Arc<T> が使っている参照カウントはその一例です。）
>
> 突き詰めれば、ヒープアロケーションによって増大した表現能力は（例えばガベージコレクタという形の）著しい実行時サポートか、
> （Rustコンパイラが提供していないような検証を必要とする明示的なメモリ管理呼び出しという形の）
> 著しいプログラマの努力のいずれかのコストを引き起こすのです。
> URLﾘﾝｸ(doc.rust-jp.rs)
と公式は言ってはいるが、Rustの取っつきにくさはここにあって、
要するに既存言語のノリでやったら全然コンパイルが通らないらしい。（俺はやってなから知らんが）
ただし、スタックアロケーションの方が効率も管理も楽なので、スタックアロケーション出来るものはスタックに、という理屈は合ってる。
問題はそれだと柔軟性、つまりデタラメなコーディングが出来なくなる点で、

414:デフォルトの名無しさん
19/12/26 23:10:55.58 2UlJm9YS0.net
> 天秤にかけた結果だよ
というのはその通りで、C#は色々なことを天秤にかけて「丁度いい言語」を目指している。
だから、「最速の言語」では今現在ないし、今後ともあり得ないことも自覚してないといけない。
繰り返すが、パフォーマンスクリティカルな状況でC#を使うこと自体が間違いだ。これは今後共だ。

> それC#で言うunsafeなfixed相当。関係無い
確認したが、fixed相当なのはその通り。それで、何故関係ないと言えるのか？
usingで書けるということは、同じ構文のfixedでも書けるということ。
pin_ptrは型なのでグダグダ制限が付いているが、usingやfixedは構文なのでそもそも制限する必要がないだけ。
まあここら辺の理屈はさておき、実際、GDI+リソースをクラスメンバとして持つ必要がどこにある？
例えばGraphicsをControl.CreateGraphicsから生成するのなら、Controlを持っておき、その都度生成することは出来る。
これにより、永続コンテンツ（クラスのメンバ）として持つのは回避出来る。
この制限を付ければ、Graphics自体が「生成されたスコープを抜ければ常に破棄される物」となり、
言い換えれば君の言っているとおり「スタックにしか確保出来ない型」になるが、
usingなんて付けなくてもリソースリークが発生することは原理的になくなるし、
ファイナライザという機構も不要になるので、GC自体も単純化し、高速化する。
とは言ってもここら辺はフレームワーク根幹の設計思想であって、今更グダグダ言っても始まらないが、
Rustで.NETをサポートしたらusingみたいな糞は入らないだろうよ。（原理的に不要）
どの言語スレもそうだが、若干みんな信者になってしまっていて、公平に見れてない。
C#8.0のusingは「書く」前提なら完成型だと思うが、「書かない」方向を目指すことも出来、実際、Rustはそっちを目指してる。
それを糞だと判断するのも自由だが、理解出来ない/知らないのは君の問題だよ。
俺に言わせりゃ、コールグラフなんて抜けるんだから、
usingなんて書かなくとも「このリソースが永続化することはない」というのはコンパイラ側が判断出来ることで、
なら自動的にusing扱いにして、そうじゃないところだけwarning出してくる、というのが理想だと思うが。

415:デフォルトの名無しさん
19/12/26 23:23:27.97 aYxazJyl0.net
unityでも3Dゴリゴリのゲームは作るよ
というかスマホで3Dゲームの高クオリティ開発ならunity
1択なくらい。unrealはまだスマホ市場少ない
unityはスマホが多いがコンシューマもPCもそれなりにある
ゲーム以外のARVR分野もかなりunityは多い
言語パフォーマンスより開発パフォーマンスが優先された結果だと思う
だからといって処理速度をないがしろにできるわけじゃない

416:デフォルトの名無しさん
19/12/26 23:25:15.01 2UlJm9YS0.net
>>393
いや長期的に見た生産性の為にusingを書いてトラブルの種を潰しておく、というのは納得した。
俺がいくら試しても、俺環境で俺の使い方での結果でしかないから、公式に従った方が得策だ。

ただし言語としてそれが最高か、と言われれば、俺はusingなんて書かなくてもなんとかしとけ、という思想。
つまり、
C#： using書け、ただし、書き忘れても大体何とかなるようには作ってある
Rust：そもそも変数はスタック上にしかアロケートしないので、usingとか原理的に不要
俺：勝手にコンパイラが色々チェックして、可能なところは自動的にやって、駄目なところだけwarning出してこい
ということ。ただしこれは理想論であって、現実はそうではないのはもう認めてる。
ただそれにしても、「GDI+オブジェクトがスタック上にしか確保出来ない」がそんなに糞だとは思わない。
実際、俺はこれでほぼ組んでいるはずだし。

417:デフォルトの名無しさん
19/12/26 23:41:44.91 V9vPePAWa.net
Rustは普通にヒープ使うぞ？
なんか勘違いしてるようだが、そもそもスタックだけで用が足りるんなら所有権だの何だのとRustの高度なリソース管理は要らん
C++のRAIIや、それこそC#で変数をデフォルトでusingにした程度で十分だ

418:デフォルトの名無しさん
19/12/26 23:42:14.94 2UlJm9YS0.net
>>398
> 言語パフォーマンスより開発パフォーマンスが優先された結果だと思う
> だからといって処理速度をないがしろにできるわけじゃない
C#の開発パフォーマンスがいいのは認める。
とはいえ、原理的な速度というのはあって、
正直、C++erの「GC使わないけどスマポ使え」ってのはロジック的に間抜け（矛盾してる）と思うが、
Rustの「全部スタック動作と連動」というのは原理的に正しく、逆に言えば、この方法でないとCを越えられない。
だから、根幹の思想は何だかんだで重要で、GDI+に関してはusngではなく「スタック縛り」の方が妥当だったように思う。
ファイルリソースは永続化出来ないとイテレータが使えないのでusingじゃないと無理っぽいが、
GDI+リソースは特に永続化する必然性が無く、大量に生成し、破棄するものだからだ。
パフォーマンス上は断然「スタック縛り」が有利で、
それでコードが書けなくなる/書きづらくなる、ってこともないと思うのだが。
と言ってもMSも気づいているだろうし、当然考えてもいるだろうし、
Rustにも手を出してはいるから必要なら出してくるんだろうけど。

419:デフォルトの名無しさん
19/12/26 23:44:51.57 2UlJm9YS0.net
>>400
他言語の「ヒープ」と同等の動作では全くない、ということ。

420:デフォルトの名無しさん
19/12/27 01:44:02.82 FV6GRoMta.net
>>402
具体的にどう違うのか説明してね
Rustのメモリ管理は、端的に言えばスマポしか使えない縛りを入れたC++に過ぎないよ

421:デフォルトの名無しさん
19/12/27 09:28:31.67 9LlS+1cS0.net
>>399
呼び出しの静的解析だけで、コンパイラ側が自動でusing付けるとか、現状の言語仕様でいけるもんなのかなあ。
行けそうなケースがあるのはわかるけど、すべてのケースで問題なく動作するというエビデンスはなんかある？
あと、俺に言わせりゃ静的解析で出来るだろとのことだけど、設計実装難易度も十分に低いと見積もってて、なんでやらないんだ、と言いたい、ってことなの？個人的には難易度は未知数だと思うんだけどなあ。

422:デフォルトの名無しさん
19/12/27 10:30:46.74 jG1yqawr0.net
>>404
参照がスコープ外に持ち出されていないかどうかを判断する必要があるだろうけど、それには
rustのように関数呼び出しに情報を受け渡す拡張が必要になるだろうね。
どうせ文法を拡張するなら、C++/CLIのようにusingより簡単な記述でDispose()の必要性を
判断できるようにする方が現実的かも。

423:デフォルトの名無しさん
19/12/27 11:10:40.91 AkdF/Ds50.net
>>404
> 設計実装難易度も十分に低いと見積もってて、なんでやらないんだ、と言いたい、ってことなの？
いや違う。ぶっちゃけ、信者的態度で言われたから言い返してるだけだな。
現実問題として、Rust公式でも述べているとおり、ヒープ+GCの使い勝手は素晴らしく良く、
「コードの書きやすさ」という意味においては現状最高だろう。
だからC#がこれを採用しているのも理に適ってる。
ただし問題は、それを信者的に素晴らしいと君らが捕らえている点で、
これはC#が魔法を使ったわけでもなんでもなく、
単純に、速度を捨てて書きやすさを取っているだけだと正しく認識しろと言っている。
だからパフォーマンスクリティカルだと分かっている状況でC#を使うのが間違いだし、
それはファイナライザが実装されているからGCが1世代分伸びるのも問題だ、というときも該当する。
そこまでのパフォーマンスを求めるときに使う言語ではないし、出来る言語でもない。これは今後共だ。
解決策は既に述べたとおりだが、ここに関してはMSが「間違えた」というのは厳しいが、でも、間違いだとは思う。
usingは「書く」前提ではC#8.0で完成しているが、
問題は、「それが書かなければならない型だ」とユーザーが認識しなければならない点で、
そもそも知らなければ抜けるし、そのためのファイナライザでシステム的に遅いGCになる事を許容しなければならない。
（というほど俺は遅くはならないと思うが、お前らはファイナライザが問題だと言うので）
なら、最初から「スタック縛り」にしてしまえば、SyntaxErrorで落とせるし、GC機構そのものが不要になる。
このときの問題点は多少コーディングの自由が奪われることだが、現実として、
PenやBrushをクラスメンバとして永続させる必要なんて無いし、
GraphicsやFontも生成元『マネージド』情報(既に述べたがControl等）を代わりに持つことによって回避出来る。
結果、馬鹿みたいに「GDI+オブジェクトはその都度生成して、その都度廃棄」なコードになってしまうが、
SyntaxErrorにならなければリソースリークは原理的になくなり、
GCも�

424:ﾈ素化/高速化し、using周りの仕様も覚える必要がない、ということになる。

425:デフォルトの名無しさん
19/12/27 11:11:26.51 AkdF/Ds50.net
俺が思うC#の利点は、「無駄に覚えなければならない仕様」がほぼ無いことであり、
これは、C++が何でも出来る言語にしようとしている反面、
ほぼ使いもしない仕様を覚える必要がありすぎる状況になっているのと対極的ではある。
ただ、俺に言わせれば、usingも覚えるべき仕様ではない。
「GDI+リソースを持つクラスはスタック上にしか置けません」の仕様だと、何も覚えなくて済み、リーク周りの問題もない。
ただこれは完全に後出しで、MSが間違いを犯したわけではない。
彼等は単純に現状の仕様に乗るようにしてきただけであり、
未来の改訂で「スタック縛り&using廃止」になるのも十分ありうるし、俺はそれを望む。
ただMSはおそらくパフォーマンスよりも書きやすさに振ると思うので、微妙だとは思うが。
> 呼び出しの静的解析だけで、コンパイラ側が自動でusing付けるとか、現状の言語仕様でいけるもんなのかなあ。
要は
Brush xxxxx;
{
// ここで永続化されなければよい
}
なので、中身を辿りきれるかどうかに尽きる。
具体的には、ヒープ上のオブジェクトに保持されているとかが無ければいい。（といってもC#は全部ヒープだが）
解析に問題になるのは関数ポインタを動的に使われるケース（テーブルジャンプ等）だが、
そういうのはほぼやらないから現実的には大半の場合は解析可能だと思う。
> 行けそうなケースがあるのはわかるけど、すべてのケースで問題なく動作するというエビデンスはなんかある？
こんな物はそもそも必要ない。
解析可能なら自動でusing付けろ、解析無理(かつユーザーがusing付けてない)ならwarning出せ、のベストエフォートでいい。
現実的にこれで問題ない。
というかJavaScriptのJITが既にこれに近いことをやっていたはずで、
要は「この関数を抜けたら破棄されると静的に解析済みの変数は最初からスタックに配置する」で、
解析無理なら従来通りヒープに置いてＧＣ、可能な物は纏めてスタックに置いてGC回避で高速化、みたいなことになってたはず。
だから.NETもそれをやればいいだけ。

426:デフォルトの名無しさん
19/12/27 11:48:38.34 hRCuq6kQM.net
君が冒している最大の勘違いは、「C#開発者の皆が自分と同じくusingの不便を感じている」という前提を置いていることだ。
実際にはもうFormsの開発なんてC#ではマイナーな部類になりつつあり、
現在の主流であるWeb開発ではDisposeなんか滅多に使わない。
Webのパフォーマンス改善の観点で言えば、(君の愛する)スタックにしか置けない特殊な構造体の導入等により、
C#のGCに極力頼らない高度なメモリ管理は実は一部では既に実現されている。
usingはもはや滅多に使わない機能であり、それほど力を入れて改善されるべき対象ではないんだよ。

427:デフォルトの名無しさん
19/12/27 11:56:34.65 JsENnlV9p.net
信者的信者的ってなんのこと言ってんだコイツ？
ファイナライザ持ちがDispose呼ばないと昇格オブジェクトが増えてやばいって警告に
誇大広告だのほざいてるのは自分じゃねえか
自分のコードでDispose呼ばずにフルコレクトかましてガクガクさせながら「自分はそれほどでもないと思う」とかなんのギャグだよ

428:デフォルトの名無しさん
19/12/27 11:59:55.99 9LlS+1cS0.net
>>407
JITだからできることでコンパイラじゃできなくない？
何が気になるかって言うと、コールスタックの解析とかをコンパイル時点でやり始めるってのは停止性問題を取り扱うみたいなむりがあるんじゃないのかってこと。
ごく簡単な例だったら問題ないだろうけど、そのごく簡単な例ってわずかじゃないのかな。

429:デフォルトの名無しさん
19/12/27 12:08:44.93 hRCuq6kQM.net
それをコンパイラ(というか型システム)でやろうとした結果がRustだね。
ちなみに彼は知らないようだが、Rustのメモリ管理がスマートであると言われる所以は、
エスケープしていないオブジェクトの生存管理などではなく(そんなものはC++でとっくの昔に実現されている)、
エスケープした「ヒープ上の」オブジェクトも正しく追跡して破棄できること。
それがプログラマにどれだけの負担を強いているかは >>396の通り。

430:デフォルトの名無しさん
19/12/27 12:34:15.59 AkdF/Ds50.net
>>408
Formsが過去の遺産で糞で既にVSからデフォで除外済みなのは知ってる。
ただし俺は移行するよりはそのままメンテする方を選んでいるだけ。
usingについては、C#8.0(2019/09リリース）で改訂されているのだからobsoleteとは言わんだろ。

まあそれはさておき、Web開発ってのは以下で、現状のC#の主力はWPFではなくこれだって事か？
URLﾘﾝｸ(docs.microsoft.com)
見た目サーバーアプリで、つまりPHPの代替のように見える。
なら実際の描画はやる必要がないから、そりゃGDI+オブジェクトを掴むことはあり得ないわな。
> Webのパフォーマンス改善の観点で言えば、(君の愛する)スタックにしか置けない特殊な構造体の導入等により、
> C#のGCに極力頼らない高度なメモリ管理は実は一部では既に実現されている。
調べてみたが、Span<T>, stackalloc, ref struct 等か。確かにこれらは悪くない。
こういう小回りも利くところがMS主導言語のいいところではある。
実際にコードを書く奴らが主導している匂いがする。
ただな、こういうマニュアル調整は本来C#が目指しているものではないだろ。
GCを使う＝変数等の寿命について一々考えたくない、であって、
実際、C++だと考えることが多すぎて、開発に手間がかかる＝開発効率が悪くなる。
だからそこをランタイムに丸投げして、ユーザーは本来書くべきコードだけに集中出来るのがよいのであって、
あれこれ弄れば速くなります、なら、最初からC++等使え、でしかない。
とはいえ、折衷策として出してきたのは悪くないが。
JavsScriptの良い点は、「何も考えなくてもJITが勝手に速くしてくれる」事であって、
俺はこの点が最高に気に入ってる。
ちゃんと弄れば速くなります、なんてのは、面倒＝開発効率が下がる。
ただしC#はスクリプト言語レベルの手抜きを目指しているわけでもないから、割と妥当なラインなのかもしれんが。

431:デフォルトの名無しさん
19/12/27 12:41:35.60 Xz3K8ooNd.net
えらい散らかった論調だな。もう少し端的に話せんか？

432:デフォルトの名無しさん
19/12/27 13:00:43.57 AkdF/Ds50.net
>>410
JITで出来ることとコンパイラで出来ることは違うが、今回に関しては同じだよ。
（関数単位でJITしてる限り同じ）
普通に考えれば分かると思うが、関数内の変数なんてその関数出たら破棄される物が大半で、
仮に内部でさらなる関数呼び出しに関連している物が全部追跡不可能だったとしても、十分効くんだよ。
完全にやり切ろうとするのはそりゃかなり無理だよ。でもそれは必要ないんだ。

433:デフォルトの名無しさん
19/12/27 13:13:01.35 ra/PE2rBa.net
極論 vs. 極論でなんともw

434:デフォルトの名無しさん
19/12/27 13:18:13.87 AkdF/Ds50.net
>>411
> ちなみに彼は知らないようだが
実際知らんからRustの話は君に任せる。
俺はRustはどういうコンセプトでどういう状況かを遠くから眺めているだけで、
「このコードが動かないんです！」みたいな悲鳴をチラ見してるだけだからな。
ただ、その中に「ヒープ上のオブジェクトすらも勝手に解放されるのかー！！！」みたいな話もあった気がするが。
スマポ限定なだけだというのなら、あれは関数呼び出しによる所有権移転で解放されただけの話か。
まあそうかもしれん。
いずれにしても俺はRustのコードは書いてないし、直近で書く予定もないので、Rustについては君に任せる。

435:デフォルトの名無しさん
19/12/27 13:29:20.92 ra/PE2rBa.net
どうせ過疎スレだし、BGMこれでガンガンやって欲しいw
URLﾘﾝｸ(youtu.be)

436:デフォルトの名無しさん
19/12/27 16:53:56.60 SNZP60vo0.net
トヨタの車をブレーキを踏まずに運転できる人なら、usingはいらないよ

437:デフォルトの名無しさん
19/12/27 20:05:38.60 vYkXGtn00.net
うぜーから個人ブログでやれよ

438:デフォルトの名無しさん
19/12/27 21:26:25.65 rZaePzzs0.net
正直半分ぐらいしかわからないけど、たまには盛り上がるのもいいよ

439:デフォルトの名無しさん
19/12/27 2

440:3:28:54.87 ID:SNZP60vo0.net

441:デフォルトの名無しさん
19/12/27 23:31:26.75 jbwOykBS0.net
ふらっとじゃなくこっちで暴れる分には好きにしたらいい
こっちでNGしとけばふらっとで見なくて済むし

442:デフォルトの名無しさん
19/12/27 23:40:23.09 AkdF/Ds50.net
>>420
半分しか分からないのは、オブジェクトの寿命を考えずにコーディングしているからだ。
ただしこれがGC言語の魅力でもあり、一々グダグダ考えていると魅力半減ではあるが、
そうは言っても、上達したいのなら、考える癖は付けた方がいい。
これについては、禿(ストロウストラップ＝C++創始者）の
「ドキュメントを作成すべきコードのサイズには下限があるが、
コーディングする前に考えるべきコードのサイズには下限がない」
が当たってる。なまじ出来るようになるとどうとでも組めるようになるが、それがいけない。
本来このコードはここにあるべきか？というのを考えながらコーディングした方がいい。
usingに関しては、そもそもGDI+オブジェクトが永続化されるのが間違いで、
それはVに状態を持つということだから、MVCから見てもアウトだとすぐ分かるだろ。
本来は、GDI+オブジェクトに関しては、
・usingの中でしか使えない
・スタック上にしか置けない
（まあこの2つは等価だが)みたいな制限を課されたとしても、まともな設計なら制限にすらならないんだよ。
で、戻るが、これが分からないのなら、それはオブジェクトの寿命を考えてないからだ、となる。
といっても分からないだろうから、具体的に説明すると、
例えばドベタな将棋ソフトを作るとしよう。
CPUと対戦するだけの将棋ソフトで、ドベタに、
ユーザーが入力（指す）→画面の更新→CPUは考える→指す(画面の更新)→アイドル（ユーザー入力待ち）、の無限ループだとしよう。
これでMVCなら、
M：盤面と持ち駒情報
V：画面表示
C：それらのグルー
であって、画面はその都度最新状態に更新されているのだから、
アイドル状態で残っているオブジェクトはどう考えてもMの「盤面と持ち駒情報」だけでいいだろ。
だからアイドル状態にてV用のGDI+オブジェクトが捕まれたままになっている時点で設計がおかしいんだよ。
この点、Janeは再起動してみたが相変わらずGDI+は8,657なので、明らかに糞設計だと断言出来る。

443:デフォルトの名無しさん
19/12/27 23:41:02.61 AkdF/Ds50.net
画面の更新は、当然関数であり、
画面の更新はこの中でしか行われないのだから、当然、この関数を出ればGDI+オブジェクトは破棄していい。
だから、全てのGDI+オブジェクトは、どこかで
void some_funciton_0(){
using (var someGDIobject = ... ){
some_function_1();
}
}
みたいにusingで囲めるポイントが必ず存在する。例えば、ど頭でCreateGraphicsするなら以下となる。
void redraw_board(){
using (var gr = someControl.CreateGraphics()) {
some_function();
}
}
これは寿命という意味では、関数の一番頭でCreateGraphics＝この関数と変数grの寿命を同期させているわけだが、
この関数以外に画面更新関数がなく、常に全面更新完了して抜けるのだから、
grはどう考えてもこの関数の外で使われることが無く、これで問題になりようがないだろ。
だから変数を寿命順に入れ子にし、結果的に関数コールも同様に並び、変数の寿命とスタックの動作が完全に一致する、というのがC流で、
動作としてはこれが一番無駄がないから、この設計で組まれた場合に速度ではどうやっても勝てない、ということになる。
別にこれが難しいとか制限が厳しいとかいうわけでもなく、要するに無駄なく普通に組めばこうなる。
だからまともな設計に於いて、GDI+オブジェクトに
・usingの中でしか使えない(＝スタック上にしか置けない)
という制限を課すのは、制限にすらならない。
これが問題になるようならそもそも設計がおかしい。
ただ、現実論として、度重なる仕様変更によりプログラムの設計というのはおかしくなって行くもので、
多少設計がおかしくてもなんとでもなる言語じゃないと困るのだが、
それにしてもGDI+オブジェクトは上記制限を課されても全�

444:ｭ問題ないと思う。回避手段もあるし。というかマジな話、MVCにしてればV用オブジェクト掴みっぱなしなんてあり得ないし。

445:デフォルトの名無しさん (ﾜｯﾁｮｲ 412f-fJ/L)
19/12/28 04:09:04 Cmc+tz5h0.net
GDI+だけがアンマネージドリソースではないんだが
そんな狭い前提で話されてもなぁ

446:デフォルトの名無しさん
19/12/28 09:58:00.22 6W1egYcc0.net
ちょっと言い方が本質的でなかったから言い直すと、
ある関数内で必要とされるリソースに対して、
・その関数突入時には掴んでおらず、
・その関数脱出時にはリリースしててよい（＝その関数の中でしか使わない）
場合は、必ずブロックスコープの入れ子で対応出来る。(A)
となる。Cはある意味これしか無く、これを「不自由だ」とする人達はGCに向かったが、
結局C的上記手法に回帰してる。これはC++もそうだし、C#もそうだ。
C#8.0のusing、何度も言っているが書く場合は完成型だが、意味的にはC++のデストラクタと同じでしかない。
なら36年前に開発済みの手法であり、C#1.0からこれでよかった。
それを19年かけて再開発して、何も知らない若者がありがたがるという、間抜けなことをやっている。
ここら辺がLinusがC++を嫌う理由で、C++も同様に仕様を引っかき回した挙げ句、C的手法に回帰してる。
なら最初からCで書け、Cで出来る範囲しかC++は認めない、というのも、酷い言い方だが確かにそうでもある。
同様に、C#も、usingの間抜けさに気づくのに8.0までかかったんだから、
C#12.0位で上記縛りを付けて廃止する方向になるのではないかな。
MとVを分離するのは現在既に常識だし、Vを分離している場合にはGDI+リソースについては上記(A)は必ず成立する。
ファイル等のその他アンマネージドリソースについては後回しになるだろう。
言語/プラットフォームとしての整合性/統一性が取れないが、C#は整合性より実質的利益を選択するはず。

447:デフォルトの名無しさん
19/12/28 09:59:17.52 6W1egYcc0.net
お前らは多分気づいていないんだろうけど、C系言語は「関数を抜けたらローカル変数は全て破棄される」為、
動作効率はいいが、関数を頻繁に抜ける＝GUIとは絶望的に相性が悪い。
GUIの場合は各イベント関数がトップレベル関数(C#コンソールアプリでいうmain)になるから、
上記「入れ子」での変数処理にかなり無理が発生してしまう。（アーキテクチャ的に無理）
ここら辺は最初からGUI用に設計されているJavaScript等をやってみれば分かる。
JavsScriptの場合は全部の関数がクロージャ付きだから、クラスと関数の区別もなく、関数に変数が紐ついてる。
だから、C系言語だとグダグダになるGUIも、JavaScriptなら比較的綺麗に書ける。
C#はいい言語だし、1つ学ぶならC#という選択も悪くはないが、他言語をやりさえすればあっさり見えることはある。
JavaScriptは糞だ糞だと言われて久しく、AltJSもやたら作られたが、いまだに殺しきれないのは、
結局のところ根幹のアーキテクチャ「全関数がレキシカルスコープのクロージャ付き」がGUI向けに圧倒的にフィットするからだ。
同様に、C#含めてC系言語がやたらあるのに、Cを殺しきれないのは、結局のところ、Cの根幹のアーキテクチャ
「変数の寿命とスタックの動作を一致させ、最速を得る」が圧倒的に素晴らしいからだ。
「変数の寿命を考えて設計しろ」なんてのは今も昔もそう言われてないが、（ただCにはそれしかないから言わずもがなだったが）
C#もC系ではあるのでC的手法で設計した方がフィットするのは事実。
寿命なんて考えたこと無かった奴は考える癖を付けた方がいい。
そして可能であればJavaScript等の「コンセプトがそもそも違う」言語を触ってみた方がいい。
そうすれば、C系言語が何を捨てて何を取ったかも分かるようになる。
具体的には（歴史的にはおかしい言い方だが）、GUI対応を捨てて速度を取っている。

448:デフォルトの名無しさん
19/12/28 09:59:55.78 6W1egYcc0.net
なお余談だが、そのGUIをグダグダにな�

449:轤ﾈいように設計として対処しよう、というのがMVCであり、これはやった方がいいのは事実だが、酷い話、 JavaScriptほどGUIと相性がいいとMとVが混ざっていようがなんとでもなってしまうのも事実で、これの最たる物がjQueryであり、jQuery自体ではなく使う奴の使い方の問題なのだが、レッテル貼られて丸ごと廃棄されようとしている。ただここら辺も、やれば、C#なんてGUIにはまるで向いて無く、だからMVCだバインディングだと手の込んだ仕掛けを作って誤魔化さないと駄目なのだ、というのが分かるようになる。だからまあ、設計の善し悪しが分かるようになってきたら、他言語を触ってみればいい。（分からないうちに触っても文法コレクターにしかなれず、意味無いから止めとけ）

450:デフォルトの名無しさん
19/12/28 10:32:20.67 Jn8dNYLra.net
FormがBackgroundプロパティを持たないでどうやって背景色を指定するのかな？
再描画の際にしかBrushのGDI+オブジェクトは使用されないのだから常にBrushがGDI+リソースを持ち続ける必要がないという主張であるなら、パフォーマンスを度外視すればその通りかもしれん。
しかしBrushがGDI+リソースと一対一対応するのではなく必要なときにだけ内部的にGDI+リソースを作るような設計思想なら、
そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
言語をいじるまでもない簡単な話。

451:デフォルトの名無しさん
19/12/28 11:00:39.51 b3ohKRMf0.net
今日も知ったか君が暴れてるw

452:デフォルトの名無しさん
19/12/28 11:09:23.84 mOzjhcRm0.net
予防線張ることに必死過ぎて何言ってんのかわからなくなってる典型だなこりゃ
自分の発言を自分で否定しながらお花畑垂れ流してる底抜けのアホ

453:デフォルトの名無しさん
19/12/28 11:11:57.13 e/19aGJmM.net
オブジェクト指向ではリソースは依存性として分離して注入するのが良い習慣とされる
なのでローカルスコープでいきなりリソース確保みたいなコードを書くことは稀だ
C#やJavaの世界ではリソースのライフタイムはDIコンテナが管理するものであってスタックに同期させるものではない

454:デフォルトの名無しさん
19/12/28 11:16:46.70 Jn8dNYLra.net
>>432
彼の主張は置いといて、生成タイミングの制御のためにDIでファクトリーオブジェクトを注入するのはよくあるパターンだぞ

455:デフォルトの名無しさん
19/12/28 11:45:36.16 yuB2IAbM0.net
cでもmallocしてりゃどこかで開放は要るだろ。
理屈すり替えて楽しいか？

456:デフォルトの名無しさん
19/12/28 13:24:27.10 6W1egYcc0.net
>>429
> パフォーマンスを度外視すれば
GDI+オブジェクトの生成ってそんなに重いのか？
> そもそもBrushのusingが一切必要ないようなアーキテクチャが十分に実現可能なんだよ。
その通りだ。だから.NET自体がボロいんだよ。
元々はGDI+オブジェクトのリソースが限られていたから、win98までは文句を言わず俺が言っている
「使うときだけ生成、使い終わったらすぐ解放」
しかなかった。これを「面倒」と思ったのか単にボケているだけなのか、
リソースが大幅に増えたこともあって問題にもならなくなった為、掴みっぱなしも出来るようになった。
.NET自体はWin32APIを隠蔽する為の物で、これ自体は良く出来ている。
ただ、俺は、君の言うとおり、もう一枚多く隠蔽して、usingが一切不要のフレームワークにした方がいいと思うけど。
もしGDI+オブジェクト生成が問題になるほど重く、キャッシュしたいというのなら、直接自前でGDI+オブジェクトを掴む必要がある。
だから.NETは今のアーキテクチャなのだ、と捕らえることも出来るが、
実際はそうではなく、単に皮を被せただけで、その皮の厚さが不適当だっただけだと思うよ。
まあこれはすぐに修正出来る話でもあるけど。

457:デフォルトの名無しさん
19/12/28 13:31:51.66 6W1egYcc0.net
>>432
> オブジェクト指向ではリソースは依存性として分離して注入するのが良い習慣とされる
そうだ。ただ、これがGUIとは絶望的に相性が悪いんだよ。
実際、Formsはこれで、各コントロールが値を保持してそれを参照する、というアーキテクチャだが、
事実としてこれは使いにくくて、WPFでばっさり修正されてるだろ。
(例としてはまんま

458:>>255で、彼が253の時点でいいと思っているアーキテクチャがFormsのものだ。だから俺は253はFormsしか知らない老害に文句を言われたのだと思っている）一応Webは当初は（というか一応今も）Javaでもクライアントコードを書けることになっている。ただ、JavaとJavaScriptだと書きやすさのイージーさの次元が違っていて、喧嘩にならないんだよ。一応アプレットが遅いだの色々理由が付けられてるけど、俺はJavaScriptの方が圧倒的に楽に書ける、というのが本質だと思うよ。 (仮に速くてもJavaは駆逐されてたと思う）不幸なのはGUIが出てきた時の覇権言語がCであった為、有無をいわさずGUIもCでやり、そしてそれを今でも引きずっている点だ。そしてその後はOOPが覇権を取ったから、GUIもOOPだという事になるのだが、これがまた間違いで、これを盛大にやらかしたのがFormsだ。 MVCのMなんて、OOP（特にJava)で禁忌とされるグローバルそのものだろ。 C系言語の変数管理そのものがGUI向きではないんだよ。そしてOOPの変数局在化思想もOOP向きではない。結果、Formsは二重に間違いを犯してる。

459:デフォルトの名無しさん
19/12/28 13:34:55.12 6W1egYcc0.net
>>436
最後訂正
x そしてOOPの変数局在化思想もOOP向きではない。
o そしてOOPの変数局在化思想もGUI向きではない。
まあ分かると思うけど紛らわしいので一応。

460:デフォルトの名無しさん
19/12/28 14:09:15.47 06FVqHz0a.net
うーん、なんかさすがに「アインシュタインは間違っている！」と主張するトンデモ本作者的な主張は草不可避w

461:デフォルトの名無しさん
19/12/28 14:31:37.94 6W1egYcc0.net
>>438
それが信者的態度だよ。
お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？
ただしこれはC#だけではなく、どの言語スレも割とこの傾向の奴が多いのも事実だが。
ただその態度は目を曇らせるから止めた方がいい。
C#が覇権を取れておらず、今後とも取れそうにもないのにも理由があるし、
JavaScriptが糞糞言われてもやたら蔓延っているのにも理由がある。
お前が何を好きかはお前の自由だが、何故そうなっているのかが分からないようなら単なる馬鹿でしかない。
勿論馬鹿であり続けるのも君の自由だが。
> URLﾘﾝｸ(www.youtube.com)
> ｽﾚﾘﾝｸ(tech板:69番)

462:デフォルトの名無しさん
19/12/28 14:54:05.52 yrEHcKMIM.net
そんなに良いものなら実装してC#チームにマージリクエスト出したら？
ここで演説しても全く時間の無駄だよ？
実装するのにスキル不足なら機能リクエストでもいい
C#はオープンソースなんだからさ

463:デフォルトの名無しさん
19/12/28 15:20:44.51 WD8h4qtV0.net
今でもJavaでもクライアントコードを書けることになっている、とか、どの世界の話だろう？
あと、自分は432じゃないけど、
> それが信者的態度だよ。
> お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？
というぐらいなら、C#以外の言語使えばいいんじゃない？って思ってしまう。
実際自分はプラットフォームに合わせて、アプリケーションの使いかたに合わせて8言語ぐらいから選んで使ってるけど。
あと、C#が覇権を取れていないとは全く思わないけどな。Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの？
UnityだってC#だし。

464:デフォルトの名無しさん
19/12/28 16:14:20.14 6W1egYcc0.net
>>440
俺は.NETを使っているのであって、C#は使ってない。
ただ、usingをどうするかは思想の問題であって、技術的に不足しているわけではないので、提案しても通らないとは思う。
（作ってる側も知っててそうしているはず）

>>441
そう思うならそ�

465:黷ﾅよし。 C#は良い言語だし健闘している方だが、Javaと食い合うなら死ぬのはC#だ。(俺はJavaが死んで欲しいのだが) OracleはJavaを技術的に成長させることは出来なかったが、ある意味余計なこともしなかった為、プラットフォームとしては既に膨れあがってしまった。後はC#で成果が出た仕様を順に取り入れていけば、「C#には負けない」言語にはなる。（勝てもしないが）同じような仕様で並立すると、死ぬのは小さい側のC#なので、当然C#は新規機能を追加して逃げ続けるしかない。これはこれで恩恵はあり、そうこうしているうちに勢力逆転出来ればいいが、今のところその芽もないだろ。 (Unityがそうだというのならそれでいいが） > Windowsで適当なアプリ作るなら普通みんなC#で書くんじゃないの？俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。その動画見ても一応トップだし。

466:デフォルトの名無しさん
19/12/28 16:38:51.11 WVh0vSeH0.net
ずーっと勝ちだの負けだのふわっふわなことこだわってるのなこのド近眼馬鹿
手前で他の言語持ち出してきて突っ込まれたら知らんから解説譲るとか逃げてるし
まさに無意味な頭でっかち文法コレクター（笑）を自ら体現してる
クスリでもキめてんのか？

467:デフォルトの名無しさん
19/12/28 22:03:53.41 WD8h4qtV0.net
>>442
> 俺は知らんが多分Python。大体ネット上ではブッ叩かれているが。
いやいや…
実情を知らなすぎだろう？C#なら実行ファイルの入ったフォルダごと渡したら実行できるようになるけど、
Pythonだと環境を作ったりとか結構めんどくさいぞ。大体GUIを考えたらPythonとか最悪でしょ。
「お前はC#以外の言語をいくつも知っていて、C#/.NETの良さ/悪さをちゃんと識別出来るのか？」とか言ってる割にはトンチンカンすぎる。
一応言っとくと、C#しか書けないからこう言ってるわけじゃなくて、Pythonもガンガン使って仕事してるからね。
あと、JavaはもうほとんどSIer専用言語みたいになってるから、C#と直接比較するのもナンセンスでしょ。
スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど、そこ以外で使わないだろ。それと一緒。
最強言語なんてのはない。色々なニーズに合わせて言語（プラットフォーム）を選んで何でも書けばいいんだよ。
手続き型言語だったら考え方は大して変わらないからね。

468:デフォルトの名無しさん
19/12/28 22:29:59.46 6W1egYcc0.net
>>444
そりゃお前の現状認識がおかしいと思うぞ。
インストールすら大変なら、Pythonがここまで蔓延ることはない。
何故かよく出てくるFORTRANガーってのも、FORTRANなんて実際もう誰も使ってない（と聞いている）し、
今のFORTRANは昔のFORTRANとは別物（と聞いている）ので、FORTRANを持ち出すのもおかしい。
それはVBを持ち出してBASICがまだ使われている、と言っているに近い。（はず）
多分お前もFORTRAN信者に嘘を吹き込まれているだけだと思うが、
冷静に考えれば見抜けるはずだが、FOTRAN全盛時代の連中はもうリタイヤかその辺であって、コードなんて書いてない。
あれはスパコンのCOBOL扱いになってるはずだが。
（もしかしてベクトルはFORTRANしか受け付けないのかな？これはあり得るが）
まあいいが。
いずれにしてもお前らが何故そんなに信者化するのかはいつも疑問だ。

469:デフォルトの名無しさん
19/12/28 22:34:45.14 yuB2IAbM0.net
自分が作ったものだけ動かすなら楽だもの。Python。
envで環境作らないといかんくなったらめんどくさい。
お前あんまり知らねえだろ。

470:デフォルトの名無しさん
19/12/28 23:12:31.42 WD8h4qtV0.net
>>445
開発用PCでプログラミングするだけで十分な場合と、デプロイが必要なアプリケーションを作るのは違うんだよ。
Pythonが流行ってるのはデプロイが必要なアプリケーションでなければ、かなり楽できるから。
デプロイするのは結構大変だよ。インターネット接続不可の環境でpipを使うのはめちゃくちゃ難しいし

471:。仕事でプログラム作ってアプリ納品したことないでしょ。その経験がなければプログラミングを語るなとは思わないけど、納品という観点でみたらナンセンスすぎるんだよ。よくも上から目線で「お前の現状認識がおかしい」と言えるね。あと、PythonでGUIアプリケーションを書くことに関してはスルーかな？ FORTRANの下りも、聞きかじった知識だけじゃん。科学技術計算でよく使われるBLASっていう線形代数のライブラリがあるんだけど、githubで見る限り半分はFORTRANで書かれてるよ。 https://github.com/xianyi/OpenBLAS/ 4,033 commitsとか書かれてるところの下の棒押してみ。 Fortran 49.3% Assembly 26.7% C 21.2% C++ 1.4% Makefile 0.8% CMake 0.4% Other 0.2% って出てくるから。あと、書かれてるコードも昔のFORTRANそのものでしかないコードだよ。 https://github.com/xianyi/OpenBLAS/blob/ce3651516f12079f3ca2418aa85b9ad571c3a391/lapack-netlib/SRC/dgebd2.f これを今でも皆コンパイルして使ってるわけ。スパコンだけじゃなくて、PCでもね。んで、プログラマーじゃなくて、研究者はいちいち他の言語とか覚えたくないから、今でもこういう乗りのFORTRANを使ってるわけ。 http://www.chem.konan-u.ac.jp/PCSI/DL_POLY/still_FORTRAN.pdf どうしてろくに自分で調べもせずに聞きかじったそれっぽい言葉を信じちゃうのか。「いずれにしてもお前が何故そんなに知ったかするのかはいつも疑問だ。」

472:デフォルトの名無しさん
19/12/28 23:13:03.41 H+9YQLdE0.net
自分とは違う意見=信者、と言うレッテル張り

473:デフォルトの名無しさん
19/12/29 00:26:30.89 EA/Onx+o0.net
>>447
もう意味がないから終わりでいいが。
> インターネット接続不可の環境
今更ねえし。それがC#なら楽チン！（とも思えないが、仮にそうでも）それが売りになるとでも？
> あと、PythonでGUIアプリケーションを書くことに関してはスルーかな？
当たり前だがGUI用のツールキットも死ぬほどあったはずだよ。ググればいくらでも出てくるでしょ。
> 4,033 commitsとか書かれてるところの下の棒押してみ。
それで飛んでいった先が
> C 3950
> Fotrran 3720
なんだが。コミットが多いだけでコードの数はCの方が上だし。
それ以前に今時のML向けのCUDAやOpenCLじゃFOTRAN使えねえだろ、と思ったが、
CUDAにはFortran出てるのな。ちょっとびっくりだわ。
> これを今でも皆コンパイルして使ってるわけ。スパコンだけじゃなくて、PCでもね。
君本人がFORTRAN書いているのか？それならまあそれでいいが。
そのスライドなかなか面白かったけど、2010年代がねえだろ。そういうもんだよ。
京がCとFORTRANのユーザー割合を公開していた気がしたが、出てこないんだな。
> 研究者はいちいち他の言語とか覚えたくないから
これはその通りだけど、だからこそ、年代的にFOTRANはほぼ絶滅してて、
今時はPythonで書かせろゴラアで、NumPyだCythonだが出てきてるわけだろ。
もし君がFORTRANを実際に書いているのなら、それだから君の周りにFORTRAN使いが多いだけであって、
やっぱり君の現状認識は間違ってると思うぜ。

474:デフォルトの名無しさん
19/12/29 00:34:45.31 jh70IlFa0.net
結局このスレで長文垂れ流して何がしたかったのかは永遠の謎だった

475:デフォルトの名無しさん
19/12/29 00:36:25.95 EA/Onx+o0.net
>>447
すまん、名前(TensorFlow)が出てこなかったので分かれてしまったがついでに。
GoogleのTensorFlowもPython,/C/Java,/Goであって、FORTRANは動かない。
CUDAは既に書いたようにFortranも出ているようだが、
元々はそもそも出す気もなく、ユーザーも「C++のサポートを」とは言っていたけどFORTRANについては言ってなかったと思うけど。
BLASのFORTRANをUpdateしている連中は、どこで何向けを流しているんだ？
現在のHPCはFORTRANなんて見てないと思うのだが。（上記CUDAやTensorFlowしかり）

476:デフォルトの名無しさん
19/12/29 00:40:06.58 9rgAI5qX0.net
GUI Programming in Python
URLﾘﾝｸ(wiki.python.org)

477:デフォルトの名無しさん
19/12/29 00:58:10.27 s3t0CIvz0.net
python製のwindowsアプリって何かある？

478:デフォルトの名無しさん
19/12/29 01:04:54.28 34CXn0hn0.net
凄えなGitHubの見方もまともにわからねえのかコイツ…
ここまで全方位に雑な上から目線キャラ初めて見たｗ

479:デフォルトの名無しさん
19/12/29 01:13:01.51 s3t0CIvz0.net
現時点でwinアプリ開発で採用される言語のトップにpythonなんか入るわけ無いと思うけど
普通にC++/C#/VB辺りじゃない？
VBは国内だけかな？
この次あたりはどれも似たようなもんでそこにpythonが入るとかならまぁわかる。
javaはwinアプリなんかで使われてるのかはわからんけど

480:デフォルトの名無しさん
19/12/29 01:17:48.90 s3t0CIvz0.net
ある程度の知識が広く浅くあるタイプの人間で技術屋以外に対して上手く話をして言いくるめるのが得意そうな感じ
あんま知らんけどSIerってこんな感じの人間なのかな？って見える

481:デフォルトの名無しさん
19/12/29 01:55:47.41 Jtzyjysr0.net
言い訳と反論が得意なイメージ有るけど。

482:デフォルトの名無しさん
19/12/29 11:03:14.73 HK/YahvcM.net
>>449
> 今更ねえし。それがC#なら楽チン！（とも思えないが、仮にそうでも）それが売りになるとでも？
いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。
> 当たり前だがGUI用のツールキットも死ぬほどあったはずだよ。ググればいくらでも出てくるでしょ。
で、使おうとしてみたことあるの？Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。
あとgithubのグラフの読み方は間違ってる。コミット数じゃなくて、コードの総量。
> 京がCとFORTRANのユーザー割合を公開していた気がしたが、出てこないんだな。
さっきのPDFに書いてあるとおり、FORTRANが1位だよ。

483:デフォルトの名無しさん
19/12/29 11:04:58.14 HK/YahvcM.net
>>449
> 今時はPythonで書かせろゴラアで、NumPyだCythonだが出てきてるわけだろ。
その辺は科学数値計算よりデータサイエンス系で盛り上がってるだけで、
色々余計なレイヤーがかぶさってるPythonが数値計算でnumpy、Cythonがあったとしても採用されにくいと
思うけどな。それこそメモリまわりの挙動とかで。
あと、tensorflowを例に挙げてHPCがどうこうと言ってたけど、ディープラーニングとかHPCの1ジャンルでしかないし、
ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。
で、なんでそんなに他人の違う意見に対して「自分は正しい。お前の現状認識は間違ってる」と自信満々に言えるの？根拠は？
聞いてる限り聞きかじりの知識ばかりで実際に作らずに良し悪しを決めつけてるようにしか思えないんだが。

484:デフォルトの名無しさん
19/12/29 11:46:41.74 vuWWhjO70.net
ここはC#スレだぞ

485:デフォルトの名無しさん
19/12/29 13:00:01.09 99B+H0jR0.net
ワッチョイスレなんだから各自NGすればよろし

486:デフォルトの名無しさん
19/12/29 13:26:29.34 KIjz0jVz0.net
日経Linux 2020/1月号に、
米田聡の記事「AI で鳩を自動認識、ラズパイ4 で3倍速」が載っている
TensorFlow Lite を使う、Google のEdge TPU の2製品、
Coral USB Accelerator, Coral Dev Board
CUDA なら、CPU の1/50 ぐらいの時間になる
ここは、C# のスレなので、以降は他のスレで議論してください！

487:デフォルトの名無しさん
19/12/29 14:36:52.40 EA/Onx+o0.net
>>458
概ね全面的に水掛け論だからまあもういいが、一応反論だけはしておく。
> いくらでもある。当然売りになる。というかセキュリティ要件で満たさなきゃいけない。
いや逆じゃね？ローカルにUSBメモリ刺してexe/dllを直インストールなんてセキュリティが厳しい要件で許可されるのか？
まあいいが。
> Pythonしか書けないってんじゃなければWinFormsの方がましとすぐに気がつく。
だから言ったとおり俺はPythonを使ってない。
> WinFormsの方がまし
ただ、これはない。Formsは壮絶にゴ�

488:だ。それはHTML/CSS/JavaScriptを使えばすぐ分かる。同様にWPFもゴミだが、Formsよりは数倍ましだ。そしてWPFがHTMLに寄せたのはMSもそっちの方が断然いいと判断したからだ。ただ、まだCSSが当てられないのが相当痛い。だから次は丸々HTML/CSSに寄せるはず。（というかWeb開発では事実上そうでしかないが) そもそもPythonもそっちに動いているっぽいだろ。>>452の頭の2つ、 > Cross-Browser Frameworks は多分それだよ。Pythonでローカルに鯖を立てて、それをブラウザで見るんだよ。(かそれに近い形式）というか俺なら最初からそうする。つまり計算用PythonはJSONインタフェースだけ付けて終わりで、後は全面的にHTMLの恩恵を受けられる。 HTMLの良さが分からないのは、君が知らないからでしかない。といっても別に難しいものではないから、やってみればいいんだよ。やれば、悲しいくらいに簡単にGUIを作れて、Formsとか本当にゴミだと実感出来るようになる。

489:デフォルトの名無しさん
19/12/29 14:37:27.40 EA/Onx+o0.net
> あとgithubのグラフの読み方は間違ってる。コミット数じゃなくて、コードの総量。
間違いは認めるとして、いずれにしてもナンセンスだからこれは止めよう。
BLASはAPIであって、当たり前だがOpenBLASは一つの実装でしかなく、
Cにもポートされているのだから当たり前のように同量のソースはあるし、
そもそもcommit回数を競ったところで意味がない。
BLASが使われるのがFORTRAN経由かC経由か、他の実装も含めての割合が問題であって、それはGitHub見てても分かりようがない。
君が示したのは、「今でもFORTRAN向けBLASの一つの実装がアップデートされている」という事実だけでしかない。
（それでも俺にとっては十分驚愕だが）
> さっきのPDFに書いてあるとおり、FORTRANが1位だよ。
本当にそうだったら「うええ、老害め」みたいに記憶に残ってるはずなんだがなあ。
と言っていても本当に水掛け論だから、こちらも調べたが出てこない。
ちなみに文部科学省のアンケートは出てきたが、これにはユーザー割合は載ってない。（ただし2006年の資料であり、相当古い）
URLﾘﾝｸ(www.mext.go.jp)
インストールされているのはFORTRAN100%、C92%なので、その当時はCが使えないスパコンってのも存在したのも事実のようだ。(P19)
> その他、スーパーコンピュータセンターからのコメントから、ＦＯＲＴＲＡＮ７７からＦｏｒｔｒａｎ９０への移行、
> あるいはＣ＋＋
への移行等、より記述性や生産性の高い言語への移行が進んできている印象を受けた。
君は移行すらしてない、という見解なんだろ。なんだかなあ。
> それこそメモリまわりの挙動とかで。
何が言いたいのか分からん。
Cのdllを呼んでるだけだぞ。C#でならunsafeでCのdllを呼んでるのと同じ。
全く問題ないし、関係ないよ。だからこれについてはC#でも何でもいいわけだが。

490:デフォルトの名無しさん
19/12/29 14:38:02.85 EA/Onx+o0.net
> ディープラーニングとかHPCの1ジャンルでしかないし、
> ディープラーニングの分野ではFORTRANが使われてない、以上のことを示してないよ。
今寄ってたかってホットなのは明らかにここだし、これを外して何を言うんだ？
問題は、こういった新しい環境ではFORTRAN向けの環境整備なんてされてない、ってことなんだよ。
だから正確には、「新しいHPC環境ではFORTRANは使えない」だよ。
俺は君が
> スーパーコンピュータで科学技術計算する分野では今でもFORTRANが主役だけど(>>444)
という明らかな嘘を言ったことを咎めている。
「環境自体がない」んだからそんなわけがないだろ。
何も知らない若い奴らが信じてしまう可能性もあるのだから、明らかな嘘をついてミスリードするようなことはするな。
色々見解が違うのはいいとしても、これはねえよマジで。

491:デフォルトの名無しさん
19/12/29 14:51:21.50 mqdEA2UD0.net
WPFはHTMLに寄せたんじゃねえよ。
XMLとしてvalidだろ。

492:デフォルトの名無しさん
19/12/29 15:06:33.85 EA/Onx+o0.net
>>466
C#er的公式見解がそうなのは知ってる。
ただ、機構は丸パ�

493:Nしてるだろ。 HTML/CSS/sjavaScriptのよい点は A. テキストで書くだけ。ボタンなら"<button>Click Me</button>"だけ。 B. CSSが当てられる。 C. イベントがバブルする。 D. JavaScriptから値を弄ってもイベントは発生しない。 E. イベントは非同期、つまり必ずキューイングされる。で、WPFは（といっても俺は使ってないが） A. はまあ許容範囲（もうちょっと簡単に書かせろよとは思うが） B. 出来ないのが悲しい C. 問題なし D. E. 知らない。Formsはイベントが発生してしかも同期イベントなので地味にこれがものすごく使いにくくて糞。　直っていることを期待するが、そもそも俺はWPFを結果的にスキップしそうになってる。だろ。AはXMLからとしても、Cはパクったろ。そしてCは地味に素晴らしい。といってもFormsから移行した奴らは活用してないかもしれんが。

494:456
19/12/29 15:10:58.86 KIjz0jVz0.net
VSCode で良い。
markdown も表示できるし
Python は、Jupyter Notebook でも良い。
Julia, Ruby でも使えるし
VSCodeは、Electron だから、Node.js + Chromium だろ。
Ruby の標準サーバーを立ててもよいし

495:デフォルトの名無しさん
19/12/29 15:26:07.21 J2Lmqp1KM.net
>>468
ルビ糞は教祖様推奨のEmacsを使えカス

496:デフォルトの名無しさん
19/12/29 15:26:34.81 fYAoNqJEd.net
コントロールに適用したいStyleがあるので、Generic.xaml を作成して、
App.xaml で ResourceDictionary.Merge Dictionaryしました。その中で自作のコンバータークラスを使いたくて定義したのですが、どうしても認識してくれません。ビルドは通るのですが、実行時に見つからないエラーがでます(xaml parse exeption)
同じ定義を App.xaml の中で、Generic.xamlをマージする前に書くと、何故か実行時にエラーも出ませんし、ちゃんと動きます。
Generic.xaml の中でコンバーターを定義することは出来ないのでしょうか

497:デフォルトの名無しさん
19/12/29 15:30:19.53 Lr7vQfGy0.net
テキスト送信して相手にレンダリングさせるものと自身のウインドウ環境に直接レンダリングするものを本気で横ならびで比較する時代になったのね

498:デフォルトの名無しさん
19/12/29 15:59:41.03 EA/Onx+o0.net
>>471
なったというか、いわゆる(短期的な)「生産性」ってのは、どうでもいいところで如何に手を抜くか、でもあるからね。
グラが勝負なら自前でレンダリングしかないが、
>>255とか俺とか、>>458もほぼ確実にそうだと思うが、
計算ソフトの初期値設定をするだけ、みたいなGUIに時間かけて凝っても意味無いんだよ。
そこは「計算」に凝るべきであって、とりあえず多少遅かろうが表示出来れば何でもいいんだよ。
というか、こういうのを分かっててお前らはC#を選んでいるんじゃないのか？
ならまあ、お前らが奇妙なほどに信者化するのも分からなくもないが。
ちなみにUnity、内部エンジンはC++で上位スクリプトだけC#か？なら確かに芽があるかもしれん。
しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。

499:デフォルトの名無しさん
19/12/29 16:06:57.90 mqdEA2UD0.net
>>467
機構のどこが丸パクリなんだよ。
Cだけじゃねえか。
Formsでもイベントのさばき方次第だろ。全然Forms触ってねえだけじゃねえか。
で、イベントも普通はそう捌くんじゃなくて、バインディングするもんだよ。
何意味不明な事言ってんだよ。

500:デフォルトの名無しさん
19/12/29 16:08:17.70 ot6kdVlr0.net
語れば語るほど行毎に突っ込みどころ量産してるのが凄い…
釣りでガイ�

501:Wのフリやってるなら大したもんだわ

502:デフォルトの名無しさん
19/12/29 16:11:04.28 RdqvkJW90.net
> ちなみにUnity、内部エンジンはC++で上位スクリプトだけC#か？なら確かに芽があるかもしれん。
> しかしこの構成なら、じきに上位スクリプトもPythonで書かせろ、になるとも思うが。
なんでこんな予測になるのか意味不明
unityから使用できるjavascriptが廃れた経緯があるのにまた変更なんかこないよ
ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
新しいエンジンが来たときにその時代に沿った新しい言語が採用される可能性はある

503:デフォルトの名無しさん
19/12/29 16:14:19.03 8r12tXQy0.net
実際にUnityで選択肢として使えたjsとpythonがC#に駆逐された経緯とか知ったらこのキチガイ脱糞しそう

504:デフォルトの名無しさん
19/12/29 16:27:43.79 EA/Onx+o0.net
>>473
逆だろ。Bはこれからパクる、Cはパクリ、D/Eは直っていればパクリ、直ってなければ糞だ。
あとFormsはバインディングできない。（から自前でやるにはReflectionすることになり、これが糞）
ただバインディングについては、
バブルされたイベント拾ってそこでバリデーションして問題なければ反映、アウトなら戻す、
みたいな方が格好悪いが結果的に楽な気はする。
(既に言ったとおり俺自身がWPF使ってないから全てに於いてバインディングだけで上手く行くのかは分からない。
勿論全く問題ないならバインディングした方がいいけども)

>>475
>>476
おお、その釣り針は喜んで食いつくから、駆逐された経緯とか書いたページがあれば紹介してくれ。
つってもちょっと（席を）外すが。

505:デフォルトの名無しさん
19/12/29 16:36:33.93 RdqvkJW90.net
食いつかんで良いから自分の浅はかな知識で事を語っていることを認識し悔い改めていただきたい
知りたきゃご自身でお調べ下さい

506:デフォルトの名無しさん
19/12/29 17:14:51.69 mqdEA2UD0.net
>>477
WPFがバインディングが基本だと言っとろうが。
FormsにもDataSourceと言う概念があって出来んもんでもないしリフレクションも必要ではない。

507:デフォルトの名無しさん
19/12/29 18:30:55.82 2GmPR76J0.net
>>467
> B. CSSが当てられる。
> B. 出来ないのが悲しい
書くのが異様に面倒だけどスタイル定義はできるよ
てか、よく知らないならROMってれば？

508:デフォルトの名無しさん
19/12/29 19:00:10.06 EA/Onx+o0.net
>>479
> DataSource
ああそれは確かに俺は触ってないわ。何かあったけど放置してた。
一応軽く見てみたが、ちょっと使ってみないと分からんね。
.NETは若干かっこよさを追求しすぎていて、既に言った
「フォームの値をプログラムから変更してもイベントが『同期』で発生する」
もそうだけど、格好良く自動連動を目指したのだろうけど、余計に使いにくくなってる。
同様に、余計なイベント接続が行われている可能性もあるから、実際に使えるかどうかは試してみないと分からん。
JavaScriptの場合はもっとドベタに
「プログラムから変更したらイベントは発生しないから、必要なら自分で呼べ」
でしかないから、本当にドベタにユーザーが挙動を定義出来る。
言ってしまえば、JavaScriptはライト層向けにできていて、
.NETはプロ向け（.NETのことを隅々までよく知っている前提）だと言えなくもないが、
ちょっとチューニングを失敗しているように思う。
結果、JavaScriptの方が取っつきやすいから、最近はどうでもいいUIはだいたいWebアプリになってるだろ。

>>480
これか？
URLﾘﾝｸ(www.atmarkit.co.jp)
これは確かにCSSの一部だが、これでは全然足りない。
スタイルを適用したいのはコントロールそのものに、ではない。
CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
だから見た目全く違う物も同じHTML構造を取れ、結果、
同じ関数からお約束のHTMLを吐き出して後はCSSでも当てて、みたいな手抜き�

509:ｪあっさり出来る。（見た目毎に出力関数を用意する必要がない） CSSの表現能力についてはWeb系の馬鹿共がよく「CSSでここまで出来る！」みたいなページを作っているから見てみればいい。

510:デフォルトの名無しさん
19/12/29 19:12:12.77 RdqvkJW90.net
詳細を突っ込まれると
そうだね、けどこの面では…的な論理展開ばっかだけど自分で気にならないの？
これを繰り返してるうちに自身の主張が何かよくわからなくなって無意味に多方向にdisを撒き散らしてるだけになってる

511:デフォルトの名無しさん
19/12/29 19:21:15.54 2GmPR76J0.net
>>481
> CSSが美味しいのは、左右はもちろん上下ですら表示位置を簡単に入れ替えられること。
それはコンセプトの違い
WPFはXAMLでコントロールの位置を変えればいいだけ
データとはバインディングで繋がってるから位置を変えてもDataSourceはいじる必要はない

512:デフォルトの名無しさん
19/12/29 19:24:54.99 mqdEA2UD0.net
>>481
自動連携なんて目指してない。
変更したならイベントが起こって然るべきだからイベントが起こるんだよ。

513:デフォルトの名無しさん
19/12/29 19:33:22.61 EA/Onx+o0.net
>>478
以下は読んだ。
URLﾘﾝｸ(blogs.unity3d.com)
開発側の人的資源の問題と、C#のIDEが素晴らしいからだな。
まあ妥当といえば妥当。（というかそう読めるように書いてあるもんだが）
そもそもJavaScriptが動くとは知らなかったし、信者でも無いから、ダメージもないのだけど。
まあそれ以前に俺はここだからC#の話をしているだけであって、
JSはJSでそれなりに糞だから、JSスレでならJSの悪口言ってるよ。
C#のIDEが圧倒的にいいのは事実だよ。あれと同じ物を自前で用意するのは無理だ。

514:デフォルトの名無しさん
19/12/29 19:53:49.10 RdqvkJW90.net
>>485
で、unityはそのうちpythonになるだろうという君の主張はどうなったの？
また同じ論理展開で主張が飛んでるよ？
そんなの知ったこっちゃないってのなら始めからズレた主張しないでね

515:デフォルトの名無しさん
19/12/29 20:00:11.04 EA/Onx+o0.net
>>483
だからそれが駄目だと言ってるんだよ。
XAMLを変更＝HTMLを変更と同じで、それだと、全く同じ関数とか使えないんだよ。
XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
すると、イベント周りも修正が必要になってくるだろ。
CSSだけで位置変更出来れば、本当に表示位置だけを変えられる。
バブルしてくるイベントはHTML通りにバブルしてくるから、見た目重なってもいない要素からもバブルしてくるようにも出来るんだが、
それだからこそ、同じプログラムで対応出来るんだよ。
違うのは人間からの見た目だけであって、プログラム上からの見た目は同じだから。
と、説明しても意味分からんと思うけど、多分やれば分かるよ。
「こんな手抜きの仕方があるのかよ！」みたいな事が結構出来たりするから。
典型的な例だと、HTML/CSSでは display:none （表示させないだけ、Formsで言う Control.Visible = false)を多用する。
勿論上記の通りFormsでも出来るけど、文化的にほぼ使われてないでしょ。（と俺は思っている）
ここら辺の手抜きの仕方がWeb系の方がこなれてる。
俺もそうだったが、,.NET界隈も真面目にプログラミングやりすぎてるんだよ。
「常に見えない設定の物を表示ルーチンに渡すのは無駄だ」というのは当たり前だけど、
それで別関数になるくらいなら、display:noneで同じ関数使おうぜ、ということ。
CSSの表現能力が高いからこれがかなり有効なんだよ。

516:デフォルトの名無しさん
19/12/29 20:05:42.44 rG0bhEhQ0.net
かまうほうも頭おかしいんだけど自覚ないの

517:デフォルトの名無しさん
19/12/29 20:06:05.21 EA/Onx+o0.net
>>484
原理原則論としてはそうなのだろうけど、だから逆に使いにくくなってるんだよ。
多分これも、JavaScriptみたいに「自前でやらないと発火しない」フレームワークを使えば分かるよ。
君が既に両方使ったことがあって、
HTML/CSS/JavaScriptよりも.NETの方が�

518:gいやすいと判断しているのなら、それでいいが。

519:デフォルトの名無しさん
19/12/29 20:06:32.69 RdqvkJW90.net
なんでxamlとhtmlの比較の典型例にformsがでてくんの？
xamlでもコントロールの非表示なんて日常茶飯事だと思うが

520:デフォルトの名無しさん
19/12/29 20:08:02.86 kYkJMpoK0.net
cssを採用したjava fxってどうなったんだろうね？

521:デフォルトの名無しさん
19/12/29 20:12:37.27 EA/Onx+o0.net
>>486
ん？Pythonについてなら君の言うとおり、
> ゲーム開発においてスクリプト言語が来る時代は来るかもしれんがそれはunityにはこんだろう
これについては納得したぞ。俺の負けでいい。
あのブログはもう2-3年前になるが、まあ、少なくともunityにはスクリプトは来ないね。
あれはC#と心中する、という決断だ。（逆に言えばC#は死なないとunityは判断してる）

522:デフォルトの名無しさん
19/12/29 20:20:44.20 PurJ6L2e0.net
差し支えなければどなたか >>470を…

523:デフォルトの名無しさん
19/12/29 20:21:07.58 2GmPR76J0.net
>>487
> XAMLを弄って変更した場合、文書階層が変わるから、バブルしてくるイベントも経路が変わってしまうだろ。
WPFではイベントは直接使わないよ（使うこともできるけどあまりよろしくない）
モデル側でコマンドを定義してコントロールにバインドする
って言っても君にはちんぷんかんぷんかもね
まあ理解する気なさそうだから君はそのままでいいと思うよw

524:デフォルトの名無しさん
19/12/29 20:21:43.91 by75XqYfM.net
>>492
俺は複数の分野を横断的に知ってて各方面の弱いところをよく知ってる、だからマウントとれる、
と思ってるのかもしれないけど、職業プログラマだったらそんなの実務レベルで当たり前で、
むしろある分野を専門的にやってる人には勝てないなと思ってるからそんな大げさな物言いはしないんだけどね。
（〇〇の分野だと□□という概念があるんだけど、△△だとそういう概念はある？ぐらいに控えめに話題にする）
「C#信者」、「FORTRAN信者」だの、「Web系の馬鹿共」だの、「HTMLの良さがわからないのは君が知らないからだ」だの、
「説明しても意味わからんと思うけど」だの、よくもまあ自分以外を下に見る発言が沢山出てくるもんだ。
皆、あんたが偉そうに発言する割には、中身が誰でも思いつくことでしかも間違いが多いからツッコミを入れてるだけだぞ。それを「こいつはわからないから反論してきてるんだ」と思うようじゃ単なる天狗で自分の成長につながらないよ。
このスレでたった2日やりとりしたぐらいで、経験知識不足で頓珍漢な理屈を並べてると思われちゃってるんだから。
最終的に、実世界で相手されなくなって5chに書き込むしかなくなる悲しい人生になるぞ。
> 「今でもFORTRAN向けBLASの一つの実装がアップデートされている」
正直笑ってしまった。わかってないようだがOpenBLASはFORTRANのコードをコンパイルしてCから呼び出すんだよ。
FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。

525:デフォルトの名無しさん
19/12/29 20:23:58.98 EA/Onx+o0.net
>>490
そうなら第一段階は出来ていることになる。
でも本当にそうなら、もっとStyle側に押し込めればコードを減らせる＝XAMLのスタイルなんて非力すぎる、
というのも実感出来てるはずだけど。

>>491
俺についてはCSSを採用してることすら知らなかったな。
ただJavaのGUIはどうやっても死んでるだろ。
色々原因は言えると思うが、既に言ったとおり、Javaの変数管理がGUIに向いてないんだよ。
これはC#も同じで、よく騙して来れてる方だよ。

526:デフォルトの名無しさん
19/12/29 20:25:19.89 RdqvkJW90.net
>>492
勝ちとか負けとかそんな話してないんですが…
俺が突っ込めるのは俺がわかる範囲だけだが、そういった浅い知識で何でも語る人間なら全ての話が適当なんだろうなとしか見えないね

527:デフォルトの名無しさん
19/12/29 20:25:25.54 2GmPR76J0.net
>>490
たぶんID:EA/Onx+o0はWPFのことをFormsをXMLで記述できるようにしたもの程度の認識なんだろうと思う

528:デフォルトの名無しさん
19/12/29 20:33:25.70 EA/Onx+o0.net
>>494
> モデル側でコマンドを定義してコントロールにバインドする
そんなことになってんのかよ。
んー、まあ何か理由はあるんだろうけど、格好良すぎて余計に分かりにくくなってる気はするが。
まあいずれにしても俺の勉強不足はそのとおり。俺はWPFはやってないし、今すぐやれる準備もしてないからね。

>>495
だからそもそもマウント取りに来ていると考えているのが間違いなんだよ。
なんで一々そんなことしないといけないんだよ。
> FORTRAN専用のコードじゃない。CやFORTRANで呼び出せる共通バイナリをFORTRANで書いてるの。
おーマジか。知らんかったわ。というかFORTRANのバイナリなんて呼び出そうともしたこと無いし。
してOpenBLAS以外はFORTRANで書かれているのか？
Cじゃねえの？という気はするし、それ以前にアセンブラで書く気はするが。（勿論Cのインラインアセンブラな）

529:デフォルトの名無しさん
19/12/29 20:37:07.30 EA/Onx+o0.net
>>497
> 勝ちとか負けとかそんな話してないんですが…
メンドクセエ奴だな、じゃあどう言って欲しかったんだよ？
俺のことをどう見るかは君が決めることであって、俺がどうこう言っても意味無いだろ。
好きにすればいい。

530:デフォルトの名無しさん
19/12/29 20:44:08.21 RdqvkJW90.net
>>500
適当な知識を撒き散らし嘘を広めるような言動をやめてほしかったんですよ

531:デフォルトの名無しさん
19/12/29 20:44:40.41 by75XqYfM.net
>>499
初めの主張を否定されたら「知らんかったわ。だけどこれはどうなの？」とか言って話をずらすのは、
気付いてないのかもしれないが、マウントを取る行為そのもの。
会話をしている相手への礼儀に欠いている。
少なくともFORTRANが現状では死んだ言語だという主張は間違いなわけだ。あんたが呼び出そうとしたこともないかどうかで事実が変わる訳でもない。
やったことない領域は分からないんだと謙虚な態度で考えることがエンジニアリングにおいても人間関係においても大事。
伝聞からの外挿で精度の悪い話を吹聴しても勝てないんだよ。相手は大抵人間じゃないか自分より能力や経験値が高いから。
日常が精度の悪い話で勝てる状況なら、正直その環境を見直した方がいいと思うぞ。低レベルな環境で過ごしてて、知識や技術は身につかないのに歳だけ取るということになるからね。
エンジニアリングを生業にしてないのなら、まあ、趣味の範囲で好きに生きるといいと思うよ。

次ページ