次世代言語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(火) 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言語はこれをするのに各言語で苦労しているのと対照的

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

>>803
それはかなりの曲解
自動化しているのは結果として起こる「メモリ解放」
その「メモリ管理」自体は手動の範囲内だとはっきり書かれている

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

一生懸命にC++を味方に引き込もうとする姿が哀れに思える。C++は全部プログラマが気にして細心の注意を
払い神のごとくコントロールする言語なのに、一緒にされたらC++プログラマーは嫌

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

RAIIでやりくりするほうがある種スッキリしてるし
それを欲する層は居なくはならないよ

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

>>803
追加解説サンキュー。
普通はそう考えるよなぁ。

自分で引用しているのにその内容を無視するのはなぁ。
それで騙せると相手を馬鹿にしているのか、本当にそうだと幻覚でも見ているのか……

>>807
まずははっきり書かれている部分を示してくれない？確認するから。

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

>>807
>その「メモリ管理」自体は手動の範囲内だとはっきり書かれている

どこに？
どこにshared_ptrの利用は手動メモリ管理の範囲内ですってはっきり書かれてるの？
shared_ptrに言及してるのはそのページでは↓ここしかないけど？
「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. shared_ptr is not suitable for all object usage patterns, however. 」

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

>>806
goのdefer文のがよっぽど楽だと思うけどね。
デストラクタみたいにオブジェクトに紐づくのは不自然なことが多い。

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

そもそもWikipediaをソースに議論するのが間違っとる

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

実用上はGCのタイミングとやり方をプログラマが制御できるかどうかだね

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

「RustはGCじゃない！」
「え？ARCでしょ？別にどうでも良いじゃん？」
「shared_ptrがうんたら、なんちゃらで、RustのArcの”A”は自動じゃない！Wikiによると（長すぎるので省略）」
「C++やRustはスッキリ！C#のIDisposableはRustの真似！」
「？？？」
「C++を仲間に引き入れたいだけだろｗ」
「だからWikiによると（長すぎるので省略）shared_ptrは手動なんだ！うぇぇん！バーカｗ」

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

第三者目線で観ると一人で自演してるようにしか観えない

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

だろ？

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

>>812
例えばどういうケースで不自然になるの？

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

>>802は別にGC起因の問題じゃなくて単なるシンタックスの問題だろ
メモリの解放とその他のリソースの解放を、GC言語ではレイヤの異なる別の問題として扱っているだけだ
C++やRustではそのusingに相当する言語機構を用いてメモリ解放の面倒も見なければならないわけで、本質的には負担が増えている
最近のバージョンのC#では using var r = みたいな記法もできるようになって記述負荷の問題は解決したが、そういう問題じゃないんだろ？

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

copy constructor と
move constructor だな

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

そもそshared_ptr自体使わない。
new/deleteも使わない。
RAII、所有権と唱えると設計がすっきりする。

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

>>821
単独所有者限定はRustですら諦めたデザインなのに。

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

>>822
HTML5仕様のパーサー、木コンテナ、ダブル配列ベースのTRIE木コンテナ、それら木へのイテレータ/アダプター、CSS Syntax Module Lv3仕様のパーサーなど書いた結論。
new/deleteすら要らない。
偉い人が言ってることは全部ほんとだった。

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

ｗｗｗ

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

>>811
ずばりそこに書かれてる

　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 ...
　C++においては、RAIIを決定論的参照カウント方式と共に使うことで、メモリ解放を自動化するのに利用している。その他の点では手動のフレームワークの範囲内で。

ようするに自動化はあくまでも『メモリ解放』だけであって
その他の点で(otherwise)は『手動のフレームワーク』すなわちこのwikipedia項目『手動メモリ管理』の範囲内(within)だと明記されている
shared_ptrが自動でメモリ解放するのは当たり前だけどもあくまでも手動メモリ管理の範囲内ということ

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

vector、listなどSTLのコンテナは基本的なストレージとして設計されてるそうで、実際、その他のコンテナはこの上に実装できる。
tree、ダブル配列ベースのTRIE木などをこれらの上に実装して不都合は無かった。
速度的にもmap、unordered_mapなどと比較するレベルで、普通に使える。

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

イテレータを使い分けることで、終了タグが現れる行きがかり順の走査と単純な木としての走査を行える二面性を持つHTML木も作ってみた。
単純な木として走査するならDOMのように見え、HTML文書として走査するなら（タグのバランスが取れていない）壊れたHTMLも扱える。

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

うん

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

そういう作業をした結果、HTML5とは、インターネットエクスプローラーを倒すためにデザインされており、プログラミング的な合理性は全くないと理解した。
また、HTMLを簡単に扱えないようにするため、いろいろ詭弁を使いながら仕込みを行っている。
HTML5のおかげで、賢いベンチャーが現れてグーグルを倒すようなことを防げる。

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

R！A！I！I！
これですべて解決。
RAII強し。

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

>>825
メモリ解放を自動化しているならそれはGCでは？
逆にGCはそれ以外何の仕事をすると？

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

>>831
例えばunque_ptrもメモリ解放を自動化していますがGCとは呼ばれませんよね
つまりメモリ解放の自動化とGCは別のことです

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

セガサターン言語！

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

RAIIで無駄なくやりくりするのがC++の思想なんだろうね
スマートポインタもRAIIがもたらすリソース解除実行の一例で
ヒープメモリをデストラクタでdeleteしてるだけだから

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

>>831
>>832は（今までのやり取りにもある通り）悪意を持って情報を隠すから気をつけろ。

>>684以降、誰も異論を挟んでいないWikipediaの解説
ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち、
『不要になった』領域を自動的に解放する機能である。
にある通り、『不要になった』かどうかを自動的に判断するのがポイント。

自動で判断しないc++のunique_ptrはGCの機能とは言わんが、（仕様に従う限り）自動で判断するshared_ptrはGCの機能と言える。

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

>>835
またゴールポストを移動させたの？
その「自動的に判断」「自動に判断」などは今までこのスレに一度も出て来ておらず誰も主張してきていない初登場の言葉
そしてその意味の定義がなされていないから解釈次第になる

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

Rust 2021 Edition

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

だぜぇｗｗｗ

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

ちゃんと必要十分条件を考えてください

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

こいつらがプログラム作るの勘弁してほしいんだが

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

法律で禁止するべきと？

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

まだWikipediaとか不毛なことやってたのか
もうちょっとまともな文献を挙げてみると
リチャード・ジョーンズ「ガベージコレクション」
では参照カウント方式GCの具体例としてBoostのshared_ptrを取り上げて、トレーシングGCとの比較が行われている
著者はメモリ管理についての国際会議（ISMM）の創設者なので、少なくとも学会レベルではshared_ptrはGCの一形態として認識されていると考えていい
もちろん学会が世の中の全てではないから「俺の常識ではGCではない」と主張するのは自由だけど

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

激おこなの？

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

>>825
やっぱり何言っても無駄だったか

「自動だけどそれは手動の範囲内」ww

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

GCはGCまかせのタイミングでいつかきっとメモリを解放できる
RAIIはRAIIオブジェクト破棄のタイミングで※1リソース※2を解放できる

※1 shared_ptrの場合は参照カウンタを見て
※2 shared_ptrの場合はメモリを

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

shared_ptrがGCかそうでないかはどうでもいいからさ、
GCの動作有無をアプリ開発層のプログラマから制御できる次世代言語はどれよ？

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

真実は>>660
それ以上でもそれ以下でもない

**デフォルトの名無しさん** · 2021/11/18(木) 00:02:29.34

【結論】紅しょうがは無料だけど良心の範囲内！

**デフォルトの名無しさん** · 2021/11/18(木) 00:30:08.00

>>846
D

**デフォルトの名無しさん** · 2021/11/18(木) 07:15:04.87

99％のプログラマーはこんなアスペルガーの領域のことまで考えてプログラミングやってないと思う

**デフォルトの名無しさん** · 2021/11/18(木) 08:11:30.53

>>836
ゴールポストは>>684から変えてないし、まともな異論も出てない。「手動メモリ管理」とかも>684を否定しているわけではないだろ。それとも>684はデタラメと主張するのかね？
嘘ばかりの歴史改竄主義者だな。

世間一般の認識は>>842みたいだから、>836の心の中のGCについては勝手にすれば？歴史改竄しないかぎりだけど。

**デフォルトの名無しさん** · 2021/11/18(木) 08:57:24.74

キミはおそらく誰からも相手されとらんだけではｗ

**デフォルトの名無しさん** · 2021/11/18(木) 09:07:54.56

お前らが大好きなWikipediaの文言だぞ

https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

Reference counting
Main article: Reference counting

Reference counting garbage collection is where each object has a count of the number of references to it. Garbage is identified by having a reference count of zero. An object's reference count is incremented when a reference to it is created, and decremented when a reference is destroyed. When the count reaches zero, the object's memory is reclaimed.

As with manual memory management, and unlike tracing garbage collection, reference counting guarantees that objects are destroyed as soon as their last reference is destroyed, and usually only accesses memory which is either in CPU caches, in objects to be freed, or directly pointed to by those, and thus tends to not have significant negative side effects on CPU cache and virtual memory operation.

There are a number of disadvantages to reference counting; this can generally be solved or mitigated by more sophisticated algorithms

https://ja.wikipedia.org/wiki/%E3%82%AC%E3%83%99%E3%83%BC%E3%82%B8%E3%82%B3%E3%83%AC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3

スマートポインタ

なお、C言語で参照カウント方式のガベージコレクションを利用する場合、通常煩雑なコーディングを必要とするが、C++では以下のようなRAIIを活用したスマートポインタを利用することで緩和できる。

・Boost C++ライブラリのboost::shared_ptrおよびboost::shared_array。
・参照カウントの増減処理をカスタマイズできるboost::intrusive_ptrもある。
・C++11以降のstd::shared_ptr
・Active Template LibraryのATL::CComPtr - COMオブジェクトのスマートポインタ。
・Windows Runtime LibraryのMicrosoft::WRL::ComPtr - Windowsランタイムオブジェクトのスマートポインタ。COMオブジェクトにも使用可能。

**デフォルトの名無しさん** · 2021/11/18(木) 11:21:14.46

>>823
否定はしないが賛成もしない
new を出来るだけ避ける様に心がければ delete の心配が無くなるのは当たり前