次世代言語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/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
私利私欲を捨てさせることが目的のように見える
私的な目的を持たないことが目的みたいな

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

>>783
英語を読めないの？
>>769には、手動メモリ管理の有利な点としてRAIIによる自動リソース管理を可能とすることが挙げられ、C++では手動のフレームワークの範囲内でメモリ解放を自動化するshared_ptrが使われている、と書かれている
つまりshared_ptrは手動メモリ管理の代表選手

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

>>783の解釈で正しいよ
そもそも出典の記載もなく俺が書いたかもしれないwikipediaの記事にどれだけ意味があるのかは知らんが

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

>>786
ウソはよくないな
>>769には引用されていないけど
「手動メモリ管理の有利な点とし
てRAIIを可能としC++にはshared_ptrがある」の直後に
「このアプローチはGC言語(＝自動メモリ管理)では使用できない」と明記されている
shared_ptrは手動メモリ管理であることが明確になった

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

でもC++/CLIってGC言語だけどshared_ptr使えるじゃん

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

weak_ptrの存在もあれだよな
必要だったらコレ使ってなんとかしろよ？という
循環参照も自動で解放できるんならコレいらないしな

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

定義定義ってうるさいよ
何を目的としてその定義があるのかという視点から考えないからこういうコーナーケースで無用な論争に発展する

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

自演の荒らしだと思う

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

〇〇かGCか否かという議論に決着がつくと
プログラム書く上で何か役に立つんですかねえ
あるいは学術的な発展でもするんですかねえ

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

じゃあ次はお前らの大好きなNimの話でもする？
Efficient, expressive, elegant
どこがエレガントなのかどうぞ

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

>>785
それはshared_ptrの実装に手動メモリ管理の枠組みが使われているという話で
shared_ptrが提供する機能性が手動メモリ管理に分類されるとは言っていないと思うが

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

auto変数はすべてGC(キリっ)

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

allocaはGC(キリっ)

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

Garbage Collectionを持つ言語
Garbage Collectorがある言語
Garbage Collectが行える言語

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

>>785 >>787
shared_ptrは「 further use to automate memory deallocation within an otherwise-manual framework」であって、shared_ptr自体がmanual frameworkだとは言っていないけど？

文章で言うなら、「put to further use to automate memory deallocation」だからmanual frameworkの外にある機能を追加する（=manual frameworkには無い機能）と読むのが自然。

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

スレの半分はこいつでできています
http://hissi.org/read.php/tech/20211116/U2x6aVZFN1Y.html

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

>>798
そこにもあるように
あくまでも手動メモリ管理の範囲内でのメモリ解放の自動化
とはっきり書かれている
しかも手動メモリ管理のアドバンテージの説明として書かれているわけだから
shared_ptrは手動メモリ管理であってしかもそのアドバンテージ

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

不毛とハゲの違いってなんだよ？
英文持ってきて貼り付けて一仕事終えるじゃなく、自分の言葉で説明しろよ！
アドバンテージ！

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

RAIIで解放タイミングを把握できるのはメリットだね
GC標準装備言語だとそうはいかないもん
C#だとusingとIDisposableを使ってまで同じようなことをしたがるけど
using (StreamReader r = new("foo.txt")) {/*処理*/}

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

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

おいおい・・・
無駄かもしれんが一応書いておく

まず大前提として1行目に
「In computer science, manual memory management refers to the usage of manual instructions by the programmer to identify and deallocate unused objects, or garbage. (手動メモリ管理というのは使われなくなったオブジェクト(ガベージ)を識別してメモリを解放するのにプログラマーが手動命令を使用することを指す)」と書いてある
つまりはここで言う手動メモリ管理はどのオブジェクトを解放すべきかを判断するコードやメモリを解放するコード(freeやdelete)をプログラマーが直接書くことを意味してる

でもってRAIIの説明箇所にある「This can also be used with deterministic reference counting.(RAIIは決定的参照カウント方式と一緒に使うこともできます)」は”手動メモリ管理だけでなく参照カウント方式とも一緒に使える”と言ってるわけ

「In C++, this ability is put to further use to automate memory deallocation within an otherwise-manual framework」(C++ではこの機能を、その他の点では手動のフレームワークにおいて、メモリの解放を自動化するのに活用している)
otherwise-manual frameworkと書いてることからわかるようににC++が活用してる内容は”自動”の範疇に含まれると記事の書いた人間は考えてる

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

>>798
かぶったな
でも真っ当な理解ができる人がいてよかった

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

外部DLLに渡すヒープデータなんて普通にコントロールするのが当たり前、GC”非標準装備”言語だってそう
じゃなければDLLを起点にクラッシュする。おまえほんとはなにもしらねーんじゃねえの（笑）ｗ
C#だって当然そういう事を考えるだろう、アホ信者言語と同じことをしたいんじゃない

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

>>802
だな
C++やRustなどは即座に解放のためデストラクタでファイルcloseやlock解放を自動化できてプログラマーは気にしなくて済むもんな
GC言語はこれをするのに各言語で苦労しているのと対照的