次世代言語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/12(金) 00:06:01.94

Prologが分かる奴はErlangもRustも分かるから早急に次世代に行けた

**デフォルトの名無しさん** · 2021/11/12(金) 02:10:18.26

prologなんて誰も使ってなかったよｗ

**デフォルトの名無しさん** · 2021/11/12(金) 14:30:35.33

>>579
それ、何てOz？
Oz触ったこと無いけど。

**デフォルトの名無しさん** · 2021/11/12(金) 14:41:26.85

swi-prologなら若干拡張されてるけど、prolog自体が昔からほぼ使われておらず
存在自体あまり知られてないし、結局手続き的思考が必要だし、用途が限定される使いにくい言語だと俺は思ってるｗ

**デフォルトの名無しさん** · 2021/11/12(金) 14:59:17.99

調べてみるとICOTとかいう、Prologをメインに使って、500億円も予算をかけたプロジェクトがあったらしいけど、なんだったんだろうな

**デフォルトの名無しさん** · 2021/11/12(金) 21:33:34.72

第五世代コンピューターと論理プログラミングを基にした現代の深層学習とは違う人工知能・・・ウッ頭が
つまりはアランケイのSmalltalkが最強ってことだろ？

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

コストが高いか安いかでくるくる掌返すのはポジショントークだよな
しかもサンクコスト

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

Prologは夢を見すぎたな
結局バグは仕様そのものとかいろんな理由で起きるというのに

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

メモリ安全みたいなテーマに限定すれば夢が無限に大きくはならんだろ
夢を見たことではなくテーマを表す言葉を使わなかったことを反省しよう

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

ループをすべて再帰で書くというのがちょっと難しいが
デバグが楽だし、保守もしやすい
ライブラリをどさっと作れば流行ったかもしれないな
のちのperl,javaのように

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

>>589
末尾再帰ループ化できない再帰はスタックが溢れる
最近はループを更にわかりやすくイテレータ連鎖で書くのが主流だね

>>588
Rustの発想は目からウロコだった
他の言語たちが最初からガベージコレクション前提にしてた状況でGCなし言語があそこまで出来るとは驚き

>>587
論理宣言型言語は結局は現実のCPU命令手続きとのギャップを処理系でカバーするも効率面も厳しく

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

また過大評価してGC無しなんて言うけど理論上は参照カウントはGCアルゴリズムだし、そんなのは原始的で
最も基本のGCに分類される。仮にこれから今のRc系のGCに参照カウントGCの非同期が搭載されたりすれば
その動作はスイープマーク系や世代別GCに近くなる。（その可能性は少ないが）現在なぜ良い結果が出るかと
いえば構造上、連鎖的な多量GCが少なくなるために、スループットが高くなる事だけ。
レテンシーで見ればJavaやC#のGoなどの処理は毎回GCするとは限らないので、その分だけ処理が速い

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

君、頭悪いでしょ

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

末尾呼び出し最適化が保証されてる言語でのみ
枕を高くして再帰で書きまくれるというもの
ocamlはいいぞ

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

>>591
まずほとんどのデータは参照カウントで管理しないから極一部のケース対象にしか論じていないね
次に参照カウントゼロ時に即座に解放する場合はガベージが一度も発生しないためガベージコレクションとは通常言わないです
最後に列挙しているGC言語はC/C++/Rustよりもベンチマークでも遅いですね

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

末尾再帰はプログラミングテクニックではなく、コンパイラ等におけるコード最適化の技術です。
（多くは手続き言語における自己呼び出しをTailに変形してスタック消費をゼロにしたりする）

「ループを再帰で書く」まったく意味ないどころか、言語問わず末尾再帰最適化が未実装のコンパイラ等では
弊害しかありません。「イテレータ連鎖？で書く」は普通のループ大きく変わりませんが、言語によりけりで
手続き言語では非同期処理やサイドエフェクトのある処理では上手く書けません。

そもそもPrologの一階述語論理における再帰処理というのは再帰定義自体が、関数型プログラミングの元と
なる論理型プログラミングで、多くの普及している手続き言語のような弊害がないために成り立つだけです。

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

>>594
(1)多くの言語のデータ管理はヒープとスタックです。スタックには（よほど特殊なOSでない限り）違いがありません。

(2)「参照カウントゼロ時に即座に解放する場合」意味のある日本語で書きましょう、開放すると言っておきながら
ガベージが無いといったり、RustであればRc<T>やArc<T>で参照カウントゼロ時は確保してないということです。

(3)「ベンチマークでも遅い」例えばCPUのベンチマークだって幾つも項目がありますが、その中のスループットは
高い（near =早い）と言っているのです。一方でレテンシーは遅いのです。

なぜそんなに強引に推し通したいのか、理解不能です。

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

ベンチマークの数値ってもうRustのコンパイルエラーと同じぐらい意味不明と思われてるね
Prologさんを500億の言語にしても誰もほめてくれないし

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

GCなければキャッシュの効果は高くなりそうだけどねｗ

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

>>596
おそらくC++やRustを使ったことがないのだろうけどC++のshared_ptrやRustのRc Arcを使うのは所有者が複数になる特殊ケースのみ
それらのみが参照カウンタを用いるけど所有者がいなくなった時点で自動的にリソース解放される
これをGCと呼ぶ人はいない
もちろんそれ以外のケースは参照カウンタも使わずに解放される
そのためGC言語は原理的にどうやってもCやC++やRustに勝つことはできない

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

特殊な界隈でそういう習慣があるのか知らんが
参照カウンタは普通にGCの実装方式の一つと
言われてるだろ

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

末尾再帰ができないのをループで書いても
スタックがあふれるけど

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

例えば、ベンチマーク時間が30秒だとして、どれだけ回数を多く実行できるかがスループットであり
gcのあると言われる言語の中でgcの時間/頻度を調整できるものは30秒gcをしなければ、余計な処理が
走らないために数値が当然高くなる。もちろん処理中に使用メモリが常に増大して終了時のみに解放を
するため整合性のある説得力のあるベンチマークとは言いませんが、特定の処理に限ってメモリーが
溢れないのであれば、十分に取りうる選択肢です。

そして1msが致命的となるような処理では重要ですが特定桁までPIを求めたりフィボナッチ数列の処理
時間を計測したり、あんまり意味がないですね
多くは最適化がどこまでなされているか、配列などの範囲チェックなどのランタイムチェックが足枷に
なっているか、などが違うだけで言語的な特性だとは言いません。

上のほうでshared_ptrなんて持ち出してバカ言ってる人がいるけど言語は適用範囲が違えば有利な分野が
違います。「勝つ」なんて、Cなんて基本は配列などの範囲チェックなんかはやってないわけで原理的な
説明に１つもなってません。CとRustを同列に並べることがどうかしてる、Rustは範囲チェックなどは
安全な言語として当然やってるわけでRustだってアロケーションは他のgcの言語と同じく従来はjemallocで
今は違いますが確保と解放がセットになっている事が、今は有利に働いているが、将来的にはそうだという
確信はありません。そうでなければgcの研究なんて見捨てられるでしょう

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

またGCの定義をmalloc/freeとreference countとtracing GCの3つの間でお手玉して好き放題言う流れか

**デフォルトの名無しさん** · 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するだけのコンテナに対してだ