26/05/25 01:59:44.39 nvu762kR.net
C#の新たな方針がRustの真似
>>1
>> unsafeで定義された関数は、コール元が明示的にunsafeブロックで呼び出す必要があり、適切なドキュメント（/// <safety>ブロック）で安全性の契約や義務が明示される。
>> ポインタ型がシグネチャに含まれるだけでは自動的にunsafeにはせず、実際に危険な操作(例えばデリファレンス)が発生する箇所ごとに明示される形となる。
3:デフォルトの名無しさん
26/05/27 12:45:45.72 WCS5U2KA.net
阿鼻叫喚
4:デフォルトの名無しさん
26/05/27 16:08:15.94 PZQy1Xr7.net
Rustの存在意義無くなっちゃったじゃん
5:デフォルトの名無しさん
26/05/27 18:53:08.40 SBCRghEW.net
C#はガベージコレクション方式の遅い言語
C/C++/Rustの速さや使用メモリの少なさをC#は実現できない
6:デフォルトの名無しさん
26/05/27 20:51:34.31 dSJ8g9Ow.net
>>4
んなこたーない
7:デフォルトの名無しさん
26/05/30 04:10:51.03 OeNHKzAz.net
関数やブロックにunsafeするだけでいいんだよ
プロジェクトにunsafe許可とか必要ない
もっと気軽にunsafe使わせろ
そもそもポインタごときでunsafeとかダメグラマかよ
8:デフォルトの名無しさん
26/05/30 15:18:51.41 5fXXCMxe.net
c#好きだけど、unsafe使いたいから使ってるわけじゃないんだよなあ
9:デフォルトの名無しさん
26/06/26 15:16:52.82 R6afI80t.net
>>5
プログラミングエアプか？
GCは速いぞ
ChromeはC++で作られてるけど独自のGCを使ってる
Rustが重宝されるのはレイテンシが小さいからだ
10:デフォルトの名無しさん
26/06/26 16:42:26.29 +1B9IjoT.net
>>9
GCは遅い
C++でもRustでもメモリ管理はアリーナ方式がベスト
割り当て解放が速く、断片化しないためCPUメモリキャッシングにも有利
11:デフォルトの名無しさん
26/06/26 22:19:01.91 R6afI80t.net
やはりエアプか
12:デフォルトの名無しさん
26/06/26 22:24:27.32 maA58Mlv.net
ガベージコレクションは確実に遅くなる
その遅さと引き換えに他のメリットが上回るときに用いられるレアケースがある
滅多にないため通常はガベージコレクションは候補にせずに無視していい
13:デフォルトの名無しさん
26/06/27 00:01:41.06 D69zuVLr.net
逐次解放が速いなんてありえねえしアリーナ使えるのは条件が限られるガベージコレクションこそが一般的で高速なメモリ管理だよ、メモリが十分にあるならGCがされないことだってあるからね遅延させて必要な時だけメモリを解放する、これよりも良い方法は存在しません
14:デフォルトの名無しさん
26/06/27 00:07:39.52 D69zuVLr.net
C#がCなどに比べて遅いのは仮想マシンで実行されるからでメモリの確保を大量にこなす処理はC#の方が速い、マネージメモリをまとめて確保してるからね、手動でやれば速くなるなんてのは幻想よRustもゴミ、以上
15:デフォルトの名無しさん
26/06/27 01:48:25.86 c7cFpiQD.net
C#が遅い理由はGCに依存しているため
16:デフォルトの名無しさん
26/06/27 02:00:33.11 YqZxmVSt.net
数字出さずに感想文だけ書くやつは無能
17:デフォルトの名無しさん
26/06/27 02:04:32.43 ID3kKpvp.net
>>13
無知すぎる
ガベージコレクションが開始されなくてもガベージコレクション言語が遅い理由をまずは理解すべきだ
18:デフォルトの名無しさん
26/06/27 02:15:41.04 ZhnlnZJx.net
メモリが十分にあってGCが発動しなくても、GC言語は各種ベンチマークで、なぜC/C++/Rustに勝てないのか？
その理由は、GC言語はGCできるようにメモリ管理をせざるを得ないためだ。
19:デフォルトの名無しさん
26/06/27 08:40:51.74 D69zuVLr.net
>>16
あなた無能ってことですやんｗｗｗ
20:デフォルトの名無しさん
26/06/27 14:22:36.42 i5PSImc0.net
それってあなたの感想ですよね
21:デフォルトの名無しさん
26/06/27 18:35:33.80 vL0XygNT.net
>>14
手動とはどういう意味でしょう？
例えばそのRustで構造体のオブジェクトを作るとすると
その値を格納する変数はスタック領域に確保されます
そのメモリ割り当て解放コストは他のローカル変数とまとめてスタックポインタを加算減算するだけでコストは最小
これら自動ですので手動ではありません
22:デフォルトの名無しさん
26/06/27 18:38:11.62 vL0XygNT.net
ではその構造体オブジェクトを作る関数が先ほどの変数>>21へ値を返す時はどうなるでしょうか？
その値が小さければレジスタで返されます
その値が大きければ自動的に先ほどのスタック上の変数のアドレスが関数へ渡されてダイレクトに返す先の変数に値が書き込まれます
このようにオブジェクトの値のやりとりコストも最小
そしてこのオブジェクト作成関数ではオブジェクトのメモリの確保が不要
これらも自動ですので手動はありません
23:デフォルトの名無しさん
26/06/27 18:40:24.54 vL0XygNT.net
最後に変数>>21に格納された構造体オブジェクトの値を用いる他の関数を呼び出す時はどうなるでしょうか？
不変参照(書き換え不可)か可変参照(書き換え可能)を関数へ渡します
先ほどのスタック上の変数のアドレスがレジスタに格納されて関数へ渡されるだけでコスト最小です
以上ここまでメモリの割り当てと解放のコストは最初のオブジェクト格納変数のためのスタックポインタの加算減算しか生じていないです
だから速いのです
24:デフォルトの名無しさん
26/07/01 23:53:23.48 xfe/unY1.net
>>9 >>13-14
流石にGCがいくら高速になってもメモリの確保・解放にプラスして管理コストが乗っかる以上、メモリの確保・解放のみより軽くなることは理論上あり得ないことくらいはわかっておくべき
25:デフォルトの名無しさん
26/07/02 00:01:31.02 bbwDIcek.net
>>21-23
複数の点で間違っている
まず、ランタイムが管理するのではなくソースコードで利用されている場所や解放のタイミングを定めることを「手動管理」と呼ぶのであり、Rustは手動管理を行う言語である
また、メモリ割り当てコストはスタックポインタの加算のみではなく、OSによる処理が介在するしこちらの方がはるかに重い、しかもGCの話と何の関連性もない
メモリがどこから参照されていてどの時点で利用されなくなったか、管理する処理を全てランタイムが実行時に行うのがGCである
参照カウンタによる管理（ARC, ORC）のような中間の機能を備えた言語も存在するが、いずれにせよGCは管理コストが重いことは確かである
26:デフォルトの名無しさん
26/07/02 16:41:43.90 uhOY6xpy.net
>>24
バカ乙
メモリがリンゴだとする
リンゴを収穫する時に1個ちぎって1個ずつ運ぶより何個もちぎって箱に入れてまとめて運んだ方が速いだろ、箱を管理するコストが増えるが運ぶコストが減るから結果的に速くなるわけ
27:デフォルトの名無しさん
26/07/02 17:58:33.20 CnMkjRrm.net
>>25
あなたの理解が不足している
それらに書かれていることを別の表現にすると
『Rustはスタック上にオブジェクトなどの値を置いたまま他の関数でも安全に扱える』
メモリの確保と解放はスタックポインタの増減のみなので最も高速で正しい
そしてその関数を抜けると自動的に解放されるから「自動管理」で正しい
一方でベクターなど複数個の大きな領域を必要とする場合はもちろん自動的にヒープ領域にまとめて確保されてまとめて解放される
Rustはそこでも手動解放は必要なくて基本はそのベクターを宣言した関数を抜けると自動的に解放されるから「自動管理」で正しい
関数の返り値として返せば解放されずに上位の関数に移るが返り値として返すことはGC言語でも同じく行なう自然な行為なのでそれが手動管理と呼ばれることはない
28:デフォルトの名無しさん
26/07/06 14:44:28.59 wKirmoVj.net
>>26
GCはまとめてメモリを消し飛ばす機能ではなくて、一つずつ使用状況を確認して使ってないものを解放する機能なので君の理解が100%間違ってるだけだね
29:デフォルトの名無しさん
26/07/06 14:51:17.40 wKirmoVj.net
>>27
それはRAIIが何かわかっていないから起こる勘違いだね
単にC言語では free() と書けばメモリが解放されるのと同じく、Rustでは何もせずにスコープの末端まで来ればメモリが解放されるだけ
スコープの末端に必ず free() が挿入されるだけなので、これを自動管理と言うならこの世に手動管理は存在しない
そうなると、手動管理が存在しないのに、自動管理という言葉を使う君がおかしなことを言っていることになる
これは矛盾だね
私が言っているのはそれとは違って、ソースコードであらかじめメモリを解放する位置を明示し、また参照・借用や所有権、ライフタイムといったメモリ管理について常にプログラマが制御する必要がある方式のことを「手動管理」と言っている
GCにはこのようなことはなく、メモリは全てランタイムが実行時に管理するため、ソースコード上に解放される位置は書かれていないし、プログラマもメモリ管理を意識することはない
30:デフォルトの名無しさん
26/07/07 00:19:27.15 73yWDig3.net
下手糞のMTはATより遅い
31:デフォルトの名無しさん
26/07/07 06:05:40.12 +R9WRXbp.net
>>29
それはRAIIの理解不足
RAIIはブロックなどのローカルスコープで宣言したものはそのスコープを抜ける時にも存在していれば自動的にそのリソースが解放される自動管理の仕組み
ただしそこへの参照が残っていれば自動解放されるとダングリンク参照になってしまい危険
Rustはコンパイラが参照連鎖も静的にチェックするため必ずそれを防いでくれるため実用的な自動管理になった
一方でそれらの機構のないGC言語ではローカルスコープを抜けても自動的にそのリソースを解放していいのかわからない
そこへの参照が残っているのか実行前に静的にコンパイル時点で判断できないためだ
だから定期的に参照連鎖を実行時に動的にチェックするガベージコレクション(GC)が必要になる
そして実行時に参照連鎖を追えるようにするためのコストの高いメモリ管理をせざるを得ない
それゆえGC言語は実行が遅くなるだけでなくGC発動まで無駄にメモリを占有してしまう