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

**デフォルトの名無しさん** · 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強し。