次世代言語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(火) 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 の心配が無くなるのは当たり前

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

>>846
node.js

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

>>823
newを使わない要らないとはヒープを一切使わないという意味ですか？
それともC言語のように自分でmalloc等を用いてヒープメモリ管理を行うべきという意味ですか？
前者はそれら挙げている物のプログラミングが不可能だから後者の何十年も前に戻っただけですか？

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

>>856
C++の標準ライブラリにあるstd::string、コンテナクラス、unique_ptr、shared_ptrなどを使っていればnewを書かずにヒープメモリを使うことができるし、shared_ptr以外はスコープを抜けたときに自動的にデストラクタを呼んでヒープを解放してくれる。
ちゃんとC++を使えばほとんどの場合手動でメモリ解放せずに済むよ。

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

>>856
それはRAIIを判ってない発言だからたぶん恥ずかしい

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

>>857
コンテナの中身がポインタだったら？

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

本人も認めてるけどRAIIってネーミングセンスがないよな

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

>>856
この辺見るといいと思う
https://www.youtube.com/watch?v=86xWVb4XIyE&;t=1790s

shared_ptrがGCの一種って話も出てくる

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

>>857
しかし元の方は>>821でdeleteを使わないだけでなくshared_ptrも使わないとおっしゃっているのです
つまり解放をどうするのか問題が残ります
あとコンテナ自体の解放に加えて要素が値だけで構成されずポインタを含む場合はその先の解放も必要ですよね

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

>>858
ある程度の構造を持ったデータを扱う場合
RAIIではそのクラスのデストラクタでdeleteが発生しますよね？
>>823はdeleteも要らないと書いていますがそこはどうするのでしょう？

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

new/deleteを明記しないってだけやろ

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

golangなんかだとbenchでB/opやallocs/opが取れるけど、他の言語はあまりメモリー量は重要視してないのかな？
最終的にはエネルギー毎のjoule/opとか出してほしいけど、IntelとAMDそしてARMで全然違うのはCOP21とかは
何も考えてない偽善だろう

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

>>862
所有権について言及してるしunique_ptrを使うのでしょう

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

流れを踏まえると
C#はせっかくGCがあるのに
自分でいちいち手動のDisposeを描かされる

残念な言語(キリっ

と言わざるを得ない

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

GoやJavaなんかだとGCがあるからやばい、って思えるほどシビアなプロジェクトの開発をしてみたいもんだ

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

>>863-864
デストラクタ内のdeleteは勘定に入れなくて良いルールなんだろう

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

>>867
というより可能な限りGCを動かさないように
値型を多用してコレクションも
System.Collectionsじゃなくて
System.Collections.Genericのほうを使うとかして
ヒープ側を使わないようにする悲しい頑張りが必要

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

まあ、ネイティブコンパイラが必須なケースが少ないからこそ
JavaScriptインタプリタのようなものをC++やRustで書いて使ってるんだよな

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

>>870
C#ならガベージの生成を避けるようなケースでもC++なら気にせずヒープ使いまくれるってことか？
そうでないならそれはGCの問題ではないことになるぞ