次世代言語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/14(日) 16:22:12.42

>>631
shared_ptrなりRcなりは普通にコーディングするとスコープ抜けたり所有権失ったり獲得した領域が不要になったタイミングで即時freeされるけど
ビジー状態終了後にまとめてfreeしたいならそれまで参照を生かしておくなどの工夫が必要だよね
いわゆるGCならGCを一時的に止めるだけで比較的簡単に実現できる

ただ、C++やRustでこういう状況に対応しようとしたら arena 使うのが定石な気もするのであまり意味のない比較だったかも

そもそもこういうワークロードが現実的にどの程度存在するかもよくわからないし
freeのオーバーヘッドがどの程度大きいかにも依るので
実際のアプリケーションのベンチマークとかとらないとちゃんとした議論はできない気がしてきた

**デフォルトの名無しさん** · 2021/11/14(日) 17:11:54.46

shared_ptrやRcは参照カウント方式のGC機能を提供するライブラリ
これらをGCとは呼ばないというのは無理がありすぎる

「GC言語」はGCの利用を基本的前提として設計されてる言語という意味なので
non-GC言語にGC機能が用意されてるからといってGC言語に分類されるわけではない

**デフォルトの名無しさん** · 2021/11/14(日) 17:18:41.30

>>626
C#はこの前メソッドチェーンでとやかく言ってた人たちには、LINQ表現などはさらに一歩進んだ考えだが、彼らが
このような記述表現が、仮にお気に入りの言語に入っても大喜びするとはとても思えない。
GCの観点でいえば、JavaやC#などのclassで参照を多用して並列GCでストップのあるものと、Goのようにstruct値
だけだが、軽量スレッドがあるために並列GCにしなければならなかったものとは同じ土俵で比べるべきではない
これは同じく、並列GCを用いないDIO様がいない世界の言語とも比べらずらい。

**デフォルトの名無しさん** · 2021/11/14(日) 17:26:09.38

>>633
shared_ptrやRcはライブラリではありません
単なるスマートポインタです
ポインタを使い終えると対象を自動的に解放します

例えばC++では同じスマートポインタとしてunique_ptrもあって使い終わると自動的にdeleteが呼ばれて解放されます
同様にshared_ptrもあって使い方終わると自動的にdeleteが呼ばれて解放されます

これらのどこにガベージコレクションの要素がありますか？
shared_ptrをGCだと主張するならばunique_ptrについてはどうですか？
もし仮にdeleteが呼ばれて解放することをGCだと主張するならばC++では常にGCが行われていることになってしまいますが？？

**デフォルトの名無しさん** · 2021/11/14(日) 17:53:57.69

>>632
freeはそんなに重くないにしても、メモリアロケーションは論理アドレスから仮想アドレスへ変換し更には連続し
適したサイズの空間を見つけるために当然ながら重くなる。
Linuxカーネルの場合のBuddy実装があるに、tcmalloc/jemalloc/dlmalloc/mimalloc/boehmなど、プログラムに
より適化したOSSの実装が次々と出来ていることからも、仮にプログラムがメモリ漸増するものではなく決定論的な
予測が可能である場合なら、逐一メモリー確保のためにOSに介在するよりも、プログラム開始時にドカンとメモリを
確保したほうが早くなる可能性もある。もし可能なら今の型推論と同じくこれはコンパイル時に解決されるだろう

そういった意味で言えばアロケーションと解放のプログラムからの切り離しは、Goにおけるコンテキストスイッチの
話とも似ていて、言わばローテクともいえる参照カウントや逐一解放が絶対的、将来に渡って良いとは言い切れない。
もちろん並列GCのおける全停止は問題だが

**デフォルトの名無しさん** · 2021/11/14(日) 18:45:12.28

流れまったく読んでないけど
スマートポインタはGCではないだろうｗ
Javaが出るときC++とくらべてこんなにもシンプル！というのと
C++とくらべてGCがある！という宣伝だったと思うけど

**デフォルトの名無しさん** · 2021/11/14(日) 19:33:55.78

ランタイムレベルてmark-and-sweepしたりcopy GCしたりするやつはtracing GCという名前が付いています
使い分けよう

**デフォルトの名無しさん** · 2021/11/14(日) 19:59:08.54

>>637
Javaが出たときにスマートポインタってあったのか？

**デフォルトの名無しさん** · 2021/11/14(日) 20:11:47.32

疎結合という便利な言葉を思い出したから使おう
言語仕様を一切変更することなくスマートポインタを追加とか削除できるのは疎結合だよな

**デフォルトの名無しさん** · 2021/11/14(日) 20:20:08.21

なんでGCの有無を気にするかというと、GCの挙動があるとやりづらい対象があるからでしょ？
GCが前提にある言語だと、大抵はその言語の普通のスタイルからかけ離れた、マイナーなテクニックが必要になってウザい
GCが無くても普通に使える言語ってのは、プログラマのUXを変えずにそういうジャンルに手が届く＝同じノウハウを共有できるから良い

そういう意味ではRustはRc無しで十分に使えてる。何でもかんでもRcやArc！みたいな風潮は無い

**デフォルトの名無しさん** · 2021/11/14(日) 20:23:46.45

>>640
単にopt-inであるってだけじゃないですかねそれは
疎結合っていうとインターフェースが適切に定義されていて特定の実装に依存していないこと

**デフォルトの名無しさん** · 2021/11/14(日) 20:24:33.68

意味不明なことを書いたやつが一番偉い

**デフォルトの名無しさん** · 2021/11/14(日) 22:27:20.79

>>635
参照カウント方式はGCじゃないって主張なの？
それならshared_ptrやRcはGCじゃないって言うのは理解はできる(同意はしないけど)

参照カウント方式もGCの一種だけど
それを実装してるshared_ptrやRcはGCじゃないって主張ならちょっと理解不能

ちなみに有名なGC本の「The Garbage Collection Handbook」には
shared_ptrやunique_ptrが参照カウント方式のGCとして説明されてるよ

**デフォルトの名無しさん** · 2021/11/14(日) 23:54:26.37

>>644
C++もRustもこの点で全く同じだからC++で説明すると

まずunique_ptrは所有者が常に1人だけのスマートポインター
所有権は譲渡することができる
所有者のスコープが尽きたら自動的にdeleteが呼ばれて開放(回収)される

次にshared_ptrは所有者が複数可能なスマートポインター
所有権は共有することができる
全ての所有者のスコープが尽きたら自動的にdeleteが呼ばれて開放(回収)される

このようにどちらも全く同じ仕組み
(1) shared_ptrでは所有者の数を数えるためにカウントしているけれどカウントしているとGCなの？
(2) unique_ptrでは所有者1人だからカウントはしていないけど全く同様に自動的にdeleteされて回収だけどGCなの？
(3) スマートポインターを使わない場合は手動でdeleteを呼んで回収だけどGCなの？

以上の3点をよろしくおねがいします
3つとも仕組みは全く同じで同じように回収されていきますがカウントしているとガベージコレクションなのですか？

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

教科書等の標準的な定義と違うことを言い出す奴が
説明しろよ

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

garbage collectorとgarbage collectionは別だろう
645の1,2,3はいずれも後者の一手法に該当する
前者は後者を実行する主体であり、スマポは前者には該当しないとするのが普通
能動的にgarbage collectionを行うというよりプログラマ自身がそれを行うための補助に過ぎないからな

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

俺が信じるGCを信じろ！

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

手動で解放するコードを書かなくても自動的にヒープメモリを解放してくれるのがGCだよって言えばshared_ptr、unique_ptrはGCになるでしょう。
でもヒープメモリが解放できるようになってもすぐに解放せずにあるタイミングでいっきに解放するのがGCだっていえばshared_ptrとunique_ptrはGCにならないでしょう。

**ハノン** ◆QZaw55cn4c · 2021/11/15(月) 06:52:03.10

>>649
＞手動で解放するコードを書かなくても自動的にヒープメモリを解放してくれるのがGC
足りない。
この条件＋「循環参照も問題なく扱える」という条件を追加して！

＞ヒープメモリが解放できるようになってもすぐに解放せずにあるタイミングでいっきに解放するのがGC
動作タイミングはGCの本質ではないとおもいます

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

>>648
藁人形論法が標準化されたら平和になるどころか争いが増えるだけだな

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

なんだ朝鮮人か

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

うっせー！GCじゃないぞ！こ、これはセガサターンだ！(笑)

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

争いの原因は多様性ではなく
テンプレ化した標準的な決まり文句なんだよ

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

なんか変なこと言われてたような気がしたけど、Perlは参照カウンタ方式のGCを採用した言語だよ

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

「The C++ Programming Language(4th)」もshared_ptr達をgarbage collectionの一種として説明してるね

===引用===
Thus, shared_ptr provides a form of garbage collection that respects the destructor-based resource management of the memory-managed objects.
(中略)

We can address problems related to the lifetime of a shared subobject by introducing a form of garbage collection. For example:
struct S2 {
　shared_ptr<int> p;
};
(中略)
In fact, shallow copy and such entangled objects are among the sources of demands for garbage collection. Entangled objects lead to code that is very hard to manage without some form of garbage collection (e.g., shared_ptrs).
=========

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

擬似問題起こしているな。
とりあえず>>633はちゃんと区別して議論したら？

c++は「GCを前提とした言語」じゃないけど「GCの機能のある言語」だろ。

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

garbage collectionを実行するのがプログラマなのかgarbage collectorなのかというだけの話だな
プログラマから見てgarbage collectionが完全に隠蔽されているなら、
参照カウント方式だろうと何だろうと、もはやどこかにgarbage collectorなるものが存在していると考えていいだろう
C++のスマポはプログラマが意識しなくていいという程ではないからふつうgarbage collectorとは呼ばない

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

参照カウンタはgcでは無い、ということにすると
なんか技術的な発展あるの？

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

gcの実装手段の1つとして参照カウンタはある
しかし参照カウンタだからといってgcということにはならない
それだけｗ

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

コア言語レベルだと、GCのある言語/無い言語って区分は正確じゃなくて
手動でメモリ管理しなくていい言語/しないといけない言語
っていうのが正しいよね

手動管理しないといけない言語でも、ライブラリのサポートによって部分的にGCまかせにすることはできる
その場合でもGCを使う選択だけはプログラマが明示的に行う必要がある

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

>>659
純粋な参照カウント方式のみでは循環参照に対応することができず、一般にGC付きの言語とされているもので参照カウント方式を採用している言語は、それ以外にマークアンドスイープなどで循環参照が起きた場合それら自身以外から（プロセスのRootから連鎖的に）指されていないことを見つけ出して削除する方法を併用している

これを行わない場合、つまりC++のshared_ptrなどの例の場合は、適宜手動でweak_ptrを用いるなどして循環参照が起きないようにプログラマが管理するか、プロセスが終わるまで循環参照が残存する事を許容する必要がある

従って参照カウント方式そのものをGCでないということにすると、完全に自動化されているGCを考える場合は、その循環参照への対処に対する+αの手法が何かというところに重点が置かれるし、その+αが弱参照のような手動の手法である場合、メモリ管理が完全には自動化されていないという点でGCでないと線引きする事ができる

と、私は認識している
間違いがあったら有識者は叩いてくれ

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

>>645
プログラマーの視点からはその(1)(2)(3)の3つともGCではないな
C++言語仕様的にその3つは全く同様にdeleteで配列でもクラスのインスタンスでもメモリ回収されていく
だから参照カウンタを用いているshared_ptrだけGCだとの主張にも実態との大きな乖離があり違和感がある
GC派の人は以上の点をどう捉えている？

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

>>636
GCの未来を考えると、確かに、特定のアプリケーション領域に特化したメモリー確保やアライメントがあるわけで
tcmallocやhoardが低スレッド数では明らかにglibなどのmallocより速い事は、現状のシンプルな参照カウントが
絶対的に有利とはいえないね。GCであるない分類なんてどうでも良い話だわ

ちょっと前の話で出てきたUnity3Dで構築済みのオブジェクトをキャッシュして使いまわしパラレルGC（もっと
言えばS.T.W)を発生させないというテクニックも一歩前に進んで考えれば、都度のメモリー確保と破棄の時間を
省略し、さらに進めば複雑なオブジェクト構築に掛かる時間も部分的には省略可能なわけで、そこまでGC実装が
手が届くかはまだ疑問が多いが、今コンパイラにある最適化して実行速度を速めるフラグにはあまり使われない
バイナリーを小さくするトレードオフなフラグがあるが、メモリー効率を無視してより実行速度を高めるような
最適化を行うことを行いだしても不思議ではない。C系のコンパイラだとシステムコールや標準ライブラリには
厳密な意味があるのでメモリーの事前確保は難しいかもしれないが、他の言語でよくあるList構造なんかでは
それが必ずメモリー確保を必ず同期的に行うとは深く言及していない言語は、そのような道をたどるかもしれない。
tcmalloc/jemallocなんかもメモリプールを随分前に導入しているしね

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

>>662
Perlに限っていうと、参照カウント式のGCしかなくて、循環参照を自動で削除するような方法は併用されていません
よって、おっしゃるようにプログラマが弱参照を使ってくれないとメモリリークが簡単に起きます

でもPerlもGC言語の仲間に入れてください。お願いします

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

まあgcは自力で実装できるしね

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

Rust 使っとけばオケという事でオケ？

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

>>665
Perlは全てが参照カウンタでありプログラマーはそれを意識することなく回収されていくから明確にGC
一方でC++やRustは基本的に参照カウンタは用いておらずプログラマーは複数所有になる時のみ意識してshared_ptrやRcを用いており回収される時には付加動作もプログラミング可能だからGCではない

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

せやな

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

>>664
まあメモリーの少ない環境で処理のピークとなるようなメモリー確保を行うのは迷惑かもしれんが、現状だって
多くのアロケーターはvec![1, 2, 3]やmake([]int,5)としても断片化させないために2^Nの確保を行うからね。
逆を言えばメモリーの使用量効率が圧倒的に（現在の理論の範囲では）良いのはRust/C++だろうけども使用量が
ピークに耐えうる環境で無ければ、実行できないか例外やパニックになり目的の動作を達成しえないわけで
逐次の動的確保と解放を完全否定するものではないが、アロケータのメモリープールは実装され実証されていて
GCというか確保と解放をプログラミングから切り離す事は正常な発展の道だとも思える

GCであるないの話はお気に入りの特定の言語でそう呼ばれたくない人がいるだけで、それを全員認めて広く世に
一般化がなされても自己満足以外に何か得られるようなものではない

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

Perlは循環参照だめなのか
そりゃ廃れるわ

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

RustもSwiftも循環参照はダメだぞ

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

>>670
ヒープを用いるだけのことまでもGCとみなすその考えはおかしいのではないか？
その考えだとC言語でfree()することもGCとなってしまう

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

>>672
CでもC++でも循環参照は当然起きるけど何を問題にしている？
所有者の概念のある諸言語は所有権を持たない弱参照が必ずあるので困ることはない
同時に生ポインタがある諸言語は自分で管理することも可能
そこがGC言語との大きな違い

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

>>673
ちゃんと元読んでます？ハードウェア寄りのOSやドライバーを書く言語では、厳密性が求められるだろうから
実際に確保しない/実際には開放しないなんて許されないだろうけど、C言語でも数あるアロケーターはfreeで
実際には使われていないマーキングだけが行われる事もある。そしてfreeでOSに返却した場合でも、OS自体が
コンパクションの動作を行うなどはGCであるとは言えないが、GCのような動作を行う。何が違うかといえば
アプリケーションが関与してないだけであり、重要なのはCPUは使用されるという事であり無駄を省くという
観点からいえば、GCという枠を超えメモリー管理は特化した最適化が行えるだろうという話

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

>>675
そこは明確にレイヤーが異なる
(1)OSからシステムコールでヒープ領域の大きさを変更するレイヤー
(2)確保されているヒープ領域の中を管理するレイヤー
(3)GCやデストラクタ等でプログラムから利用された部分をヒープ領域に戻すレイヤー (逆の確保も含む)
今回行われているGCの件は(3)の話

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

>>676
誤記を訂正しておく
ごめんね

誤: (1)OSからシステムコールでヒープ領域の大きさを変更するレイヤー

正: (1)OSへのシステムコールでヒープ領域の大きさを変更するレイヤー

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

>>676
あなたがしたい話をしている場ではありません。全く１つも理解していないのに絡んで来ないでください。
私は所有者だの弱参照だの話してませんし正常に話す気が１つもない人を相手にするつもりはありません

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

Swiftは何でもそろってるので何でも対応可能
strong参照
weak参照
unowned参照
UnsafePointer
UnsafeMutablePointer
UnsafeRawPointer
UnsafeMutableRawPointer
UnsafeBufferPointer
UnsafeMutableBufferPointer
UnsafeRawBufferPointer
UnsafeMutableRawBufferPointer
AutoreleasingUnsafeMutablePointer
OpaquePointer
などなど

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

スマートポインタをGCであるということにして
誰がどう嬉しいんだろう？
持ったポインタをデストラクタでdeleteするだけのコンテナに対してだ

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

こうすれば嬉しいという理想よりも
どうしようもない現実の方を重視する人もいるかもしれない

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

循環参照OKな言語ってあるの？

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

>>680
>GCであるないの話はお気に入りの特定の言語でそう呼ばれたくない人がいるだけ

辛辣www
ほとんどの人は興味ないが、某お気に入り言語の一部の狂信者が、同じく参照カウントのSwiftはGCと
言われるのに、お気に入りの言語はそう呼ばれくなくて信者を増やしたんだろう？そんなことで集めた
信者なんて役に立たないどころか稚拙なコードの手直しをすることになりかねないのにね
公式がそのような文言で宣伝してるから、ある意味では勅命とか聖戦みたいなもんだな

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

>>680
スマートポインタは「GC機能」の実装（のひとつ）だろ。このスレでいう「GCを前提とした言語」になるわけではないが。

一部の人間が悪意を持って「GC機能」と「GC言語」を混同しようとしているからグダグダになる。>>683に同意せざるを得ない。

そもそもの話、wikipediaの定義（解説）に異論のあるやつは居るの？

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

**デフォルトの名無しさん** · 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の話に対してレスしている