C#が新unsafeでメモリ安全に Rust/Swiftへの言及も

Improving C# Memory Safety
https://devblogs.microsoft.com/dotnet/improving-csharp-memory-safety/

C# 16、メモリ安全性を強化する新たなunsafeモデルを導入へ
https://codezine.jp/news/detail/24314

C#の新たな方針がRustの真似

>>1
>> unsafeで定義された関数は、コール元が明示的にunsafeブロックで呼び出す必要があり、適切なドキュメント（/// <safety>ブロック）で安全性の契約や義務が明示される。
>> ポインタ型がシグネチャに含まれるだけでは自動的にunsafeにはせず、実際に危険な操作(例えばデリファレンス)が発生する箇所ごとに明示される形となる。

阿鼻叫喚

Rustの存在意義無くなっちゃったじゃん

C#はガベージコレクション方式の遅い言語
C/C++/Rustの速さや使用メモリの少なさをC#は実現できない

>>4
んなこたーない

関数やブロックにunsafeするだけでいいんだよ
プロジェクトにunsafe許可とか必要ない
もっと気軽にunsafe使わせろ
そもそもポインタごときでunsafeとかダメグラマかよ

c#好きだけど、unsafe使いたいから使ってるわけじゃないんだよなあ

>>5
プログラミングエアプか？
GCは速いぞ
ChromeはC++で作られてるけど独自のGCを使ってる
Rustが重宝されるのはレイテンシが小さいからだ

>>9
GCは遅い
C++でもRustでもメモリ管理はアリーナ方式がベスト
割り当て解放が速く、断片化しないためCPUメモリキャッシングにも有利

やはりエアプか

ガベージコレクションは確実に遅くなる
その遅さと引き換えに他のメリットが上回るときに用いられるレアケースがある
滅多にないため通常はガベージコレクションは候補にせずに無視していい

逐次解放が速いなんてありえねえしアリーナ使えるのは条件が限られるガベージコレクションこそが一般的で高速なメモリ管理だよ、メモリが十分にあるならGCがされないことだってあるからね遅延させて必要な時だけメモリを解放する、これよりも良い方法は存在しません

C#がCなどに比べて遅いのは仮想マシンで実行されるからでメモリの確保を大量にこなす処理はC#の方が速い、マネージメモリをまとめて確保してるからね、手動でやれば速くなるなんてのは幻想よRustもゴミ、以上

C#が遅い理由はGCに依存しているため

数字出さずに感想文だけ書くやつは無能

>>13
無知すぎる
ガベージコレクションが開始されなくてもガベージコレクション言語が遅い理由をまずは理解すべきだ

メモリが十分にあってGCが発動しなくても、GC言語は各種ベンチマークで、なぜC/C++/Rustに勝てないのか？
その理由は、GC言語はGCできるようにメモリ管理をせざるを得ないためだ。

>>16
あなた無能ってことですやんｗｗｗ

それってあなたの感想ですよね

>>14
手動とはどういう意味でしょう？

例えばそのRustで構造体のオブジェクトを作るとすると
その値を格納する変数はスタック領域に確保されます
そのメモリ割り当て解放コストは他のローカル変数とまとめてスタックポインタを加算減算するだけでコストは最小
これら自動ですので手動ではありません

ではその構造体オブジェクトを作る関数が先ほどの変数>>21へ値を返す時はどうなるでしょうか？
その値が小さければレジスタで返されます
その値が大きければ自動的に先ほどのスタック上の変数のアドレスが関数へ渡されてダイレクトに返す先の変数に値が書き込まれます
このようにオブジェクトの値のやりとりコストも最小
そしてこのオブジェクト作成関数ではオブジェクトのメモリの確保が不要
これらも自動ですので手動はありません

最後に変数>>21に格納された構造体オブジェクトの値を用いる他の関数を呼び出す時はどうなるでしょうか？
不変参照(書き換え不可)か可変参照(書き換え可能)を関数へ渡します
先ほどのスタック上の変数のアドレスがレジスタに格納されて関数へ渡されるだけでコスト最小です

以上ここまでメモリの割り当てと解放のコストは最初のオブジェクト格納変数のためのスタックポインタの加算減算しか生じていないです
だから速いのです

>>9 >>13-14
流石にGCがいくら高速になってもメモリの確保・解放にプラスして管理コストが乗っかる以上、メモリの確保・解放のみより軽くなることは理論上あり得ないことくらいはわかっておくべき

>>21-23
複数の点で間違っている
まず、ランタイムが管理するのではなくソースコードで利用されている場所や解放のタイミングを定めることを「手動管理」と呼ぶのであり、Rustは手動管理を行う言語である
また、メモリ割り当てコストはスタックポインタの加算のみではなく、OSによる処理が介在するしこちらの方がはるかに重い、しかもGCの話と何の関連性もない
メモリがどこから参照されていてどの時点で利用されなくなったか、管理する処理を全てランタイムが実行時に行うのがGCである
参照カウンタによる管理（ARC, ORC）のような中間の機能を備えた言語も存在するが、いずれにせよGCは管理コストが重いことは確かである

>>24
バカ乙
メモリがリンゴだとする
リンゴを収穫する時に1個ちぎって1個ずつ運ぶより何個もちぎって箱に入れてまとめて運んだ方が速いだろ、箱を管理するコストが増えるが運ぶコストが減るから結果的に速くなるわけ

>>25
あなたの理解が不足している
それらに書かれていることを別の表現にすると
『Rustはスタック上にオブジェクトなどの値を置いたまま他の関数でも安全に扱える』
メモリの確保と解放はスタックポインタの増減のみなので最も高速で正しい
そしてその関数を抜けると自動的に解放されるから「自動管理」で正しい
一方でベクターなど複数個の大きな領域を必要とする場合はもちろん自動的にヒープ領域にまとめて確保されてまとめて解放される
Rustはそこでも手動解放は必要なくて基本はそのベクターを宣言した関数を抜けると自動的に解放されるから「自動管理」で正しい
関数の返り値として返せば解放されずに上位の関数に移るが返り値として返すことはGC言語でも同じく行なう自然な行為なのでそれが手動管理と呼ばれることはない

>>26
GCはまとめてメモリを消し飛ばす機能ではなくて、一つずつ使用状況を確認して使ってないものを解放する機能なので君の理解が100%間違ってるだけだね

>>27
それはRAIIが何かわかっていないから起こる勘違いだね
単にC言語では free() と書けばメモリが解放されるのと同じく、Rustでは何もせずにスコープの末端まで来ればメモリが解放されるだけ
スコープの末端に必ず free() が挿入されるだけなので、これを自動管理と言うならこの世に手動管理は存在しない
そうなると、手動管理が存在しないのに、自動管理という言葉を使う君がおかしなことを言っていることになる
これは矛盾だね
私が言っているのはそれとは違って、ソースコードであらかじめメモリを解放する位置を明示し、また参照・借用や所有権、ライフタイムといったメモリ管理について常にプログラマが制御する必要がある方式のことを「手動管理」と言っている
GCにはこのようなことはなく、メモリは全てランタイムが実行時に管理するため、ソースコード上に解放される位置は書かれていないし、プログラマもメモリ管理を意識することはない

下手糞のMTはATより遅い

>>29
それはRAIIの理解不足
RAIIはブロックなどのローカルスコープで宣言したものはそのスコープを抜ける時にも存在していれば自動的にそのリソースが解放される自動管理の仕組み
ただしそこへの参照が残っていれば自動解放されるとダングリンク参照になってしまい危険
Rustはコンパイラが参照連鎖も静的にチェックするため必ずそれを防いでくれるため実用的な自動管理になった

一方でそれらの機構のないGC言語ではローカルスコープを抜けても自動的にそのリソースを解放していいのかわからない
そこへの参照が残っているのか実行前に静的にコンパイル時点で判断できないためだ
だから定期的に参照連鎖を実行時に動的にチェックするガベージコレクション(GC)が必要になる
そして実行時に参照連鎖を追えるようにするためのコストの高いメモリ管理をせざるを得ない
それゆえGC言語は実行が遅くなるだけでなくGC発動まで無駄にメモリを占有してしまう

>>31
やっぱり自動管理の意味がわかってないじゃん
コンピュータが最終的な処理をやるから自動だと言ってるなら手動管理なんか存在しないからお前の言ってることはおかしいし、そうじゃないなら自動管理だから自動管理なんだ！って言ってるだけでただ自分の決めつけを押し付けたいだけ
GCがリソースの解放を静的に判断できないという点だけは正しいが、だからランタイムが自動解放するという点を理解してないので後半の説明も片手落ち

>>30
MTとATの話はしていない
ATのどこに監視用のランタイムがあって、メインの処理を停止してゆっくり呑気にチェックを始める設計があるのか

>>32
関数やブロックを抜けると自動解放されるRAIIは自動管理そのもの
自動解放タイミングも明瞭かつ直ちに行われて分かりやすく省メモリ
GCも自動解放だがタイミングが不明瞭で遅延が大きく分かりにくくメモリ使用量肥大

>>34
それを自動管理と言うなら「free()があれば自動解放されるC言語は自動管理そのもの」ということになる

>>35
free()はプログラマの意思で解放位置を決めてそこに置くから手動管理だな
RAIIやGCはプログラマの意思と関係なく解放されるから自動管理だな

>>36
ああ、RAIIに触れたことがないのはわかったよ
RAIIはプログラマの意思で設定するもんだ

ついでに言えば、所有権システムもプログラマが自らの意思で矛盾なく設計しなければ成立しない

RAIIはプログラマの意思と関係なく自動的に行われる
スコープを抜ける時にプログラマの意思と関係なく自動的にデストラクタが呼ばれる

同じ自動管理でも発動時期が読めないGCより即座に実行されるRAIIが優れているね

自動管理の言葉の定義で争う無能達

>>39
そのデストラクタをスコープを抜けた際に動くように設定するからRAIIなんだぞ
プログラマの意思で呼んでいるのだということに注意がいる

>>40
RAIIが必ずしも優れているとは言えないし、それは手動で管理しなければならないから

>>41
根本的に理解が足りてないんだろうね

RAIIで自動的にメモリが解放されるRustは両者どちらの定義でも自動管理になるよ

>>43
一番の無能が話しかけないでくれるかな？

>>42
RAIIは直後に自動
GCは時期不明の自動

>>44
ならない
どちらの定義でもと言いながら見てないのがよくわかる

>>45
一番の無能はお前定期
悪口は言えても自説も主張できなければ反論もできない

>>46
RAIIとARCの区別がついていないんじゃないか？

>>29 >>31 これはt5kHx157の勝ちだわ
31は「RAIIの理解不足」とか言っときながらt5kHx157の主張を1つも否定できてないし、IDをコロコロ変えてごまかしてる

めっちゃ話は単純
RAIIやGCのようにプログラマーの意思と無関係に必ず自動的に実行されると自動管理
free()のようにプログラマの意思で行なうと手動管理

>>50
RAIIはプログラマーが指定して用いるけど、それはプログラマーの意思と無関係に必ず自動的に実行されると言えると？
deferなんかも自動管理と認識してる人？

少なくともRustのRAIIにプログラマーの指定箇所はないね
完全自動になってる

>>52
RustのRAIIも所有権やライフタイムを明示的に扱わないと機能しないね

>>53
RustでもRAIIはそれらと一切無関係に動作しますよ

>>54
そうなんだ！すごいね！ｗ
ホントにそう思うなら一回Rust書いてみろよｗｗ

やったことないから無関係だと信じてられるんだよｗ
流石に笑っちまうわｗｗ

C→C++になってRAIIが導入されて更に手動でunique_ptrを指定すれぱ自動解放できるようになった
ただし参照が残っていればそれは解放後にダングリング参照になってしまう危険なリスクはそのまま

C++→RustになってRAIIにより常に自動解放されるようになった
参照が残らないことも保証されるため安全に自動解放されるようになった

>>57
Rustはあくまでコンパイラがコードに問題がないことを保証することと、RAIIを標準にすることをやっているだけで、メモリの管理は相変わらずプログラマがやらなくてはいけないことに変わりはないので

>>58
RAIIで自動解放してくれるから楽だよ
しかも速くて省メモリ

>>59
話が逸れてる

RAIIが自動管理は草
RAIIなんかプログラマがシコシコメモリ管理するのを何とかデストラクタ使って頑張ってるだけのこと

RAIIを自動管理だと思ってる奴、deferも自動管理だと思ってそう
メモリ管理ちゃんと意識したことないんだろうな

プログラマーが明示的に指定しなければいけないと手動管理
プログラマが指定する必要がないと自動管理

deferは手動管理
C++のRAIIは手動管理
RustのRAIIは自動管理

>>63
少なくともRustは書いたことないってことはわかった
プログラマが明示的にメモリの管理をしないとRustは正常にコンパイルもできないよ

日常RustメインだがRustは自動解放だから楽勝
管理なんてなくて普通の言語と同じ
関数に引き数として渡すか永続変数に入れておくかの二択しかない

>>65
線形リスト作ってみいや

>>65
ゴミのようなコードが見える見える

線形リストが使われなくなった理由は他のデータ構造を用いる方が速いとはっきりしたから
辿ること自体が遅いのに加えてメモリキャッシュを活かせないことが敗因
売りポイントの挿入削除もその地点を探すのにO(n)かかって不利でその地点が既知なら他のデータ構造が速い

唯一生き残っている線形リストの使われ方はマルチスレッドにおけるキュー管理で唯一ロックフリーにすることができる
複雑に改良が積み重ねられてきた歴史があるためライブラリの助けを借りるのが良い
というわけで専門家以外が線形リストをプログラミングすることはなくなった

ブロックチェーンという双方向リストで息をふきかえした
線形リストはデータ構造へと昇華したのだ

ブロックチェーンで線形リストは使われない
巨大なチェーンを一つずつ辿っていたら遅すぎて実用にならないためハッシュマップが使われている

>>67
それ以外の方法があるなら具体的に述べなさい

>>71
他の言語と同じ管理しかしてないならムーブも可変参照も使えないんだが、そこがわかっていないのだろうか

>>68
線形リストが使われる場所はあるよ、単にデスクトップやモバイルなどスペックが有り余ってるコンピュータでそんなカツカツの管理は必要ないだけで

>>72
Rustに詳しくない様だから教えてあげるね
Rustはムーブが基本なのよ
例えばaからbへの代入文 b = a があった時
言語によってはディープコピーするもの
シャローコピーするもの
特に一番浅い参照コピーするもの
それらが状況や型によって変わるもの
など多種多様なのはご存知よね
Rustはそれが基本動作としてムーブになるというだけよ
そして数値などプリミティブな型はコピー属性を持っていてムーブの文脈で代わりにコピーになるのよ
これらの基本動作は自然に行われるから安心してね

>>72
可変参照と不変参照の区別がある言語は増えているけど管理とはなんの話だろう

>>73
わかってないのはお前なｗ
Rustはメモリ管理しないと参照が使えない設計になってるって話をしてるんだわ
君の見てるところの3段階くらい上にいるから早くおいでｗ

>>73
Rust書いたことないのはわかった

>>75の
下の>>73は>>74のミス

>>74
そもそも不変参照と可変参照の差ならC++の時代からあるわ
何を言っとるんだこのアホは

>>75
嘘はよくない

Rustは非常にシンプルにできている
関数で作ったものは値を返せる
関数で引数としてもらった参照は参照を返せる
という当たり前のルールしかない

別に当たり前ではないたろ
線型論理は別に唯一の論理ではない