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

**デフォルトの名無しさん** · 2021/08/22(日) 08:59:03.31

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2021/11/15(月) 21:05:38.94

近頃の言語でGCのタイミングをプログラムから制御できるのはないの?

**デフォルトの名無しさん** · 2021/11/15(月) 21:07:57.52

スマートポインタはGCではないということにして
誰がどう嬉しいんだろう？

**デフォルトの名無しさん** · 2021/11/15(月) 21:08:32.33

>>684
>>ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する機能である

それだけだとC++(11以降)もSwiftもRustもGC言語ということになってしまいます
だからその定義が不十分なんだと思います

**デフォルトの名無しさん** · 2021/11/15(月) 21:21:58.47

>>687
いや、それはGCの定義なんだから十分だろう
不足してるとするなら「GC言語」の定義
まぁ言語機能にGCが組み込まれてるならGC言語で
ライブラリとして実装されてるだけ（C++やRust）はGC言語ではないって感じだと思うが、正確な定義は知らん

**デフォルトの名無しさん** · 2021/11/15(月) 21:28:35.39

>>685
参照されなくなったポインタをデストラクタに渡したらデストラクタ内で参照される
デストラクタ内でポインタを復活させるようなコードを容認するとGCの性能がどんどん下がる
だからGCの性能を上げたい言語にはデストラクタ機能がないのが合理的

**デフォルトの名無しさん** · 2021/11/15(月) 22:06:51.83

>>685
Golangは、SetGCPercent(-1)でスタートさせてruntime.GC()を手動で呼び出す事は可能らしい。Java系というか
JVMだとSystem.gc()というものがあるが、これは確実にGCを行うわけでもなくて提案なのであまり意味がない。
Java11ではno-op garbage collectorが-XX:+UseEpsilonGCが実装された。いわゆる上のほうで書いてあるような
短期間で直線的な定量のメモリで終わるバッチのようなプログラム用だが・・・
C#というか.NETだとSystem.GC.Collect()とか、GC.TryStartNoGCRegion()でGCを動かさない指定ができる。
SwiftはARCが強制でもないのでGCを自作すれば…できる

**デフォルトの名無しさん** · 2021/11/15(月) 22:07:26.02

>>687
「機能である」と書いてあるだろ。
よく読めよ。どこに「言語である」と書いてあるんだよ。

お前は「機能である」ことに同意しないのか？

**デフォルトの名無しさん** · 2021/11/15(月) 22:14:38.76

自動的ってとこに着目できるかもな
スマポをプログラマが手動で使うのに
自動的に開放とはこれいかに

ガベコレ言語がもたらす本当の自動を知っているプログラマなら
スマポはあくまで手動にすぎない
内部でdeleteをしてるコンテナを使ってるだけにすぎない

**デフォルトの名無しさん** · 2021/11/15(月) 22:17:50.89

>>688
そりゃそうだ。「GC言語」のまともな定義なんて無いからな。整理しようとするレスも無視しているしな。
定義も無いまま同意構築もしないまま、擬似問題をグルグル繰り返しているだけ。
しかも自分のお気に入り言語を擁護するために、何回も何回も何回も繰り返し引っ張り出すから腹立たしい。

**デフォルトの名無しさん** · 2021/11/15(月) 22:27:16.63

>>692
プログラマが「いつ」スマートポインタの参照先のリソースを手動で解放する操作をするのか説明してもらえませんか？

「スマートポインタ」が分かりづらいというなら、c++の「shared_ptr」でいいですよ。

**デフォルトの名無しさん** · 2021/11/15(月) 22:31:47.59

正直定義なんてどうでもいいと思うんだが・・・
伝わればいいと思う

**デフォルトの名無しさん** · 2021/11/15(月) 23:07:31.08

>>682
ARCだけじゃなければ循環参照を回収するサイクルコレクターが動くので、OKというか循環参照全体を参照する
変数が消えれば消える。ARCの強参照は当然ながら連鎖的には消えない。
これがよく言うARCのメモリーリークでSwiftやObjective Cで起こる現象、親の所有者が消えたのだから内部で
参照しあっていても消えると考えてしまう。サークルを作らず直線状なデーターやツリー上のデーターならば
連鎖的に消える。
ただし、サイクルコレクターがある場合でもグローバル変数になっている場合には終了時のすべての変数が寿命を
迎えるだけなのでそこで壮大なメモリー解放が起こる（これを指して意味がなく壮大な無駄だという人もいるが）
そして、SIGTERMを送ってもなかなか終了しないプログラムは一生懸命メモリー解放を行っていたりする

**デフォルトの名無しさん** · 2021/11/16(火) 00:38:45.88

同じように参照カウントを用いていても状況が真逆で決定的に異なる

GC言語
[対象] 全て
[手段] プログラマーは何もしない
[期限] プログラマーは意識していない
[適用] プログラマーから適用機構は見えない
[機能] 解放のみ

C++のshared_ptrやRustのRc
[対象] 所有者が複数となるレアケースのみ対象
[手段] 明示的にshared_ptrやRcをプログラマーが使用
[期限] どうなると解放されるかタイミングをプログラマーが把握
[適用] 解放のためにdelete(デストラクタ)やdropが適用される
[機能] 解放時にデストラクタにて関連プログラミングが可能 (ファイルを自動クローズなど)

したがってC++やRustは手動メモリ管理でありGCの定義「自動的に解放する機能である」を満たしていない
あくまでもC言語と同じく手動メモリ管理の延長(省力化)でありGCではない

【結論】
『C++やRustのスマートポインタはGCではない』

**デフォルトの名無しさん** · 2021/11/16(火) 00:54:53.09

>>697
その定義でwikipediaの説明風にGCの説明書いてみてよ

**ハノン** ◆QZaw55cn4c · 2021/11/16(火) 00:56:44.96

>>697
主観的な記述だと思いますね
私は循環参照を許容できなければ、それはもはや GC ではないと思っています
マークスゥイープかコピーGC（そしてその発展系）しか私は認めません…①

①はともかく、何ができて何ができないか、により GC か GC でないかを明晰に分別すべきかと

**デフォルトの名無しさん** · 2021/11/16(火) 03:05:17.23

プログラマがfree相当の処理を明示的に書かなくてもメモリが解放されるのがGC

解放契機がGCの回収だろうがスコープを抜けるタイミングだろうが
コンパイラやランタイムといった処理系が暗黙的に解放処理を挿入するという点では同じ
サイクルを回収できる/できないの違いは、保守的GCと正確なGCの差違のように、GCという大枠の中での細部の差違でしかない

**デフォルトの名無しさん** · 2021/11/16(火) 03:08:48.13

単にGCと言ったときにガベージコレクションを意味するのかガベージコレクタを意味するのかが場合によって異なるから混乱を招いているのか

**デフォルトの名無しさん** · 2021/11/16(火) 03:19:14.90

>>700
プログラマーがfree相当の処理を明示的に書くことが
プログラマーがスマートポインタを明示的に宣言することに変わっただけなので
『スマートポインタはGCではない』となりますね
つまりプログラマーが明示的に関わっているか否かが要点

**デフォルトの名無しさん** · 2021/11/16(火) 05:03:45.36

>>702
「スマートポインタを明示的に宣言すること」がどうして「free相当の処理を明示的に書くこと」
になるのか理解できないなぁ。
宣言している時点では参照先のリソースを使用しているので、その宣言で解放されると困るわな。

ついでに言うと、shared_ptrにリソースの管理を任せるときは、shared_ptrがプログラムコードの
どの部分で（ソースコード記述的に）リソースを解放するのか決定できないことが多々ある。
これは「free相当の処理を明示的に書くこと」と決定的に異なる部分だな。

**デフォルトの名無しさん** · 2021/11/16(火) 06:34:55.21

じゃRustは所有権管理方式のGCってことでいいのかな？

**デフォルトの名無しさん** · 2021/11/16(火) 06:46:59.83

>>704
これまでのお約束とは異なる新しい判断ですね。

**デフォルトの名無しさん** · 2021/11/16(火) 08:06:16.34

>>704
機能だけ見れば、Rustは参照カウント方式の「GC機能」を持っていると言えるだろ。

「GC言語」とかいう定義もはっきりしないバズワードに当てはまるかどうかは知らん。

**デフォルトの名無しさん** · 2021/11/16(火) 08:37:19.90

「GC機能」とやらはどこで定義されてるん？

**デフォルトの名無しさん** · 2021/11/16(火) 08:42:24.55

>>707
>>684にWikipediaの記載を引用したから。
それともWikipediaの記載に異論あり？

**デフォルトの名無しさん** · 2021/11/16(火) 08:47:56.56

以下いずれもやっていること・行われることは全て同じ
抽象化と省力化が進んだのみ

C「free()で解放」
　↓抽象化＋付加機能
C++「deleteでデストラクタを呼んで解放」
　↓自動化＋所有概念(専有vs.共有)
現C++「スマートポインタ利用でdeleteを自動行使」
　↓全般化＋静的完全性チェックbyコンパイラ
Rust「全てがスマートポインタ相当扱い」

これらとGC言語の違いは「プログラマーがメモリ管理をしていること」
つまり一見すると自動解放されるためメモリ管理していないように見えるが
プログラマーは所有権を管理することでメモリ管理をしている

GCの定義を「利用者がメモリ管理をせずとも自動的にメモリが解放される」とすることで皆が納得できる

**デフォルトの名無しさん** · 2021/11/16(火) 08:59:05.41

>>706
Arc/Rcのことじゃないよ

動的に確保したメモリ領域を指してる所有権のある変数が
ムーブされずにスコープを抜ければ解放されるようコンパイラがよろしくやってくれる
これも参照カウント方式？

**デフォルトの名無しさん** · 2021/11/16(火) 09:08:46.14

>>708
ソースはWikipediaなの？

ちなにみ英語版では
> In computer science, garbage collection (GC) is a form of automatic memory management.
となってて機能というより形式って感じかな？　どうでもいいけど

あと
https://en.wikipedia.org/wiki/Manual_memory_management
のページのRAIIの段には
> This can also be used with deterministic reference counting.
> In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework,
> use of the shared_ptr template in the language's standard library to perform memory management is a common paradigm.
こういうのがでてきてるね
automate memory deallocation ね

**デフォルトの名無しさん** · 2021/11/16(火) 11:32:23.17

RustやC++にGCがないという言及でGCが意味するところはガベージコレクタというランタイム処理ののことで
ガベージコレクションの仕組みがないとは言っていないという理解をしている

**デフォルトの名無しさん** · 2021/11/16(火) 11:59:42.80

>>712
C++とRustは所有権による手動メモリ管理
ガベージコレクションではない

**デフォルトの名無しさん** · 2021/11/16(火) 12:16:23.63

いつまでやるんだよこの話
GCスレでも作ってそっちでやれ

**デフォルトの名無しさん** · 2021/11/16(火) 13:00:34.21

>>710
カウントしていないから違うんじゃないのかね。実際、他が参照していても（不要でなくても）スコープ抜けると解放されるし。

>>711
読み込めてないけど、スタックの積み降ろしでリソースを管理するのは昔からあったね。スタックマシンとかスタックのみforthとか。

>>713
さんざん指摘しているのにGC機能の定義が間違っているから話にならない。

**デフォルトの名無しさん** · 2021/11/16(火) 13:01:16.80

ぼくのかんがえたさいきょうのGC言語の定義なんぞ
プログラム作成になんの役にも立たんから
好きにしてくれ

**デフォルトの名無しさん** · 2021/11/16(火) 13:24:00.95

>>715
GCの定義ははっきりしている

ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち不要になった領域を、手動メモリ管理に依らず、自動的に解放されること。

**デフォルトの名無しさん** · 2021/11/16(火) 14:12:09.47

>>712
その場合はガベージコレクタとは何か？
ランタイム処理とは何か？って定義がないと境界線が曖昧なまま

ガベージコレクションを行う主体(行為者)をガベージコレクタ、
コンパイル時じゃなく実行時に解放タイミングを決定する意味でランタイム処理と言ってるなら
RustのRcやC++shared_ptrはGCの意味するところに当てはまる

ランタイム処理がGoやObjective-Cのようなruntime libraryによって行われる処理って意味で言ってるならあてはまらない

**デフォルトの名無しさん** · 2021/11/16(火) 14:12:38.51

wikipedia含め自然言語の定義など絶対的なものじゃないよ
その言葉を使った文脈で意味が正しく伝わればいいだけ

**デフォルトの名無しさん** · 2021/11/16(火) 14:16:08.22

>>714
Rust狂信者がGC無いということにして布教したくて、大暴れして嫌われてる真っ最中。完全頭がイカれてる
個々人の見方によればどうでも良い事なんだが、狂信者の"信仰が揺らぐ"ので納得しない。

**デフォルトの名無しさん** · 2021/11/16(火) 14:24:20.34

科学技術と科学技術が対立するのはよくある現実

対立するのは科学と宗教だと思ってるのは現実逃避

**デフォルトの名無しさん** · 2021/11/16(火) 14:25:50.64

>>720
C++とRustはGCが無いよ
その代わり自分で所有権の管理をしないといけない
見返りとしては速い

**デフォルトの名無しさん** · 2021/11/16(火) 14:26:44.88

>>715
参照カウントじゃないとしてGCの定義にしたがった場合にRustのやり方は何らかの方式のGCなのかどうか？

あとSafe Rustなら他が参照してればコンパイルエラーじゃないかな
unsafeなら参照側を長生きさせるバグを埋め込むことは可能

**デフォルトの名無しさん** · 2021/11/16(火) 14:28:43.97

参照カウントは、GCか、GCじゃないのか

クソどうでもいい
まあGCだけどね

**デフォルトの名無しさん** · 2021/11/16(火) 14:28:57.30

>>722
明確に間違いだな
自分で所有権の管理ができない場合にARCを使うんだろ？

**デフォルトの名無しさん** · 2021/11/16(火) 14:31:25.51

Rust寄りの話をすればGCの有無という定義より、現時点のコンパイラの方法は、Rustがメモリー回収の
コスト(CPU消費）が他に比べて小さいだけの話。参照カウントやBoxのようなスコープで解放と確保を
繰り返す事を「GCの有無に関せず」コストを話している人にも定義の有無の話にレイヤーが違うなどと
言いつつ巻き込んでくる。マジもんの狂信者には言葉は通じない

**デフォルトの名無しさん** · 2021/11/16(火) 14:34:03.96

>>725
Arcはマルチスレッドで共有する時にRcに対してアトミック操作が必要な時にRcの代わりに用いる

シングルスレッド共有:　Rc
マルチスレッド共有:　Arc　shared_ptr

もちろん後者の方がコストが高い

**デフォルトの名無しさん** · 2021/11/16(火) 14:40:58.65

SwiftやObjective Cなんかはさらに進んでいて、ARCだけだとカウントがボトルネックになる場合があるから
特定のデータ構造についてはGCみたいのを自作する。狂信者は聖典に書いてあることが真理。
レイヤーはネ申が決めた侵さざるべき領域、なんじネ申の言葉たるRustを喋れ、邪教たる他言語を駆逐せよ

**デフォルトの名無しさん** · 2021/11/16(火) 14:42:11.98

>>725
そしてもちろんshared_ptrもArcもRcも所有権を管理するために用いる
所有者が複数可能

一方でunique_ptrやRustの一般は所有者が1人のみなので所有権は維持するか譲渡するかになる

**デフォルトの名無しさん** · 2021/11/16(火) 14:57:58.41

>>727
ARCってこれのことでは？std::sync::Arcじゃなくてさ
https://en.m.wikipedia.org/wiki/Automatic_Reference_Counting

**デフォルトの名無しさん** · 2021/11/16(火) 15:08:54.50

>>730
それはSwiftやObjective-Cの話
一方で>>725はC++とRustの話に対してレスしている

**デフォルトの名無しさん** · 2021/11/16(火) 15:26:54.21

https://doc.rust-lang.org/std/rc/struct.Rc.html
> A single-threaded reference-counting pointer. ‘Rc’ stands for ‘Reference Counted’.

https://doc.rust-lang.org/std/sync/struct.Arc.html
> A thread-safe reference-counting pointer. ‘Arc’ stands for ‘Atomically Reference Counted’.

https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
> In computer science, garbage collection (GC) is a form of automatic memory management.

GCを自動メモリ管理の一形態と定義するなら
RCもARCも手動メモリ管理側に属するやろね
したがってGCではない

https://en.wikipedia.org/wiki/Manual_memory_management
> In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework
> C ++では、この機能(訳注：RAII)をさらに活用して、手動のフレームワーク内でメモリの割り当て解除を自動化します。

**デフォルトの名無しさん** · 2021/11/16(火) 15:32:41.58

嫌われ者の屁理屈大会

**デフォルトの名無しさん** · 2021/11/16(火) 15:45:11.75

>>732
それはもちろんそう
GCは定義にあるように自動メモリ管理
一方でC++とRustのスマートポインタは手動メモリ管理
したがってGCではないことが明白

**デフォルトの名無しさん** · 2021/11/16(火) 16:05:00.39

>>729
その複数の所有者によって共有される所有権を管理してるのは誰？
プログラマではなく「自動参照カウント機能付きのスマートポインタ」が、「自動的に」所有権を管理しているんだろ？

**デフォルトの名無しさん** · 2021/11/16(火) 16:07:51.68

GC言語でもどの変数がどのオブジェクトの所有者か意識してコードを書けばそれは手動管理しているからGCじゃないってことになるの？
C++やRust使ってても所有者を気にせずに全部shared_ptrかRcにするようなコードの書き方をすればGCになっちゃうの?

**デフォルトの名無しさん** · 2021/11/16(火) 16:09:38.42

Perlでメモリリークしがちな参照カウント方式でもGCとみなしてくれるなら許す

**デフォルトの名無しさん** · 2021/11/16(火) 16:21:49.03

>>735
いえいえ
GCのように見えない意識しない魔法があるわけではなくて
例えばRcはstruct Rcという構造体の型に過ぎなくてプログラマーは管理のために色んなメソッドを発行することも出来るんですよ
例えばRcから弱参照のWeakを作り出したりRc自身の弱参照数を得たり増減したら強参照数も同様です
つまり手動メモリ管理の範囲内なんですよ

>>736
GC言語には所有権の譲渡の機能もないし手動解放の機能もないためGC言語で手動メモリ管理は無理だと思います

**デフォルトの名無しさん** · 2021/11/16(火) 16:39:25.01

https://en.cppreference.com/w/cpp/memory/shared_ptr
ここにもズラズラ並んでるけどいろんな手動管理をさせてくれるよね
reset, swap, get, use_countなどなど
そもそも
https://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr
コンストラクタの時点で豊富にプログラマに選択肢を与えてる
アロケータやデリータも指定できて自由自在
このように、色々やることあるねプログラマ側は

**デフォルトの名無しさん** · 2021/11/16(火) 16:42:40.84

あ、ズラズラというならRcのほうを引用したほうがさらにズラズラだったか…

**デフォルトの名無しさん** · 2021/11/16(火) 16:49:31.73

ちなみにshared_ptr/RcがGCじゃない派の人って
C++のBoehmGCはどっち判定なの？
使い方的にはshared_ptrと同じくプログラマが明示的にBoehmGCからメモリ割り当てないといけないから
GCじゃないって扱いになるわけ？

**デフォルトの名無しさん** · 2021/11/16(火) 17:11:12.20

>>741
BoehmGCは手動メモリ管理ではなく
自動メモリ管理なのでGCです
プログラマーは所有権の譲渡や共有などのメモリ管理を全く意識せずに使えるからです

**デフォルトの名無しさん** · 2021/11/16(火) 17:15:07.88

屁理屈大将

**デフォルトの名無しさん** · 2021/11/16(火) 17:18:12.78

>>741
「手動メモリ管理はGCじゃない」んだからBohemGCもGCじゃないんだろ、そいつらの中では。

**デフォルトの名無しさん** · 2021/11/16(火) 17:23:12.05

>>744
BoehmGCはプログラマーが何も管理しないので自動メモリ管理ですよ

**デフォルトの名無しさん** · 2021/11/16(火) 17:29:26.94

GC_MALLOC(100000); // なにも管理しないぞ！mallocじゃないけどな！必死に自分の考えを押し付けようと１日張り付いてるニート

**デフォルトの名無しさん** · 2021/11/16(火) 17:35:28.45

>>742
手動メモリ管理と自動メモリ管理を定義して、BohemGCとshared_ptrの違いを明確化してから主張してくれ。

所有権とか言っているけど、shared_ptrもBohemGCもshared_ptr・BohemGCがリソースの解放責任を持つ（プログラマが解放するのは非推奨・未定義）ことには変わりないから、所有権とか言うならその違いも明確化してくれ。

>>745
shared_ptrだって「プログラマーが何も管理しない」だろ。何を管理すると主張する？

**デフォルトの名無しさん** · 2021/11/16(火) 17:37:18.20

vec![ 0; 100000 ]; // 何も管理しないぞ！GCじゃねえったらGCじゃねーんだ！黙れ小僧！Rustの宣伝を受け入れろ！

**デフォルトの名無しさん** · 2021/11/16(火) 18:01:15.45

>>747
本気で言ってますか？
スマートポインタではプログラマーが所有権の管理をしているからこそ
毎回プログラマーはここで使うべきはunique_ptrでいいのかshared_ptrにすべきかあるいは既存スマートポインタの参照にすべきかもしくは譲渡すべきか等を管理しながらプログラミングしているのです
これを使い間違えるとメモリ管理ミスとなる多重解放や解放忘れや解放済み領域参照などが起きてしまうのです
Rustでもほぼ同様ですが使い間違えているとコンパイルが通らない点だけ異なります
C++とRustどちらもプログラマーが上述の手動メモリ管理をしながらプログラミングする点で同じです

一方でBoehmGCでは上述の手動メモリ管理をせずに使えます
自動メモリ管理方式となっています

**デフォルトの名無しさん** · 2021/11/16(火) 18:41:22.00

Rustも使い方を間違えると循環参照ができてコンパイルは通ります。Boehmでもnew (GC) char[size]で
class Foo: public gc{}しなければ回収されません。
その他ではディストラクタの回収ではなく不定期改修ではnew (GC)で、gc_cleanupから派生させる必要が
あります。とてもではないですが、「手動」「自動メモリ管理方式」などと、屁理屈を捏ねて言い負かそうと
必死こいてる哀れな狂信者は言葉は通じないです。

**デフォルトの名無しさん** · 2021/11/16(火) 19:14:07.66

>>750
BoehmGCは言語の機能ではなくライブラリなのだから呼ばなければGCが始まらないのは当たり前
自動メモリ管理と手動メモリ管理の区別はそんな表層的などうでもいいことではない
それを理解できない人がいるとは驚いた

C++スマートポインタとRustでは手動メモリ管理のため
使い方を間違えるとメモリ管理が破綻して深刻なバグが生じたりコンパイルが通らなかったりする
これを解決するにはプログラマーがメモリ管理を常に考えてどこにどんなスマートポインタを用いたり所有権は渡さずに参照にするのか譲渡するのかコピーするのかなど毎回各所で全て考えて手動メモリ管理を行なう

一方でGC言語やBoehmGCなどは自動メモリ管理なのでプログラマーは上述のようなことを考えなくてもよい
言語システムやGCライブラリにお任せとなる

**デフォルトの名無しさん** · 2021/11/16(火) 19:27:51.29

>>749
プログラマが
「unique_ptrでいいのかshared_ptrにすべきかあるいは既存スマートポインタの参照にすべきかもしくは譲渡すべきか等を管理しながら」
プログラムしているからGCじゃないという主張か。

なら、すべてshared_ptrに統一して所有権の管理なんてしなければいい。実際、既存コードとの互換性問題やプログラムの性能問題が無ければ推奨されるshared_ptrの使い方だしな。
そうすれば>>749の主張する「自動メモリ管理方式」とやらも実現できるからBoehmGCみたいなものだ。

あと、>>751の主張をするなら、まず初めに「自動メモリ管理方式」「手動メモリ管理方式」の定義と差分を明確にしなくては話にならない。

「使い方を間違えると」とか、曖昧な話でごまかすなよ。「それを理解できない人がいるとは驚いた」みたいな人格攻撃する暇あったら、グウの音も出なくなるぐらい堅牢な議論をしてみろよ。

**デフォルトの名無しさん** · 2021/11/16(火) 19:27:54.43

BohemGCは昔から気になってるけど
結局一度も触ったことが無いな

https://www.hboehm.info/gc/
> The Boehm-Demers-Weiser conservative garbage collector
> can be used as a garbage collecting replacement for C malloc or C++ new.
> Boehm-Demers-Weiserの保守的なガベージコレクターは、
> C mallocまたはC++ newのガベージコレクションの代替として使用できます。

作者（？）が言ってるようにこの場合は garbage collector なんよね
しかもガベージコレクションの代替として使用できるとのこと

なんか知らんけど色々プログラマ側から触れるようになってるんだとしたら
結局は手動メモリ管理って感じもするけど（よく知らない状態での想像）

**デフォルトの名無しさん** · 2021/11/16(火) 19:28:00.82

Rustの不都合なことを言われて、知りもしないのに墓穴を掘る狂信者ｗ
さっきはRustならコンパイルが通らない点だけ異なりますと言っていたのに、今度は深刻なバグが生じたりと言い出す。
手動自動なんていう浅はかな考えを押し通そうとしているから、知らない事を突かれる。
まあRustの肩をもつなら、Rustは独立したスレッドのサイクルコレクターが無い点が「フルスペックのGC」では無いといえるかもしれんが
狂信者の話には１つも出てこない。あんたのその理論というにはお粗末な考えで全員が黙ったとしても、ここに顔出す人以外は
GC的なアルゴリズムだろ？と言われてまたワンワン噛みつくのか？めっちゃ迷惑だと思うがｗ

**デフォルトの名無しさん** · 2021/11/16(火) 19:52:23.46

言語の分類に関して言うなら性能特性に着目して分類するのが有用
malloc/freeグループといわゆるGCグループに分けられて、スマートポインタは前者になる

>>718
後者の意図
プログラムの実行とは切り離された別のコンテキストで回収処理が行われる場合に
その行為者をガベージコレクタと呼んでいた

コンテキストという言葉は適切じゃないかもしれないが、別スレッドとか別タスクとか、そういう意味で使っている

**デフォルトの名無しさん** · 2021/11/16(火) 19:55:08.32

いつの世も狂信者というのは害がないうちは、公式のご本尊や、偉い人から見逃されるけど
害を及ぼすような事をやり出したら破門されんねん、ほんま迷惑

**デフォルトの名無しさん** · 2021/11/16(火) 19:58:48.30

プログラマが解放処理の呼び出しを書く必要があるのが手動メモリ管理
書かなくても(典型的なケースで)自動的に解放処理が呼び出されるのが自動メモリ管理

malloc/freeは手動メモリ管理
GCやスマートポインタは自動メモリ管理

というかスマートポインタという名前自体プログラマが介在しなくてもよしなにやってくれる賢いポインタという意味なので
これを手動メモリ管理と呼んでしまうのは違和感しかない

**デフォルトの名無しさん** · 2021/11/16(火) 20:03:07.86

プログラマがshared_ptrとunique_ptrを選択しないといけないから手動メモリ管理との主張だが
仮にshared_ptrしかない言語が存在したとしたらそれは自動メモリ管理になるのか？

**デフォルトの名無しさん** · 2021/11/16(火) 20:12:14.40

>>754
Rustでは手動メモリ管理を間違えても深刻な事態は起きないよ
並行時と並列時も含めてメモリ競合も問題が起きないように設計されていてコンパイラが静的に検出してくれる
メモリ関連で静的に検出できないのは循環参照くらいだよね
原理的に無理なのだからこれは仕方ない

>>752
> なら、すべてshared_ptrに統一して所有権の管理なんてしなければいい。

それだとプログラマーが管理すべきことが消えて自動メモリ管理すなわちGCになってしまうよ
もちろんshared_ptrはコストが高く遅すぎてそんなことをするプログラマーはいないね
あと一時参照やunique_ptrを駆使すれば済むところを全てshared_ptrにすると循環参照の生じる機会が激増しちゃう
だからshared_ptrの使用は最小限に抑えて他を用いる
最小限のshared_ptr使用でも循環参照の起きうるところがあるならばweak_ptrを用いて循環参照を回避する
これらもプログラマーの手による手動メモリ管理

>>757
このようにスマートポインタは手動メモリ管理です

**デフォルトの名無しさん** · 2021/11/16(火) 20:20:02.11

>>755の説明が一番しっくりくるな
これならRustもGC言語じゃないって言えるしこの辺で手を打ちませんか？

**デフォルトの名無しさん** · 2021/11/16(火) 20:38:12.95

見たくない真実はガン無視する手動自動マンｗ
”サイクルコレクターが無い点が「フルスペックのGC」では無いといえるかもしれん”をガン無視して
世紀の難解手動自動相対性理論に取り組む、いまだに答えは出ないが何やら信念があるらしい。知りたくもないｗ

**デフォルトの名無しさん** · 2021/11/16(火) 20:42:55.59

そもそもキッチリ区別できるようなGCの定義なんて元々ないでしょ

数学みたいな厳密性などはもちろんなく、ただの処理系や実装上の戦略のようなもんみたいだし、
どっちつかずな処理系もありそう

**デフォルトの名無しさん** · 2021/11/16(火) 20:46:35.71

「全部shared_ptrにしたらGCになる」ってすごいな
使い方によってなったりならなかったりするのか
その調子だとJavaにJNI経由でC由来のポインタ持ち込んだら手動管理になってGCじゃなくなりそう

**デフォルトの名無しさん** · 2021/11/16(火) 20:47:19.95

>>759
> それだとプログラマーが管理すべきことが消えて自動メモリ管理すなわちGCになってしまうよ
なら、>>759の心の中でもshared_ptrはGCということだな。
>>759の中では、GCがGCかどうかはGCをどう使うかで決まるとういことかよ。
アホらしい話だな。

**デフォルトの名無しさん** · 2021/11/16(火) 20:55:04.64

>>762
ええ意見。手動自動マンのいうとおりならSwiftはRustでいうRc,Arcなんてものは無く、弱参照はあるものの
自動でARCが動くんだけど、彼の高等理論ならどっちに分類されるんだろ…？ｗ
まあ彼・彼女？個人的な見方は否定しないけど、どうあっても他人を全否定したいみたいだけどGCの話より
どういう人なのか少し気になるｗ

**デフォルトの名無しさん** · 2021/11/16(火) 21:08:21.89

>>763 >>764
ホントに理解できていないのか理解できていないフリをしての冷やかしなのか分からなくて悩む
仕方ないので補足説明する

【以前の手動メモリ管理】
malloc等に対して直接freeをどこでどのタイミングで行うかで手動メモリ管理していた

【スマートポインタ時代の手動メモリ管理】
各種スマートポインタの使用・譲渡・コピー等および各種参照形態を
どのように使い分けてどのように組み合わせて用いるかという形で手動メモリ管理をしている

だからその使い分け組み合わせパーツの一つにすぎないshared_ptrというポインタに対してそれはGCだ！との主張は意味がないことが明らかで
もし理解出来ていない人がいるならばここで躓いている

**デフォルトの名無しさん** · 2021/11/16(火) 21:34:08.28

>>766
ちゃんと定義して、それぞれの違いを明確化するまで「手動メモリ管理」「自動メモリ管理」は使用禁止な。
エスパーじゃないんだから、>>766の心の中にある想像上の「手動メモリ管理」なんて理解できるわけ無いだろ。
この分じゃ>>766も「手動メモリ管理」「自動メモリ管理」の差分すら明確化できていないだろ。

> だからその使い分け組み合わせパーツの一つにすぎないshared_ptrというポインタに
> 対してそれはGCだ！との主張は意味がないことが明らかで

おいおい、>>759で「shared_ptrで統一すればGCになる」と発言しているだろうが。
何で「GCだ！との主張は意味がないことが明らかで」なんだよ。
>>759は意味のない主張をするようなデタラメなやつだと言いたいのか？

**デフォルトの名無しさん** · 2021/11/16(火) 22:10:19.07

言葉の定義がどうのというバカが現れると必ずこうなるよな

**デフォルトの名無しさん** · 2021/11/16(火) 22:30:38.03

>>767
wikipediaに明確な定義がありますね

『ガベージコレクション (Garbage Collection)』
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
> In computer science, garbage collection (GC) is a form of automatic memory management.
ガベージコレクション(GC)とは、自動メモリ管理です。

『手動メモリ管理 (Manual Memory Management)』
https://en.wikipedia.org/wiki/Manual_memory_management
> In computer science, manual memory management refers to the usage of manual instructions by the programmer to identify and deallocate unused objects, or garbage.
手動メモリ管理とは、使われていないガベージを解放するためにプログラマが手動で命令を書くことです。
> Manual memory management has one correctness advantage, which is that it allows automatic resource management via the Resource Acquisition Is Initialization (RAII) paradigm.
手動メモリ管理にはその正しさの利点があり、RAIIを介した自動リソース管理を可能にします。
> This can also be used with deterministic reference counting. In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework,
これは参照カウントとともに使用することもでき、C++ではshared_ptrにより手動のフレームワーク内でメモリ解放を自動化しています。
> use of the shared_ptr template in the language's standard library to perform memory management is a common paradigm.

つまり上記のwikipediaにおける定義をまとめると
・自動メモリ管理　←GCはここ
・手動メモリ管理　←shared_ptrはここ

**デフォルトの名無しさん** · 2021/11/16(火) 23:08:56.24

>>769
いやそれshared_ptr自体は自動メモリ管理であり、手動管理と組み合わせて使用できるって言ってるじゃん

**デフォルトの名無しさん** · 2021/11/16(火) 23:11:50.79

>>770
え？
自動メモリ管理とは書かれていませんよ

**デフォルトの名無しさん** · 2021/11/16(火) 23:49:36.51

ウンコが都合の悪いことが書かれると、デカいの張り付けて手動自動理論に持っていくｗｗｗ
愛してるはずのRustにすら害を及ぼす腐った狂信者ウンコ。残ったのは自尊心のみ。「ここ」は便所の落書き

**デフォルトの名無しさん** · 2021/11/16(火) 23:59:32.22

>>770
手動メモリ管理のアドバンテージとしてshare_ptrの例が出ている>>769

**デフォルトの名無しさん** · 2021/11/17(水) 00:04:50.96

>>709
これが一番納得

**デフォルトの名無しさん** · 2021/11/17(水) 00:07:56.38

じゃあSwiftは自動で管理してるからARCだけどGCなんだな？どんどんRustが嫌いになっていく…

**デフォルトの名無しさん** · 2021/11/17(水) 00:43:47.98

言語機能にどういうラベルを貼り付けるかの議論でよくもまあここまで盛り上がれるな
別に言語がGC含むとされようがされなかろうが
実態は変わらないだろうに

**デフォルトの名無しさん** · 2021/11/17(水) 00:59:15.40

>>769
Wikipedia英語版で決着ついたのか
これでスマートポインタは手動メモリ管理であってGCではないと確定だな

**デフォルトの名無しさん** · 2021/11/17(水) 01:32:43.67

まず決着を付ける目的はなんなの？
今更で申し訳無いが

**デフォルトの名無しさん** · 2021/11/17(水) 02:15:20.38

>>769
そこのwikiにはshared_ptrが手動メモリ管理なんて一言も書いてないね
結論捻じ曲げすぎてびっくりしたわ

**デフォルトの名無しさん** · 2021/11/17(水) 02:19:34.31

当たり前の話なのに
びっくりしてるとしたら
そっちのが恥ずかしい

**デフォルトの名無しさん** · 2021/11/17(水) 03:01:08.49

>>779
書いてあるようだが
手動メモリ管理のよってRAIIを介したshared_ptr等の自動リソース管理を可能にしていると

>>769
>>手動メモリ管理にはその正しさの利点があり、RAIIを介した自動リソース管理を可能にします。
>>これは参照カウントとともに使用することもでき、C++ではshared_ptrにより手動のフレームワーク内でメモリ解放を自動化しています。

**デフォルトの名無しさん** · 2021/11/17(水) 04:04:22.02

ようやくこのスレも役目を果たし終えたな

**デフォルトの名無しさん** · 2021/11/17(水) 08:38:44.32

>>769
なんで
手動メモリ管理　←shared_ptrはここ
という結論になると判断しているのか全然わからん。

手動メモリ管理とは、使われていないガベージを解放するためにプログラマが【手動で命令を書くこと】です。

C++ではshared_ptrにより手動のフレームワーク内で【メモリ解放を自動化して】います。

で、shared_ptrは【メモリ解放を自動化して】なので【手動で命令を書くこと】を満足していないから、手動メモリ管理ではないという結論にしかならんが。

**デフォルトの名無しさん** · 2021/11/17(水) 08:49:09.28

>>778
私利私欲を捨てさせることが目的のように見える
私的な目的を持たないことが目的みたいな