次世代言語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/13(土) 21:05:09.14

更に言えば多くの独立したgcのある言語は、gcにおけるメモリー断片化を防ぐコンパクション処理を独自にやっている訳でOSに任せているRustが有利なのはその通りですが、だからと言ってその処理を行って無い事を不正という話には全くなりませんし、原理的にどうやっても等という結論出すことは全く意味がありませんね

**デフォルトの名無しさん** · 2021/11/13(土) 21:14:45.54

>>600
参照カウンタはオペレーティングシステム内でもファイルシステムでも用いられている普遍的なデータ管理方式
参照カウンタを用いていることをガベージコレクションだと主張する人はいない
C++もRustも所有者が複数とせざるを得ない特殊ケースにおいて最適最速な方式として参照カウンタを用いている

>>602
やはりCもC++使ってことがない初心者だったのか
shared_ptrはCではなくC++です
そしてC++のshared_ptrはRustのArcと同じもので参照カウンタを用いている
あなたの無茶苦茶な主張では「C++とRustはGC言語」となるが世間では当然そんな主張は存在しない
もう一つのあなたのデタラメな主張「GC言語は速い」というデータも世間には見当たらない

**デフォルトの名無しさん** · 2021/11/13(土) 21:24:08.80

ガベージコレクション
https://ja.wikipedia.org/wiki/ガベージコレクション
じゃあページの記述を削除して直して来いよ。顔真っ赤にしなくても良い話だぜ？書き間違いぐらい読もうよ？
「GC言語は速い」などという主張はしていないのも読めないから呆れるんだよ、妄信するあんたらを

**デフォルトの名無しさん** · 2021/11/13(土) 21:51:51.77

もっと詳しく書かれている英語版に明確に書かれていますね
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
Many programming languages require garbage collection, ...
these are said to be garbage collected languages.
Other languages were designed for use with manual memory management,
but have garbage-collected implementations available (for example, C and C++).
「多くのプログラミング言語はGCを必要としていてそれらはGC言語と言われる」
「その他の言語は手動メモリ管理で設計されたがGC実装も利用可能(例としてCとC++)」
つまりCとC++および状況が全く同じRustはGC言語ではないです

**デフォルトの名無しさん** · 2021/11/13(土) 22:03:01.49

はあ。。馬鹿馬鹿しい

**デフォルトの名無しさん** · 2021/11/13(土) 22:10:48.49

お前らの判断が遅いのは「審判は第三者でなければならない」という習慣のせいかな
自分が審判になって自分で好き放題に判断すれば早いんだが

**デフォルトの名無しさん** · 2021/11/13(土) 22:13:59.53

tracing GC の方が有利なアプリケーションって具体的に何？

**デフォルトの名無しさん** · 2021/11/13(土) 22:29:17.51

いろいろなプロセスが動かないバッチ処理なんかは逐一確保と解放を繰り返さない分だけ、調整すれば早いでしょ

**デフォルトの名無しさん** · 2021/11/13(土) 23:05:29.89

>>611がここでプロセスとか言い出してるのを見てもわかるように
GC言語が有利というトンデモ主張している人は基本的な常識知識がないようだ

**デフォルトの名無しさん** · 2021/11/13(土) 23:09:26.37

自分の間違いを認める人が全くいなくてこのスレはわけわからん

**デフォルトの名無しさん** · 2021/11/13(土) 23:10:29.14

馬鹿はほっとけ

**デフォルトの名無しさん** · 2021/11/13(土) 23:31:48.59

前提の違う話が交錯してるだけｗ言いたいやつに言わせとけばいいｗ

**デフォルトの名無しさん** · 2021/11/13(土) 23:42:47.00

>>611さんの解読
(1)バッチ処理だといろいろなプロセスが動かなくて
(2)つまりバッチ処理でなければいろいろなプロセスが動いて
(3)そしてバッチ処理でいろんなプロセスが動かなければ逐一確保と解放を繰り返さなくて
(4)逐一確保と解放を繰り返さない分だけ調整すれば早い
とおっしゃってるようだけど

(1)バッチ処理でもよくあるパイプライン式ならいろんなプロセスは動くし
(2)バッチ処理でなくてリアルタイムにストリーム処理でもプロセス一つだけもあってそもそもバッチ処理とプロセス数は関係ないし
(3)プロセス数が増えてメモリを使うことで起きうる確保と解放ならばOSによるメモリ管理とスワップの話になるし
(4)OSによるスワッピングが起きなければ起きた時より確かに実行速いのはその通りだけど
プログラミング言語によるメモリ管理やGCの話とは関係ないですね

**デフォルトの名無しさん** · 2021/11/13(土) 23:55:33.15

言いたいことを自由に言うのは良いことだよ
ただ、言われたことを全部聞く義務があると思うのは悪い

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

GCの方式の一つとして参照カウント方式があるが増減のオーバヘッドや不完全性からGCとしては少数派で主流はトレーシング方式
一方でC++/shared_ptrやRust/Rcは参照カウント方式をとっているがガベージをコレクションする形ではなく停止もなく全体が対象でもないため少なくとも通常のGCとは呼ばないかな
そのためC/C++/RustはGCのない言語と一般的に言われている
このあたりは共通認識でよいのではなかろうか

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

書き込みが多すぎてなんの前提で話をしてるのかよくわからんが、通常のGCじゃないならなんなんだ。PerlはGCじゃないのか

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

>>619
そこは日本語をちゃんと読んで欲しかった

＞参照カウント方式をとっているがガベージをコレクションする形ではなく停止もなく全体が対象でもないため少なくとも通常のGCとは呼ばないかな

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

ごめん。それでもわからんけど、Perlは参照カウント方式を使ってるんだけど、通常のGC言語ではない、ってこと？

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

>>621
ま、まじですか？
日本語で「WWWはXXX方式をとっているがYYYという状況のためZZZではない」な文章を「XXX方式はZZZでない」と解釈する人を初めて見ましたｗ

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

つまり、君は何が言いたいの？

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

意図的に歪曲して言いがかりを付けたいだけなようなのでやめときます
一般的な共通認識を>>618に書いただけです

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

ビジー状態とアイドル状態を繰り返すようなアプリはアイドル時にGCできるから有利な場合もあるのかな
shared_ptrでも実装工夫すれば同じことはできはするだろうけどめんどくさそう

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

C#も、ついに10.0まできた。
貪欲に機能を追加し、着実に進化(複雑化)しているし、最先端とは言わないけど先端を走っていると思うんだ。
もう少し評価してあげてもいいと思うんだけど、みんな興味ないの？正直Goより・・・・

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

C#はjavaと比べられる位置なので・・・興味ないというか既にみんな知ってるよね

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

まだやってたのかｗｗ
ＧＣ言語であるない論破ｗｗｗもとを見ればＧＣアルゴリズムだって言ってるけど、途中で
絶対Rustに勝てないマンがＧＣ言語ではない言い出してるが、マジどうでもいいなｗｗｗ

絶対勝てないならここを見る必要もないだろ、Rustすれでワッショイワッショイやってろ

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

C#は開発者文化を含めJava以上に単一言語で全部済ませる志向が強い言語なんだよね
実際俺も信者だったし信者ばかりの環境で仕事してたこともあって、いかにC#が優れているかはよく分かってるつもり
チームにC#を導入したら最後、他に手を出す理由を正当化することができなくなってしまい、結局つまんない職場になっちゃうんだよ
だから俺は一切C#使わないことにしてる

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

Good は Great の敵

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

>>625
C++にはGCが無いためそういうのは必要ない
shared_ptrは単なるスマートポインタで使い終わると自動的にdeleteが呼ばれるだけ
RustのRcも同じ

**デフォルトの名無しさん** · 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相当の処理を明示的に書くこと」と決定的に異なる部分だな。