次世代言語28 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/08/29(月) 11:22:16.48

スレタイ以外の言語もok

前スレ
次世代言語27 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1659655598/

**デフォルトの名無しさん** · 2022/09/16(金) 20:08:18.02

>>843 教えてください。検索すると30年位前の論文なんかも出てきて実現しているのかどうか、
それが>>830で言っているGCと一致しているのか、ちょっと理解が追いつきません....

**デフォルトの名無しさん** · 2022/09/16(金) 20:23:30.89

GCの研究が進んでよりよいものができるようになったとき
GC言語はそれをまんまと拝借できるから旨味あるよな

**デフォルトの名無しさん** · 2022/09/16(金) 20:34:49.53

>>848 そうなんです。
ただ >>843の「incremental copy garbage collector」が30年以上まえから未だに研究されているのは検索すればすぐにわかるのですが、
nimで選べるくらいの実用段階なのか、更には>>830で言っているものと一致しているのか、重要ですよね。
30年以上の研究なんて逆に絵に描いた餅に思えたりするので。

**デフォルトの名無しさん** · 2022/09/16(金) 20:51:30.89

GC活用するだけじゃなくて、スタックフレームからエスケープしにくくする仕組みがあると面白いと思うけどね。

Rustほどガチガチだとだるいから、エスケープをコントロールするスマポみたいなクラスを用意するとか。

**デフォルトの名無しさん** · 2022/09/16(金) 21:07:42.67

GC以外だと、JVMや. NetなんかのVMも結構に改善してるんじゃない？

**デフォルトの名無しさん** · 2022/09/16(金) 21:21:31.00

GCもVMもどんどん改善してくれたまへ
JavaでHotSpotだのJITだの言い出したころワクワク感あったな
プログラマはプラットフォームに対してでなくて
これからはGCやVMに対してプログラミングをするだけでよくて
さらにGCやVMは誰かのおかげで勝手に改善されていくらしいという

**デフォルトの名無しさん** · 2022/09/16(金) 21:27:14.70

http://www.kmonos.net/alang/d/garbage.html

ガベージコレクトされたプログラムの方が高速です。これは直感に反するかもしれませんが、その理由は：

明示的なメモリ管理の際によく使われる手法は、参照カウントです。代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、速度低下の原因になっています。スマートポインタクラスでラップしても、速度的な解決にはなりません。
(またいずれにせよ、循環参照を削除できない参照カウント方式は、一般的な解決策ではありません。)

オブジェクトによって獲得されたリソースの解放には、デストラクタが使用されます。多くのクラスでは、このリソースとは割り当てられたメモリのことです。
GCを使えば、ほとんどのデストラクタが空になり、完全に削除してしまえます。

メモリ管理のためのデストラクタは、オブジェクトがスタックに置かれたときに影響が顕著になります。
例外が発生したときに、全てのスタックフレームでデストラクタが呼び出され、メモリを解放するような仕組みが必要となるのです。もしデストラクタが関係しなければ、例外を処理する特別なスタックフレームを設定する必要がなくなり、コードは高速に実行されます。

メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。大きなプログラムになるほど、キャッシュに入らない部分が増え、ページングが多く発生し、プログラムが遅くなります。

GCは、メモリが残り少なくなってきたときのみ実行されます。メモリに余裕があれば、プログラムは全速力で実行され、メモリ解放に一切時間を取られません。

モダンなGCは、過去の遅いものより遙かに発展しています。世代型のコピーGCには、昔のマーク＆スイープアルゴリズムの非効率さはありません。

モダンなGCはヒープの詰め直しを行います。これによってプログラムが活発に参照するページの数を減らし、キャッシュヒット率を高め、スワップ回数が減ります。

GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、という事態に縁がありません。

**デフォルトの名無しさん** · 2022/09/16(金) 21:34:12.96

>>830
どちらもJVMで実現済みのことに思えるが…。

メモリレイアウトの最適化
→ 世代別GC(長寿命なオブジェクトは頻繁にGCしない領域に移動する)

確定的なメモリはJITで開放
→ エスケープ解析(短命でスタックに乗せても構わないオブジェクトはスタックに乗せる)

**デフォルトの名無しさん** · 2022/09/16(金) 21:36:23.95

deno=Rust
bun=zig

https://res.cloudinary.com/practicaldev/image/fetch/s--HAhtlbw8--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oi6yfxenbfcuhlrkl6j7.png

**デフォルトの名無しさん** · 2022/09/16(金) 21:39:12.85

>>853
近現代の言語だと例外は飛び抜けて重い機能だよな。c++使うときも自分から例外を使うこと無いし。
例外みたいなエラーフローあると便利なことあるんかね？

**デフォルトの名無しさん** · 2022/09/16(金) 21:39:55.16

>>855
それも言語の良し悪しよりもbanがやるべきことをやってないだけだったり、nodeが本質的には不必要なことをやりすぎているだけっぽいと思うんだよな。

**デフォルトの名無しさん** · 2022/09/16(金) 21:44:51.39

>>854 等号の左右、ずいぶん曲解しましたね。

**デフォルトの名無しさん** · 2022/09/16(金) 21:45:22.11

GC言語、メモリを山のように積んでるマシンだと走りきるまでGC走らなかったりするしな。
mallocしてfreeしないアプリみたいなもんで、ケースによってはそりゃ速い。

**デフォルトの名無しさん** · 2022/09/16(金) 21:55:33.67

>>857
そうなんだね

**デフォルトの名無しさん** · 2022/09/16(金) 22:04:21.30

>>857
要約すると、RustはZigに比べて本質的には不必要なことをやりすぎている、という事でOK

**デフォルトの名無しさん** · 2022/09/16(金) 22:10:48.13

Rust「zero overhead abstraction」は嘘でした

**デフォルトの名無しさん** · 2022/09/16(金) 22:15:51.87

>>856
C++使ってないな。C#ユーザー

**デフォルトの名無しさん** · 2022/09/16(金) 22:19:05.45

>>853
この文章10年以上前からあるけど今でも成り立つのだろうか

確かにメモリ解放を遅延させることによって実行命令数がGCの方が少なくなる場合はあると思う
一方でいくつかのmalloc実装がやっているような、直近にfreeされた領域を優先的に再割り当てするようなことは、GCが走らない限り、つまり、メモリを使い切るまではできない
freeされた領域はキャッシュに載っていて高速にアクセスできる可能性が高いので、直近にfreeされた領域を使い回すことはキャッシュヒット率を高める効果がある
GC言語は命令数は少なかったとしても、メモリのアクセスレイテンシの影響をより多く受け、トータルでは遅かったりしないだろうか

この文章の元ネタのベンチマークがあるなら現在のマシンで比較してみたら面白そう

**デフォルトの名無しさん** · 2022/09/16(金) 22:26:31.57

>>861
アプリの実装の善し悪しの話と実装言語の善し悪しを意図的に混同させるのはよくないよ

**デフォルトの名無しさん** · 2022/09/16(金) 22:34:26.05

>>865 Chrome by C++の場合について聞かせて

**デフォルトの名無しさん** · 2022/09/16(金) 22:44:06.52

>>864
それソースある？
必ず再利用するにあたって領域を書き換えてんだから、直前にfreeしたかどうかに関わらず書き換え直後にキャッシュに乗るのは当たり前じゃないの？
チープな環境でスワップインを回避する効果はあるかもしれんが

**デフォルトの名無しさん** · 2022/09/16(金) 22:47:07.20

>>858
曲解してるかなとは我ながら思った。
けど、GCが勝つというほどインパクトある伸び代が挙げられた項目にこれ以上あると感じないんだよね。

**デフォルトの名無しさん** · 2022/09/16(金) 22:47:38.62

>>876 スワップインて。。>>864はまっとうな意見だと思うよ。

**デフォルトの名無しさん** · 2022/09/16(金) 22:54:48.64

>>868
>GCが勝つという
そんな場合もある、程度では。

GraalVMでNativeにした場合で
Native Java(+GC) vs Native other(no GC)は気になる

**デフォルトの名無しさん** · 2022/09/16(金) 23:06:36.63

escapeするかしないか、静的と動的でそんなに違うもんかね。
むしろエラー以外はescapeする・しないは静的で相当範囲カバー出来てそう。データはないけど。

**デフォルトの名無しさん** · 2022/09/16(金) 23:12:50.46

>>864
これはそう。ただ投機的実行(と昨今のその去勢)とかを考えると結構難しいかなとは。

**デフォルトの名無しさん** · 2022/09/16(金) 23:22:07.28

GCを止めたら速いという話は藁人形論法なのでやめませんか？

**デフォルトの名無しさん** · 2022/09/16(金) 23:25:00.60

どこが藁人形なの？

**デフォルトの名無しさん** · 2022/09/16(金) 23:26:02.22

>>872 vulnerability詳しくないけど、mitigationでfree->mallocがどの程度影響するのか気になるな。

**デフォルトの名無しさん** · 2022/09/16(金) 23:34:42.72

>>853
＞GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、という事態に縁がありません。

嘘言うな

**デフォルトの名無しさん** · 2022/09/16(金) 23:42:23.80

GCは解放の実タイミングは調整するけど「メモリリーク」とは見なしてないのでは。

むしろ Rust「メモリリークはメモリ安全性保障の範囲外」の方なんとかして

**デフォルトの名無しさん** · 2022/09/16(金) 23:44:19.41

>>867
GCはそもそもfreeから再利用まで間が開くのでその間にキャッシュから外れる可能性が高くなるし、
再利用に当たって領域を書き換えるなら、キャッシュに載ってない場合書き換え処理に時間がかかるのでは
スワップインはよくわからない

**デフォルトの名無しさん** · 2022/09/16(金) 23:45:28.20

>>877
メモリリークを静的に検知するのはプログラムに対する制限が相当大きくなってしまうのでは

**デフォルトの名無しさん** · 2022/09/16(金) 23:53:17.42

>>879 動的にでも検知する仕組み/試みがあったりするのかな。テスト、プロファイル、そりゃあるかな。

**デフォルトの名無しさん** · 2022/09/17(土) 00:04:48.75

>>880
valgrindとかAddressSanitizerとかmallocをhookするやつとかいろいろあるよ

**デフォルトの名無しさん** · 2022/09/17(土) 00:05:17.29

GCはいわばメモリ管理の専門家に幅広い裁量を持たせて仕事させているわけで、
それに比べるとアプリケーションコード内でのメモリ管理はCenter of Excellence的な意味では原理的にどうしても不利よね
メモリ管理の専門家が十分な裁量を持って仕事できるのはせいぜいアロケータの実装くらいで、ほかは高水準のプログラミングモデルやプログラマの能力の制約を強く受けることになる

**デフォルトの名無しさん** · 2022/09/17(土) 00:13:57.81

Javaは実行時最適化によりRustの3倍速い。

**デフォルトの名無しさん** · 2022/09/17(土) 00:21:14.46

>>883
(場合もある)

**デフォルトの名無しさん** · 2022/09/17(土) 00:44:08.92

スパイクの出ないGC出たら即乗り換える予定

**デフォルトの名無しさん** · 2022/09/17(土) 01:02:29.41

それ以来30年間GC技術が進んだ結果の現状が既出のこれ

>>200
>> https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg

全く対等に同条件で多くの人々が同じ問題に対して様々な言語で記述した結果の各実行時間
速く実行できた言語はRustとCとC++の3つでいずれもGCなし
GCする言語は軒並み遅い
一部をGC対象とならないよう回避の努力をしているGoがGC言語の中で最も速い
そうでない普通のGC言語は遅すぎる

**デフォルトの名無しさん** · 2022/09/17(土) 01:35:11.26

>>886
これってGC性能が支配的になる問題なの？

**デフォルトの名無しさん** · 2022/09/17(土) 01:41:35.46

pythonさん

**デフォルトの名無しさん** · 2022/09/17(土) 01:47:29.96

>>887
(1) GCが発生している場合
　　→ GC性能が改善された現在でもGC言語は遅い

(2) GCが発生していない場合
　　→ GC性能と関係なくGCが起きない段階でもGC言語は遅い

どちらのケースであってもGC言語はダメな存在になってしまいますね

**デフォルトの名無しさん** · 2022/09/17(土) 01:50:03.67

あれ、D言語はかなり早いイメージだったけど、Goに負けることもあるのか

**デフォルトの名無しさん** · 2022/09/17(土) 01:52:02.97

>>884
無いよ（笑

**デフォルトの名無しさん** · 2022/09/17(土) 01:53:36.44

LDCじゃなくてGDC使ってんのかな

**デフォルトの名無しさん** · 2022/09/17(土) 01:57:29.45

Goは速いよ。

アンチGCはGC言語じゃなければ速い、と思い込みすぎでは？

ミッション車みたいなもんで、自分の設計力の無さがパフォーマンス劣化に直結するというか、いわゆるベンチのスペックは素直には出ないよ。
Rustアンチじゃないけど、これはRustの目的でもない(あくまで安全が目的)

GC言語みたいにだれでも80点が取れます、エンストしませんよ、みたいなもんじゃないんよ。

コンパイラが叱ってくれるからハイパフォーマンスとか、書いてて言ってんのかほんとに謎。

**デフォルトの名無しさん** · 2022/09/17(土) 01:58:13.17

ゲハでやれ

**デフォルトの名無しさん** · 2022/09/17(土) 01:59:07.17

>>886
そいつの読み方は「C＋＋とPyPy3圧倒的じゃないか」ですよ。
新参者から熟練者まで数と質すべてが圧倒的。
C++は熟練すると、黒魔術を含め、やりたいことが全てできる言語なので、突き詰めていく性質の企業におすすめ。
逆に、手数で勝負の乱打スタイル企業には、PythonやRoRがお勧め。

**デフォルトの名無しさん** · 2022/09/17(土) 02:01:08.18

>>893
Javaも速いですよ。
Rustの3倍は冗談だけど。
欠点はメモリーを使いすぎること。
一般的なパソコンはメモリーが少し足りない。
だから、Javaは遅いと思われてる。
ミスマッチです。

**デフォルトの名無しさん** · 2022/09/17(土) 02:04:15.85

ハードウェアを売りたい言語だから、ハードウェアに対する要求が少し厳しかったですね。

**デフォルトの名無しさん** · 2022/09/17(土) 02:25:11.61

>>886
やはりGCの言語はいずれも遅いな
GCのせいで遅くなるのではなく
ヒープでメモリ確保するからGCの言語は遅くなる

**デフォルトの名無しさん** · 2022/09/17(土) 03:31:52.64

>>896
Java速いよね。あんまり適切なXmx知られてないだけだと思う。

>>898
少なくとも知ってる範囲だとGoもc#も取れるときはスタックを確保するぞ。

**デフォルトの名無しさん** · 2022/09/17(土) 03:42:09.24

>>899
Javaは遅いです
どのベンチマークでもC/C++/Rustの2倍～数倍はJavaが遅いです
>>886の例でもJavaは数倍遅くなっています

**デフォルトの名無しさん** · 2022/09/17(土) 03:53:04.00

>>900
abc 182-eはakariって問題なんだけど、読んだ？
Javaで雑に書くとパフォーマンスでない類の問題だよ。

このグラフは言語オタ勢には有名かと思ってたけど、ベンチマークのグラフではなくて、あくまで競技者が書いた言語毎の統計のグラフなので、ポンコツが多ければそれが表現される。
言語人口が多いものの箱ひげが偉いことになってるでしょ。

**デフォルトの名無しさん** · 2022/09/17(土) 04:54:39.17

>>901
なるほど
しかしJavaで書いて最も速くできた人でも遅くて
Rustで書いた平均的な人たちにすら負けているな>>886
どんなに優れた人であってもJavaを使った時点で遅いと確定してしまうのは辛いな

**デフォルトの名無しさん** · 2022/09/17(土) 07:28:28.63

>>877
これ訳わからんよね。
そこまでして「GC不要でメモリ安全」を売りにしたかったのか、と思うわ。
c++とかだとメモリリークも普通にバグ扱いされるのに、それを「メモリ安全」と言い切るのは詐欺臭い。

**デフォルトの名無しさん** · 2022/09/17(土) 07:39:14.89

>>902
そもそもRust使える人間は他の言語に詳しい人間しか居ないだろ。

他の言語に詳しく無い人間がRustの絶壁の学習曲線をクリアできるとは思えん。
「Rustしか使えません」なんて人間は存在するのかね？

**デフォルトの名無しさん** · 2022/09/17(土) 07:46:13.48

>>903
それは常識
一般的に循環参照の安全な解放を静的に記述したり静的にチェックすることは不可能
デッドロックも同じで静的に発生をチェックして防止することは不可能
だからコンパイラ(＝静的にチェックする存在)がそれらを防ぐことは対象外となる

**デフォルトの名無しさん** · 2022/09/17(土) 07:50:22.53

>>904
バカは遅い言語や危険な言語を使い続ければよい
時代の要請は高速で安全でプログラミング効率の良い言語でありそれはRust
使えないバカがついていけずに切り捨てられていくことは業界にとっても朗報だ

**デフォルトの名無しさん** · 2022/09/17(土) 08:47:42.31

早い言語は適当に書いても2秒の時間制限に間に合うけど
遅い言語は問題の想定解法じゃないと通らないから結果的に早い言語は上髭多くなるだけ

**デフォルトの名無しさん** · 2022/09/17(土) 09:18:54.40

>>902
execution timeの単位はミリ秒だぞ
ベンチヲタは気にするが1000000回ループして1秒か2秒しか差がつかないのに現実的に問題になることってないぞw
現実のループは多くてもせいぜい1000回程度だろ

**デフォルトの名無しさん** · 2022/09/17(土) 09:57:15.90

>>908
あんたには遅くてダメな言語で十分なのだから他を気にせず不満を持たずそのままでいいじゃないか
あんたには無縁だが世の中には速くて安全で保守性も良い言語が求められているだけの話だ

**デフォルトの名無しさん** · 2022/09/17(土) 10:21:27.92

Rustの他の言語と比べた速度向上って、俺にじゃなく世のほとんどのプロジェクトにとって五十歩百歩の微々たるものなんですわw

**デフォルトの名無しさん** · 2022/09/17(土) 10:29:26.87

前に、rustでtsc実装した人、さらにgoで作り直すって、理由がrustには向いてないからって。翻訳記事だからニュアンス違うのかもしれないけれど。

**デフォルトの名無しさん** · 2022/09/17(土) 10:29:40.60

>>905
プログラマサイドにそんな「常識」は無い。プログラマ視点なら「メモリリークはバグ。メモリを圧迫してトラブルになる危険がある」の方が常識。Rust関係者はそういうことを説明の奥の方に隠して「メモリ安全」とか誇大広告するから詐欺だと指摘しているわけで。

常識とかけ離れた俺俺定義を使うならちゃんと注意書きしろよ。
「メモリ安全*」
*メモリリークを除きます。
みたいに。

**デフォルトの名無しさん** · 2022/09/17(土) 10:35:04.81

Amazonの>>9の記事にもあるけど
Rustへ書き換えるだけだけでリソースコストや電気代それに伴うCo2排出量などが少なくとも50%は削減できる
さらにセキュリティの要請から安全性も求められている
土方でないまもともなプログラマーならばJavaでもRustでも他の言語でもプログラミングに支障なく書ける
それらの状況から選ぶべき言語がRust一択になっているだけでしょう

**デフォルトの名無しさん** · 2022/09/17(土) 10:39:04.61

https://stackoverflow.com/questions/55553048/is-it-possible-to-cause-a-memory-leak-in-rust
> Is it possible to cause a memory leak in Rust?
> You can also leak memory if you create a cycle of shared references:
> You can also use Box::leak to create a static reference, or Box::into_raw in an FFI situation.
> You might've forgotten about Box::leak and Box::into_raw which are pretty common in ffi situations for passing around states.

https://doc.rust-lang.org/book/ch15-06-reference-cycles.html#reference-cycles-can-leak-memory
> Reference Cycles Can Leak Memory

**デフォルトの名無しさん** · 2022/09/17(土) 10:46:39.42

RustでなくVBAを使うことでエネルギー削減になることもあるな

**デフォルトの名無しさん** · 2022/09/17(土) 10:55:22.36

>>913
Rustを学習した人間の感想の多くが「Rustは難解」と言っているのに、「まともなプログラマなら支障なく書ける」とする根拠は？
根拠が個人の感想なら、「まともなドライバーならマニュアル車を支障なく運転できる」と言うくらい傲慢だと思うがね。

**デフォルトの名無しさん** · 2022/09/17(土) 10:55:41.70

>>912
それはちょっと知識不足じゃないかしら
もし循環参照を作っちゃった場合はそれを安全に解放する局所的な方法は理論的に存在しないんですよ
GCでも局所的に解決できる参照カウント方式では循環参照を解放できないため
GCの中でも全体のマークスイープ方式や全体の使用中分コピー方式でようやく解放されます
そららは非常にコストが重いだけでなく発動までに時差もあります

したがってプログラミング言語界ではそんなコストがかかるものに依存するのではなく
最初から循環参照を作らない方向で進んでいます
そのため最近は多くの言語で弱参照がサポートされており循環参照の発生を防ぐことができます

今回の話のJavaでももちろん弱参照が用意されていて最初から循環参照を作らないようにプログラミングします
そのほうが有利だからです

**デフォルトの名無しさん** · 2022/09/17(土) 11:04:35.77

>>917
C#では参照はツリーで管理されるから循環参照も問題なく一瞬で開放される

**デフォルトの名無しさん** · 2022/09/17(土) 11:12:08.51

>>917
Wikipediaですら「メモリ安全性」の解説でメモリリークをメモリエラーとしているのに、実装側の都合で一般に使われている用語の意味をひん曲げて「常識」とな？

そういうのが詐欺だと指摘しているだけだけどなぁ。

今度からちゃんと
「メモリ安全*」
*メモリリークを除きます。
と注釈付けろよ。

**デフォルトの名無しさん** · 2022/09/17(土) 11:17:11.83

>>918
それはC#でもJavaでもRustでも他の言語でも全て同じ方法です
どの言語も弱参照を併用して参照はツリー状のみにすることで循環参照の発生を防ぎます
もちろんそこには弱参照による弱い循環参照がありますが通常の参照はツリー状なので
おっしゃる通りに一瞬で解放することが可能です

**デフォルトの名無しさん** · 2022/09/17(土) 11:20:08.51

>>919
wikipediaのメモリ安全性のメモリリークで挙げられてる項目は循環参照によるリークは含まれてないっぽいが
https://ja.m.wikipedia.org/wiki/%E3%83%A1%E3%83%A2%E3%83%AA%E5%AE%89%E5%85%A8%E6%80%A7

**デフォルトの名無しさん** · 2022/09/17(土) 11:32:35.56

ところで所有権は複製されるってことでいいの？

**デフォルトの名無しさん** · 2022/09/17(土) 11:33:28.06

>>921
リンク先にある「メモリリーク」の項ぐらい読めよ。

**デフォルトの名無しさん** · 2022/09/17(土) 11:34:17.29

今時循環参照くらいでメモリリークするような言語でよく安全を名乗れたもんだ
退化してるやん

**デフォルトの名無しさん** · 2022/09/17(土) 11:39:26.07

昔は保守的GCというGCに人気があった
本当はゴミなのにゴミではないと判断することはバグではなく安全、という注釈つきのGCだった

この注釈は嘘だったという見方の方が今は優勢

**デフォルトの名無しさん** · 2022/09/17(土) 11:42:22.70

予想される次の手：
・循環参照の矮小化
　循環参照なんてめったに起こらないし
　普通に書いてたら発生しようがない
・問題の転嫁
　循環参照なんて書くほうが悪い
　循環参照によるメモリリークなんかを問題視するほうが悪い
・飛躍した結論
　とにかくRustは素晴らしい

**デフォルトの名無しさん** · 2022/09/17(土) 11:43:45.86

>>902
「この設問は」ね。だから競プロは複数言語できると面白い。

**デフォルトの名無しさん** · 2022/09/17(土) 11:45:32.10

今は強い循環参照を作ってしまったら負けの世界
Pythonですら強い循環参照を避けるために弱参照が用意されていて回避できる
もちろんC#やJavaにKotlinやSwiftにも弱参照が当然あって回避できる
Rustなどのように強い循環参照が自然には発生しない言語仕様だと更に良い

**デフォルトの名無しさん** · 2022/09/17(土) 11:46:24.15

メモリ安全とは何なのがまとまってるページとかは作れないんだろうか

**デフォルトの名無しさん** · 2022/09/17(土) 11:48:55.60

>>925
Bohemとかもそうだっけ？

循環参照に関しては、確かにメモリリークだけど、危険ではないんでは？
Dangling pointerにならんかったら良いんじゃ無いかなあ。

循環参照で放置されているものの解放に時間がかかっても、別に問題ないと思うんだけどな。メモリに極端な制約がある環境下でなければ。

最初から循環参照を作らないというのは一つなんだけど、そういうわけにもいかんのよ。
最近書いたけど、グラフなオブジェクトなんかは循環参照するじゃん。

**デフォルトの名無しさん** · 2022/09/17(土) 11:49:36.37

>>929
Rustの話ならこれかな？
https://doc.rust-jp.rs/rust-nomicon-ja/meet-safe-and-unsafe.html

**デフォルトの名無しさん** · 2022/09/17(土) 11:57:30.35

ようやくわかってきたよ
C 言語に大量にある未定義な挙動がないことをsafeって言ってんのか
ならメモリリークっていう現象事態はたしかにsafeだ

**デフォルトの名無しさん** · 2022/09/17(土) 12:01:39.81

>>923
単にメモリリークと言ったら含まれるけど、
メモリ安全性に関わるメモリリークの文脈では循環参照は言及されてなさそうなんだよね
メモリ安全性という言葉の定義だけの問題で、実用上問題になるという点ではよろしくないとは思うけど

**デフォルトの名無しさん** · 2022/09/17(土) 12:02:36.48

循環参照はコールバック等で普通に発生する
トレーシングGCでは全く何の問題にもならないから弱参照なんか使わんよ

**デフォルトの名無しさん** · 2022/09/17(土) 12:05:32.37

ttps://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html
循環参照は、メモリをリークすることもある

ここか
なるほど

**デフォルトの名無しさん** · 2022/09/17(土) 12:06:42.34

>>928
強い弱いの意味がわかってなくて草

**デフォルトの名無しさん** · 2022/09/17(土) 12:07:05.26

>>931
今まである「メモリ安全性」の常識を無視して『メモリ安全性』という言葉を使わなきゃいいんだけどねぇ。
「プログラムの安全性にこだわった」くらいの宣伝ならまだわかる。

Rustはわざわざ「メモリ安全性」という言葉を使って宣伝しているんだからダメだろ。

**デフォルトの名無しさん** · 2022/09/17(土) 12:24:51.56

確定的なタイミングでトレーシングGCしてくれるようなスマートポインタって実現不可能なの？

**デフォルトの名無しさん** · 2022/09/17(土) 12:27:39.54

勘違いしてる人がいるようなので正しい知識をまとめておきます

C++やRustのような非GC言語やリファレンスカウント方式のGC言語では(強い)循環参照の解放は原理的に不可能です
これらの言語ではデッドロック等と同様に(強い)循環参照は発生させてはいけない禁忌として扱われ発生自体を避けます
対処方法としては弱い参照を用いた弱い循環参照を用いるのが主流ですが
プログラムが自分で管理する範囲内で循環参照を作ってまとめて解放したり範囲内GCなどを用いる方式もあります

マーク＆スイープ方式やコピー方式のGC言語ならば(強い)循環参照も解放することができます
ただしそれらの方式は全体空間を全てマークしたり辿ったりコピーしたりとコストが重いことの裏返しでもあります
さらにGCが起こるまで無駄にメモリを専有してしまう問題もあります
そのためこれらの方式のGC言語でも弱参照が用意されて(強い)循環参照を作らないようにすることが一般化しつつあります

**デフォルトの名無しさん** · 2022/09/17(土) 12:35:09.02

>>939
ちなみに誰が勘違いしてんの？

**デフォルトの名無しさん** · 2022/09/17(土) 12:37:10.60

>>940
>>939

**デフォルトの名無しさん** · 2022/09/17(土) 12:39:43.66

>>939
ちょっと本垢でQiitaにでも書いてくれマサカリ投げに行くから

**デフォルトの名無しさん** · 2022/09/17(土) 13:12:35.27

>>937
Rustのメモリ安全性、というのを先に定義しとるからなぁ。
そこはまぁ定義次第なのはその通りだと思う。

**デフォルトの名無しさん** · 2022/09/17(土) 13:18:40.25

>>938
無理だよ
だから各言語は現実的な対応をとってる
例えばC++のshared_ptrでも循環参照を起こしたらメモリ解放できない
回避策は強い循環参照を作らないようにweak_ptrを使う
Rustでは意図的に頑張らない限り循環参照が勝手に作られることはないけど
同様に参照をWeakにできるからメモリ解放可能な弱参照を用いた循環参照にして扱う
これはARC方式のSwiftでも同様で循環参照を起こしたらメモリ解放できない
Swiftでもweak宣言で弱参照にできるので解放できない循環参照を避けられる
いずれの言語もほぼ同じ仕組み

**デフォルトの名無しさん** · 2022/09/17(土) 13:55:15.51

>>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
よくわからないので聞くけど、
Rustでは意図的に頑張れば、Weakにせずに循環参照データ構造を定義してzeroじゃない実データ構築をするコードがコンパイル通るの？

**デフォルトの名無しさん** · 2022/09/17(土) 13:59:18.77

>>943
ならトップページに「Rustにおけるメモリ安全性」として「*メモリリークは除く」くらいはやらないと優良誤認だろ。