次世代言語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/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におけるメモリ安全性」として「*メモリリークは除く」くらいはやらないと優良誤認だろ。

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

>>945
https://doc.rust-jp.rs/book-ja/ch15-06-reference-cycles.html

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

>>947 ありがとう

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

>>945

https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=0d4932743de9a2d3f91b215fe3a4757b

>最後のprintln!のコメントを外してプログラムを実行したら、aがbを指して、bがaを指してと、スタックがオーバーフローするまでコンパイラはこの循環を出力しようとするでしょう。

確かに
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
timeout: the monitored command dumped core

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

>>937
循環参照によるリークを含むようにメモリ安全性を定義してる文献ってある？

Wikipediaの定義ではメモリリークという分類はあるけど、
"メモリ使用量が追跡されていない又は誤って追跡されている場合"
と説明されていて、前者は当てはまらないし、後者はダングリングポインタなどを意図しているようで、循環参照は含まないように読める

SwiftやChromeやAOSPやDのメモリ安全性に関するドキュメントでもメモリリークについては触れられていないようだった

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

>>949
[BUILD]にしてみたが「循環しるよ」的なwarningはないのね

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

>>951
>>944 >Rustでは意図的に頑張らない限り循環参照が勝手に作られることはない
warningがないし、当該データの使い方次第で実行時エラーにもならないので
意図しなくても、「偶発的に」循環参照が作られることはありそうだ。

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

潜伏した循環参照が後々深刻な事態になるかどうかは別の話だが
Rustだからと言って、コンパイル通ったからと言って、油断は禁物で

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

「常識」でしょw

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

>>937
> 今まである「メモリ安全性」の常識
お前の脳内の話じゃないなら具体的にどういう事なのか示してみそ

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

すげーくだらないことで盛り上がってんなw
さすが次世代w言語wwスレwww

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

メモリリークだけでは安全性には差し障らんでしょ。一般的に。
スタック、ヒープが枯渇することはメモリ安全性に差し障るけど。

リークしてるけど走りきった、とか、GCがまとめて解放した、はセーフだと思うよ。

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

>>950
そんなことよりもまず
「メモリ安全性は(プログラムによる)メモリエラーを許容するのか、しないのか」
はどちらだと思うのか考えてもらいたいね。Rustは「メモリエラーが発生するけどRustはメモリ安全」て言っている。
>>955も同じな。お前もRustみたいに断言するのかね。

まぁ、「c++よりもメモリ安全」というならまだ正確だが、それならそうと正直に言うべきだと思うがね。俺俺メモリ安全をwebページの奥の方に置かないで。

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

>>957
いやメモリリークはDoS攻撃に対する脆弱性になりうるから安全性に差し障るよ

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

>>958
「メモリ安全性」という用語の定義の話に変な造語持ち込んで話題そらすのやめてよ

Rustによるメモリ安全性の定義が俺俺というなら、ちゃんとした定義を示して欲しいな
「常識だから分かるでしょ？」というのは自分の思いの表明にしかならないよ

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

>>958
だからお前の思う「メモリー安全性」の定義を示せよ
まあ示せないからぐだぐだはぐらかすしか無いんだろうけどw

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

>>957
だとするとRustで常駐系のプログラムの開発をするのは安全では無いですな。
常駐系プログラムがメモリを食い潰すのは良くあるバグだけど、Rustだとそれは「仕様」で「メモリ安全の対象外」なんだから。
まぁ、Rcの循環参照だけの話だから、外部のコードを含めてRc使っていないor循環参照していないことを検証できれば安全なんだろうけど、Rustファンが言うような「Rustを使えば安全」というようなことは無い。

>>960
素直にWikipediaの「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態のこと」でいいだろ。
Rust公式はなんて定義しているの？>>931は定義じゃないよな。

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

「定義」や「常識」「一般的に」の話とは別だが、このスレ見てる個人的印象だと、
Rustで宣伝商売したい人たちは、Rustを知らない人(意思決定者)が「メモリ安全性」を「優良誤認」(自己責任)するのを密かに期待してそう
Rustプログラマーはそうじゃないと言い切れるのか

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

>>962
あんさんキチガイやな
それはRustの問題じゃない
>>939の説明が一番わかりやすいが言語全般における問題で原理的に解決できない問題やで

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

https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-programming-scripting-and-markup-languages
頑張ってるじゃないか
Rubyよりは使われてるみたいだな

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

>>925
今はしらんがrubyのgcも保守的gcだったよ。

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

>>934
じゃあなんで弱参照が用意されてるんですかねぇ？

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

>>926の論法分析が的中してる

>>964
>言語全般における問題で原理的に解決できない問題やで

言語全般が「メモリ安全性」を宣伝してるって言ってる？

>原理的に解決できない問題

原理的もなにもRustプログラマーが常に:

>>919
>「メモリ安全*」
>*メモリリークを除きます。
>と注釈付

すれば良い

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

>>962
メモリ安全性に循環参照によるメモリリークの抑止が含まれないことは認めてくれた感じかな？

Rustを使えば絶対安全とか言ってる人の言うことを信じるのは良くないよ
匿名掲示板の変な人の発言じゃなくてちやんとしたドキュメントを読んだ方が良い

Rustはメモリ安全性について独自の定義はしてなくて、Wikipediaに書かれているような意味でのメモリ安全性を保証するよ

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

>>967
グローバルなキャッシュを実装するときなど、参照先のGCを妨げることなく長時間参照を持ち続ける必要がある場合に使用する
基本的にトレーシングGCで弱参照が必要になるのは極めてレアケース

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

>>964
新しい藁人形連れてくんなよ。
最初から
Rustの問題は>>903で、本来なら
「メモリ安全*」
*メモリリークを除きます。
とちゃんと注意書きすべき
という主張。原理的に解決できるかどうかとか主張していない。

>>964の言うとおり、原理的に解決できないのに>>963を狙って「メモリ安全」と宣伝しているなら邪悪すぎるな。>>964は「Rust公式は邪悪」と言いたいのかな？

**970** · 2022/09/17(土) 17:57:12.28

なお、トレーシングGCにおいて循環強参照を避けることを目的に弱参照を使用することは全く何の意味もない
トレーシングGCのアルゴリズムを知っていれば循環強参照がGCのパフォーマンスやメモリ効率を悪化させることが無いのは明らかであるし、
弱参照の使用はレアケース故に概してあまり最適化されていないため、パフォーマンスは大抵の処理系においてむしろ悪化する

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

GCあるほうが楽だと思うんだけど、スパイクの無いGCって実現できないの？

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

>965
>Rubyよりは使われてるみたいだな
逆逆 Stackoverflowは精度がイマイチ

jetbrains
Ruby https://i.imgur.com/zqmf96u.png お一人様 7% ほとんどの人が仕事で使っている
Rust https://i.imgur.com/olB9F6L.png お一人様 86% ほとんどの人が個人の趣味

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

>>969
いや？全然。
循環参照によるメモリリークはメモリエラーだろ。メモリ安全「RAMアクセス時に発生するバグやセキュリティホールなどから保護されている状態」じゃない。

それにRustファンの言うことを信じているとか、冗談を言うのはやめてくれよ。気持ち悪いから。

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

>>972
え？
C#では循環参照を避けるためなどの目的で弱参照を使うけど
これは悪化させているとでも言いたいの？

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

>>962
「どの言語でも基本的には、OOMキラーに殺される前にGCが走らせたり、手動でメモリーを解放できること」ができないと安全では無いんじゃないかな。なので環境依存よ。
そう、Rustを使えば安全では無い。

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

>>976
そんな事実はない
嘘だと思うならC#スレで聞いてきなさい

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

今回の件でGC言語がなぜ何倍も遅いのかよく分かった
世代別ガベージコレクションをするため頻繁にコピーGCを行なうことが遅くなる敗因の一つ

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

>>973
昔、ハードウェア側でGCするJVM(?)があったような…。

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

>>973
RustはGC無いけど即座に自動的にメモリ解放されて楽だよ

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

参照カウントって GC じゃないの?

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

四天王で最弱のGC。

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

>>981 それの何が楽だと言っているの?

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

俺の考えたGCが最強だけど、サブマリン特許やる予定だから教えない。

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

はよ次スレ

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

GC言語を使うと大して楽になるわけではないのに劇的に遅くなるからな
無能にはGC言語が向いている

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

>>979
世代間GCのアリナシもそうだし、
>>927と同じく、言語と解決したい課題によるよ。

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

Java製アプリはオメガテーつこてるけど、遅いとか重いとか一切ない。
サクサク快適。
だがしかし、キャレットの位置が異常なのでテキストの選択がやりにくい。
この動作はJava GUIの仕様だが、仕様が間違っていると思う。
Windowsと同じ動作にするべき。

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

>>980 次スレ気づいてない誰か代理俺は無理

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

>>982
プログラマー指定せずとも自動的に参照カウントが使われる言語(PerlとかPythonとかSwiftなど)の場合はGCで合ってるよ
C++のshared_ptrやRustのRcのように特殊な用途のみにプログラマーが明示的に指定して使うものはGCとは呼ばれず単なるデータ管理構造

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

>>981
いつも出てくるこの自動解放されて楽って感覚がわからない。自動解放とか出来て当たり前じゃないの？

GCありと同等のルーズさが許されなら良いけれど、実際はメモリ管理を明確にさせられるよね。

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

>>989
Javaは遅い
少なくともC/C++/Rustなどの2倍～数倍は遅い
Javaは仮想マシンだしGCあるし遅くなるのは仕方ない

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

お子様　→　Python
おんな　→　Ruby
真の男　→　Rust

こう言いたいのでは？
岡くんは。

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

>>993
ってことは、2~3倍遅くても何も問題ないってことだろ。

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

パイソンとかジャッカルには厨二を惹きつける響きがある。
女がなぜRubyを使いたがるのかはよく知らん。
岡くんがRust推しなのは本読んでわかった気になったから。

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

>>992
C並に高速なプログラミング言語では自動メモリ解放は普通は行われない
これは例えば新世代言語であるZigなどでも同じで手動メモリ解放となる
唯一の例外が常に自動的にメモリ解放されるRust

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

次スレはワッチョイ付けるよね。

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

>>997
循環参照除く

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

1000

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 19日 7時間 35分 53秒