スレタイ以外の言語もok
前スレ
次世代言語21 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1587276362/
次世代言語22 Go Nim Rust Swift Kotlin TypeScript
■ このスレッドは過去ログ倉庫に格納されています
2021/08/22(日) 08:59:03.31ID:QorwbXcj
654デフォルトの名無しさん
2021/11/15(月) 10:59:52.82ID:VyWPF7Kj 争いの原因は多様性ではなく
テンプレ化した標準的な決まり文句なんだよ
テンプレ化した標準的な決まり文句なんだよ
655デフォルトの名無しさん
2021/11/15(月) 11:17:46.17ID:A0Oqbbcg なんか変なこと言われてたような気がしたけど、Perlは参照カウンタ方式のGCを採用した言語だよ
656デフォルトの名無しさん
2021/11/15(月) 11:36:02.99ID:EiiKCwr/ 「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).
=========
===引用===
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).
=========
657デフォルトの名無しさん
2021/11/15(月) 12:56:43.04ID:1YFhL4pj658デフォルトの名無しさん
2021/11/15(月) 13:03:44.58ID:0QQJPtP8 garbage collectionを実行するのがプログラマなのかgarbage collectorなのかというだけの話だな
プログラマから見てgarbage collectionが完全に隠蔽されているなら、
参照カウント方式だろうと何だろうと、もはやどこかにgarbage collectorなるものが存在していると考えていいだろう
C++のスマポはプログラマが意識しなくていいという程ではないからふつうgarbage collectorとは呼ばない
プログラマから見てgarbage collectionが完全に隠蔽されているなら、
参照カウント方式だろうと何だろうと、もはやどこかにgarbage collectorなるものが存在していると考えていいだろう
C++のスマポはプログラマが意識しなくていいという程ではないからふつうgarbage collectorとは呼ばない
659デフォルトの名無しさん
2021/11/15(月) 13:23:45.49ID:aBLKVvRB 参照カウンタはgcでは無い、ということにすると
なんか技術的な発展あるの？
なんか技術的な発展あるの？
660デフォルトの名無しさん
2021/11/15(月) 14:49:22.20ID:5AOSdK5N gcの実装手段の1つとして参照カウンタはある
しかし参照カウンタだからといってgcということにはならない
それだけｗ
しかし参照カウンタだからといってgcということにはならない
それだけｗ
661デフォルトの名無しさん
2021/11/15(月) 14:52:33.47ID:I69rZ/Of コア言語レベルだと、GCのある言語/無い言語って区分は正確じゃなくて
手動でメモリ管理しなくていい言語/しないといけない言語
っていうのが正しいよね
手動管理しないといけない言語でも、ライブラリのサポートによって部分的にGCまかせにすることはできる
その場合でもGCを使う選択だけはプログラマが明示的に行う必要がある
手動でメモリ管理しなくていい言語/しないといけない言語
っていうのが正しいよね
手動管理しないといけない言語でも、ライブラリのサポートによって部分的にGCまかせにすることはできる
その場合でもGCを使う選択だけはプログラマが明示的に行う必要がある
662デフォルトの名無しさん
2021/11/15(月) 14:58:20.09ID:VwWTxToJ >>659
純粋な参照カウント方式のみでは循環参照に対応することができず、一般にGC付きの言語とされているもので参照カウント方式を採用している言語は、それ以外にマークアンドスイープなどで循環参照が起きた場合それら自身以外から（プロセスのRootから連鎖的に）指されていないことを見つけ出して削除する方法を併用している
これを行わない場合、つまりC++のshared_ptrなどの例の場合は、適宜手動でweak_ptrを用いるなどして循環参照が起きないようにプログラマが管理するか、プロセスが終わるまで循環参照が残存する事を許容する必要がある
従って参照カウント方式そのものをGCでないということにすると、完全に自動化されているGCを考える場合は、その循環参照への対処に対する+αの手法が何かというところに重点が置かれるし、その+αが弱参照のような手動の手法である場合、メモリ管理が完全には自動化されていないという点でGCでないと線引きする事ができる
と、私は認識している
間違いがあったら有識者は叩いてくれ
純粋な参照カウント方式のみでは循環参照に対応することができず、一般にGC付きの言語とされているもので参照カウント方式を採用している言語は、それ以外にマークアンドスイープなどで循環参照が起きた場合それら自身以外から（プロセスのRootから連鎖的に）指されていないことを見つけ出して削除する方法を併用している
これを行わない場合、つまりC++のshared_ptrなどの例の場合は、適宜手動でweak_ptrを用いるなどして循環参照が起きないようにプログラマが管理するか、プロセスが終わるまで循環参照が残存する事を許容する必要がある
従って参照カウント方式そのものをGCでないということにすると、完全に自動化されているGCを考える場合は、その循環参照への対処に対する+αの手法が何かというところに重点が置かれるし、その+αが弱参照のような手動の手法である場合、メモリ管理が完全には自動化されていないという点でGCでないと線引きする事ができる
と、私は認識している
間違いがあったら有識者は叩いてくれ
663デフォルトの名無しさん
2021/11/15(月) 14:58:31.40ID:OV4818+l >>645
プログラマーの視点からはその(1)(2)(3)の3つともGCではないな
C++言語仕様的にその3つは全く同様にdeleteで配列でもクラスのインスタンスでもメモリ回収されていく
だから参照カウンタを用いているshared_ptrだけGCだとの主張にも実態との大きな乖離があり違和感がある
GC派の人は以上の点をどう捉えている？
プログラマーの視点からはその(1)(2)(3)の3つともGCではないな
C++言語仕様的にその3つは全く同様にdeleteで配列でもクラスのインスタンスでもメモリ回収されていく
だから参照カウンタを用いているshared_ptrだけGCだとの主張にも実態との大きな乖離があり違和感がある
GC派の人は以上の点をどう捉えている？
664デフォルトの名無しさん
2021/11/15(月) 15:10:31.33ID:U/bVngDM >>636
GCの未来を考えると、確かに、特定のアプリケーション領域に特化したメモリー確保やアライメントがあるわけで
tcmallocやhoardが低スレッド数では明らかにglibなどのmallocより速い事は、現状のシンプルな参照カウントが
絶対的に有利とはいえないね。GCであるない分類なんてどうでも良い話だわ
ちょっと前の話で出てきたUnity3Dで構築済みのオブジェクトをキャッシュして使いまわしパラレルGC（もっと
言えばS.T.W)を発生させないというテクニックも一歩前に進んで考えれば、都度のメモリー確保と破棄の時間を
省略し、さらに進めば複雑なオブジェクト構築に掛かる時間も部分的には省略可能なわけで、そこまでGC実装が
手が届くかはまだ疑問が多いが、今コンパイラにある最適化して実行速度を速めるフラグにはあまり使われない
バイナリーを小さくするトレードオフなフラグがあるが、メモリー効率を無視してより実行速度を高めるような
最適化を行うことを行いだしても不思議ではない。C系のコンパイラだとシステムコールや標準ライブラリには
厳密な意味があるのでメモリーの事前確保は難しいかもしれないが、他の言語でよくあるList構造なんかでは
それが必ずメモリー確保を必ず同期的に行うとは深く言及していない言語は、そのような道をたどるかもしれない。
tcmalloc/jemallocなんかもメモリプールを随分前に導入しているしね
GCの未来を考えると、確かに、特定のアプリケーション領域に特化したメモリー確保やアライメントがあるわけで
tcmallocやhoardが低スレッド数では明らかにglibなどのmallocより速い事は、現状のシンプルな参照カウントが
絶対的に有利とはいえないね。GCであるない分類なんてどうでも良い話だわ
ちょっと前の話で出てきたUnity3Dで構築済みのオブジェクトをキャッシュして使いまわしパラレルGC（もっと
言えばS.T.W)を発生させないというテクニックも一歩前に進んで考えれば、都度のメモリー確保と破棄の時間を
省略し、さらに進めば複雑なオブジェクト構築に掛かる時間も部分的には省略可能なわけで、そこまでGC実装が
手が届くかはまだ疑問が多いが、今コンパイラにある最適化して実行速度を速めるフラグにはあまり使われない
バイナリーを小さくするトレードオフなフラグがあるが、メモリー効率を無視してより実行速度を高めるような
最適化を行うことを行いだしても不思議ではない。C系のコンパイラだとシステムコールや標準ライブラリには
厳密な意味があるのでメモリーの事前確保は難しいかもしれないが、他の言語でよくあるList構造なんかでは
それが必ずメモリー確保を必ず同期的に行うとは深く言及していない言語は、そのような道をたどるかもしれない。
tcmalloc/jemallocなんかもメモリプールを随分前に導入しているしね
665デフォルトの名無しさん
2021/11/15(月) 15:22:07.43ID:A0Oqbbcg >>662
Perlに限っていうと、参照カウント式のGCしかなくて、循環参照を自動で削除するような方法は併用されていません
よって、おっしゃるようにプログラマが弱参照を使ってくれないとメモリリークが簡単に起きます
でもPerlもGC言語の仲間に入れてください。お願いします
Perlに限っていうと、参照カウント式のGCしかなくて、循環参照を自動で削除するような方法は併用されていません
よって、おっしゃるようにプログラマが弱参照を使ってくれないとメモリリークが簡単に起きます
でもPerlもGC言語の仲間に入れてください。お願いします
666デフォルトの名無しさん
2021/11/15(月) 15:26:35.98ID:5AOSdK5N まあgcは自力で実装できるしね
667デフォルトの名無しさん
2021/11/15(月) 15:34:27.74ID:Yv2HsXEI Rust 使っとけばオケという事でオケ？
668デフォルトの名無しさん
2021/11/15(月) 15:35:25.23ID:OV4818+l >>665
Perlは全てが参照カウンタでありプログラマーはそれを意識することなく回収されていくから明確にGC
一方でC++やRustは基本的に参照カウンタは用いておらずプログラマーは複数所有になる時のみ意識してshared_ptrやRcを用いており回収される時には付加動作もプログラミング可能だからGCではない
Perlは全てが参照カウンタでありプログラマーはそれを意識することなく回収されていくから明確にGC
一方でC++やRustは基本的に参照カウンタは用いておらずプログラマーは複数所有になる時のみ意識してshared_ptrやRcを用いており回収される時には付加動作もプログラミング可能だからGCではない
669デフォルトの名無しさん
2021/11/15(月) 15:47:49.42ID:A0Oqbbcg せやな
670デフォルトの名無しさん
2021/11/15(月) 15:49:13.29ID:+RUh9SHS >>664
まあメモリーの少ない環境で処理のピークとなるようなメモリー確保を行うのは迷惑かもしれんが、現状だって
多くのアロケーターはvec![1, 2, 3]やmake([]int,5)としても断片化させないために2^Nの確保を行うからね。
逆を言えばメモリーの使用量効率が圧倒的に（現在の理論の範囲では）良いのはRust/C++だろうけども使用量が
ピークに耐えうる環境で無ければ、実行できないか例外やパニックになり目的の動作を達成しえないわけで
逐次の動的確保と解放を完全否定するものではないが、アロケータのメモリープールは実装され実証されていて
GCというか確保と解放をプログラミングから切り離す事は正常な発展の道だとも思える
GCであるないの話はお気に入りの特定の言語でそう呼ばれたくない人がいるだけで、それを全員認めて広く世に
一般化がなされても自己満足以外に何か得られるようなものではない
まあメモリーの少ない環境で処理のピークとなるようなメモリー確保を行うのは迷惑かもしれんが、現状だって
多くのアロケーターはvec![1, 2, 3]やmake([]int,5)としても断片化させないために2^Nの確保を行うからね。
逆を言えばメモリーの使用量効率が圧倒的に（現在の理論の範囲では）良いのはRust/C++だろうけども使用量が
ピークに耐えうる環境で無ければ、実行できないか例外やパニックになり目的の動作を達成しえないわけで
逐次の動的確保と解放を完全否定するものではないが、アロケータのメモリープールは実装され実証されていて
GCというか確保と解放をプログラミングから切り離す事は正常な発展の道だとも思える
GCであるないの話はお気に入りの特定の言語でそう呼ばれたくない人がいるだけで、それを全員認めて広く世に
一般化がなされても自己満足以外に何か得られるようなものではない
671デフォルトの名無しさん
2021/11/15(月) 15:58:26.75ID:g6hTEDoE Perlは循環参照だめなのか
そりゃ廃れるわ
そりゃ廃れるわ
672デフォルトの名無しさん
2021/11/15(月) 16:04:42.57ID:+RUh9SHS RustもSwiftも循環参照はダメだぞ
673デフォルトの名無しさん
2021/11/15(月) 16:13:30.50ID:OV4818+l674デフォルトの名無しさん
2021/11/15(月) 16:34:13.53ID:OV4818+l >>672
CでもC++でも循環参照は当然起きるけど何を問題にしている？
所有者の概念のある諸言語は所有権を持たない弱参照が必ずあるので困ることはない
同時に生ポインタがある諸言語は自分で管理することも可能
そこがGC言語との大きな違い
CでもC++でも循環参照は当然起きるけど何を問題にしている？
所有者の概念のある諸言語は所有権を持たない弱参照が必ずあるので困ることはない
同時に生ポインタがある諸言語は自分で管理することも可能
そこがGC言語との大きな違い
675デフォルトの名無しさん
2021/11/15(月) 16:35:06.88ID:rXstoGa9 >>673
ちゃんと元読んでます？ハードウェア寄りのOSやドライバーを書く言語では、厳密性が求められるだろうから
実際に確保しない/実際には開放しないなんて許されないだろうけど、C言語でも数あるアロケーターはfreeで
実際には使われていないマーキングだけが行われる事もある。そしてfreeでOSに返却した場合でも、OS自体が
コンパクションの動作を行うなどはGCであるとは言えないが、GCのような動作を行う。何が違うかといえば
アプリケーションが関与してないだけであり、重要なのはCPUは使用されるという事であり無駄を省くという
観点からいえば、GCという枠を超えメモリー管理は特化した最適化が行えるだろうという話
ちゃんと元読んでます？ハードウェア寄りのOSやドライバーを書く言語では、厳密性が求められるだろうから
実際に確保しない/実際には開放しないなんて許されないだろうけど、C言語でも数あるアロケーターはfreeで
実際には使われていないマーキングだけが行われる事もある。そしてfreeでOSに返却した場合でも、OS自体が
コンパクションの動作を行うなどはGCであるとは言えないが、GCのような動作を行う。何が違うかといえば
アプリケーションが関与してないだけであり、重要なのはCPUは使用されるという事であり無駄を省くという
観点からいえば、GCという枠を超えメモリー管理は特化した最適化が行えるだろうという話
676デフォルトの名無しさん
2021/11/15(月) 16:47:58.36ID:OV4818+l >>675
そこは明確にレイヤーが異なる
(1)OSからシステムコールでヒープ領域の大きさを変更するレイヤー
(2)確保されているヒープ領域の中を管理するレイヤー
(3)GCやデストラクタ等でプログラムから利用された部分をヒープ領域に戻すレイヤー (逆の確保も含む)
今回行われているGCの件は(3)の話
そこは明確にレイヤーが異なる
(1)OSからシステムコールでヒープ領域の大きさを変更するレイヤー
(2)確保されているヒープ領域の中を管理するレイヤー
(3)GCやデストラクタ等でプログラムから利用された部分をヒープ領域に戻すレイヤー (逆の確保も含む)
今回行われているGCの件は(3)の話
677デフォルトの名無しさん
2021/11/15(月) 16:51:08.56ID:OV4818+l678デフォルトの名無しさん
2021/11/15(月) 16:52:32.87ID:u/x8IP+K >>676
あなたがしたい話をしている場ではありません。全く１つも理解していないのに絡んで来ないでください。
私は所有者だの弱参照だの話してませんし正常に話す気が１つもない人を相手にするつもりはありません
あなたがしたい話をしている場ではありません。全く１つも理解していないのに絡んで来ないでください。
私は所有者だの弱参照だの話してませんし正常に話す気が１つもない人を相手にするつもりはありません
679デフォルトの名無しさん
2021/11/15(月) 17:18:38.26ID:0t2kAlwU Swiftは何でもそろってるので何でも対応可能
strong参照
weak参照
unowned参照
UnsafePointer
UnsafeMutablePointer
UnsafeRawPointer
UnsafeMutableRawPointer
UnsafeBufferPointer
UnsafeMutableBufferPointer
UnsafeRawBufferPointer
UnsafeMutableRawBufferPointer
AutoreleasingUnsafeMutablePointer
OpaquePointer
などなど
strong参照
weak参照
unowned参照
UnsafePointer
UnsafeMutablePointer
UnsafeRawPointer
UnsafeMutableRawPointer
UnsafeBufferPointer
UnsafeMutableBufferPointer
UnsafeRawBufferPointer
UnsafeMutableRawBufferPointer
AutoreleasingUnsafeMutablePointer
OpaquePointer
などなど
680デフォルトの名無しさん
2021/11/15(月) 17:52:45.80ID:ZplVgP5c スマートポインタをGCであるということにして
誰がどう嬉しいんだろう？
持ったポインタをデストラクタでdeleteするだけのコンテナに対してだ
誰がどう嬉しいんだろう？
持ったポインタをデストラクタでdeleteするだけのコンテナに対してだ
681デフォルトの名無しさん
2021/11/15(月) 19:53:26.70ID:VyWPF7Kj こうすれば嬉しいという理想よりも
どうしようもない現実の方を重視する人もいるかもしれない
どうしようもない現実の方を重視する人もいるかもしれない
682デフォルトの名無しさん
2021/11/15(月) 20:12:28.41ID:Xr7xQZWT 循環参照OKな言語ってあるの？
683デフォルトの名無しさん
2021/11/15(月) 20:20:40.01ID:SRkaJxph >>680
>GCであるないの話はお気に入りの特定の言語でそう呼ばれたくない人がいるだけ
辛辣www
ほとんどの人は興味ないが、某お気に入り言語の一部の狂信者が、同じく参照カウントのSwiftはGCと
言われるのに、お気に入りの言語はそう呼ばれくなくて信者を増やしたんだろう？そんなことで集めた
信者なんて役に立たないどころか稚拙なコードの手直しをすることになりかねないのにね
公式がそのような文言で宣伝してるから、ある意味では勅命とか聖戦みたいなもんだな
>GCであるないの話はお気に入りの特定の言語でそう呼ばれたくない人がいるだけ
辛辣www
ほとんどの人は興味ないが、某お気に入り言語の一部の狂信者が、同じく参照カウントのSwiftはGCと
言われるのに、お気に入りの言語はそう呼ばれくなくて信者を増やしたんだろう？そんなことで集めた
信者なんて役に立たないどころか稚拙なコードの手直しをすることになりかねないのにね
公式がそのような文言で宣伝してるから、ある意味では勅命とか聖戦みたいなもんだな
684デフォルトの名無しさん
2021/11/15(月) 20:35:30.27ID:1YFhL4pj685デフォルトの名無しさん
2021/11/15(月) 21:05:38.94ID:VIw7Bjxz 近頃の言語でGCのタイミングをプログラムから制御できるのはないの?
686デフォルトの名無しさん
2021/11/15(月) 21:07:57.52ID:mUBmyW6D スマートポインタはGCではないということにして
誰がどう嬉しいんだろう？
誰がどう嬉しいんだろう？
687デフォルトの名無しさん
2021/11/15(月) 21:08:32.33ID:0t2kAlwU >>684
>>ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する機能である
それだけだとC++(11以降)もSwiftもRustもGC言語ということになってしまいます
だからその定義が不十分なんだと思います
>>ガベージコレクションとは、コンピュータプログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する機能である
それだけだとC++(11以降)もSwiftもRustもGC言語ということになってしまいます
だからその定義が不十分なんだと思います
688デフォルトの名無しさん
2021/11/15(月) 21:21:58.47ID:PbjRD0ud >>687
いや、それはGCの定義なんだから十分だろう
不足してるとするなら「GC言語」の定義
まぁ言語機能にGCが組み込まれてるならGC言語で
ライブラリとして実装されてるだけ（C++やRust）はGC言語ではないって感じだと思うが、正確な定義は知らん
いや、それはGCの定義なんだから十分だろう
不足してるとするなら「GC言語」の定義
まぁ言語機能にGCが組み込まれてるならGC言語で
ライブラリとして実装されてるだけ（C++やRust）はGC言語ではないって感じだと思うが、正確な定義は知らん
689デフォルトの名無しさん
2021/11/15(月) 21:28:35.39ID:VyWPF7Kj >>685
参照されなくなったポインタをデストラクタに渡したらデストラクタ内で参照される
デストラクタ内でポインタを復活させるようなコードを容認するとGCの性能がどんどん下がる
だからGCの性能を上げたい言語にはデストラクタ機能がないのが合理的
参照されなくなったポインタをデストラクタに渡したらデストラクタ内で参照される
デストラクタ内でポインタを復活させるようなコードを容認するとGCの性能がどんどん下がる
だからGCの性能を上げたい言語にはデストラクタ機能がないのが合理的
690デフォルトの名無しさん
2021/11/15(月) 22:06:51.83ID:a8RVVDGO >>685
Golangは、SetGCPercent(-1)でスタートさせてruntime.GC()を手動で呼び出す事は可能らしい。Java系というか
JVMだとSystem.gc()というものがあるが、これは確実にGCを行うわけでもなくて提案なのであまり意味がない。
Java11ではno-op garbage collectorが-XX:+UseEpsilonGCが実装された。いわゆる上のほうで書いてあるような
短期間で直線的な定量のメモリで終わるバッチのようなプログラム用だが・・・
C#というか.NETだとSystem.GC.Collect()とか、GC.TryStartNoGCRegion()でGCを動かさない指定ができる。
SwiftはARCが強制でもないのでGCを自作すれば…できる
Golangは、SetGCPercent(-1)でスタートさせてruntime.GC()を手動で呼び出す事は可能らしい。Java系というか
JVMだとSystem.gc()というものがあるが、これは確実にGCを行うわけでもなくて提案なのであまり意味がない。
Java11ではno-op garbage collectorが-XX:+UseEpsilonGCが実装された。いわゆる上のほうで書いてあるような
短期間で直線的な定量のメモリで終わるバッチのようなプログラム用だが・・・
C#というか.NETだとSystem.GC.Collect()とか、GC.TryStartNoGCRegion()でGCを動かさない指定ができる。
SwiftはARCが強制でもないのでGCを自作すれば…できる
691デフォルトの名無しさん
2021/11/15(月) 22:07:26.02ID:9V9ekymj692デフォルトの名無しさん
2021/11/15(月) 22:14:38.76ID:ZplVgP5c 自動的ってとこに着目できるかもな
スマポをプログラマが手動で使うのに
自動的に開放とはこれいかに
ガベコレ言語がもたらす本当の自動を知っているプログラマなら
スマポはあくまで手動にすぎない
内部でdeleteをしてるコンテナを使ってるだけにすぎない
スマポをプログラマが手動で使うのに
自動的に開放とはこれいかに
ガベコレ言語がもたらす本当の自動を知っているプログラマなら
スマポはあくまで手動にすぎない
内部でdeleteをしてるコンテナを使ってるだけにすぎない
693デフォルトの名無しさん
2021/11/15(月) 22:17:50.89ID:9V9ekymj >>688
そりゃそうだ。「GC言語」のまともな定義なんて無いからな。整理しようとするレスも無視しているしな。
定義も無いまま同意構築もしないまま、擬似問題をグルグル繰り返しているだけ。
しかも自分のお気に入り言語を擁護するために、何回も何回も何回も繰り返し引っ張り出すから腹立たしい。
そりゃそうだ。「GC言語」のまともな定義なんて無いからな。整理しようとするレスも無視しているしな。
定義も無いまま同意構築もしないまま、擬似問題をグルグル繰り返しているだけ。
しかも自分のお気に入り言語を擁護するために、何回も何回も何回も繰り返し引っ張り出すから腹立たしい。
694デフォルトの名無しさん
2021/11/15(月) 22:27:16.63ID:9V9ekymj >>692
プログラマが「いつ」スマートポインタの参照先のリソースを手動で解放する操作をするのか説明してもらえませんか？
「スマートポインタ」が分かりづらいというなら、c++の「shared_ptr」でいいですよ。
プログラマが「いつ」スマートポインタの参照先のリソースを手動で解放する操作をするのか説明してもらえませんか？
「スマートポインタ」が分かりづらいというなら、c++の「shared_ptr」でいいですよ。
695デフォルトの名無しさん
2021/11/15(月) 22:31:47.59ID:5AOSdK5N 正直定義なんてどうでもいいと思うんだが・・・
伝わればいいと思う
伝わればいいと思う
696デフォルトの名無しさん
2021/11/15(月) 23:07:31.08ID:ESQg0oe1 >>682
ARCだけじゃなければ循環参照を回収するサイクルコレクターが動くので、OKというか循環参照全体を参照する
変数が消えれば消える。ARCの強参照は当然ながら連鎖的には消えない。
これがよく言うARCのメモリーリークでSwiftやObjective Cで起こる現象、親の所有者が消えたのだから内部で
参照しあっていても消えると考えてしまう。サークルを作らず直線状なデーターやツリー上のデーターならば
連鎖的に消える。
ただし、サイクルコレクターがある場合でもグローバル変数になっている場合には終了時のすべての変数が寿命を
迎えるだけなのでそこで壮大なメモリー解放が起こる（これを指して意味がなく壮大な無駄だという人もいるが）
そして、SIGTERMを送ってもなかなか終了しないプログラムは一生懸命メモリー解放を行っていたりする
ARCだけじゃなければ循環参照を回収するサイクルコレクターが動くので、OKというか循環参照全体を参照する
変数が消えれば消える。ARCの強参照は当然ながら連鎖的には消えない。
これがよく言うARCのメモリーリークでSwiftやObjective Cで起こる現象、親の所有者が消えたのだから内部で
参照しあっていても消えると考えてしまう。サークルを作らず直線状なデーターやツリー上のデーターならば
連鎖的に消える。
ただし、サイクルコレクターがある場合でもグローバル変数になっている場合には終了時のすべての変数が寿命を
迎えるだけなのでそこで壮大なメモリー解放が起こる（これを指して意味がなく壮大な無駄だという人もいるが）
そして、SIGTERMを送ってもなかなか終了しないプログラムは一生懸命メモリー解放を行っていたりする
697デフォルトの名無しさん
2021/11/16(火) 00:38:45.88ID:cHZw5Yem 同じように参照カウントを用いていても状況が真逆で決定的に異なる
GC言語
[対象] 全て
[手段] プログラマーは何もしない
[期限] プログラマーは意識していない
[適用] プログラマーから適用機構は見えない
[機能] 解放のみ
C++のshared_ptrやRustのRc
[対象] 所有者が複数となるレアケースのみ対象
[手段] 明示的にshared_ptrやRcをプログラマーが使用
[期限] どうなると解放されるかタイミングをプログラマーが把握
[適用] 解放のためにdelete(デストラクタ)やdropが適用される
[機能] 解放時にデストラクタにて関連プログラミングが可能 (ファイルを自動クローズなど)
したがってC++やRustは手動メモリ管理でありGCの定義「自動的に解放する機能である」を満たしていない
あくまでもC言語と同じく手動メモリ管理の延長(省力化)でありGCではない
【結論】
『C++やRustのスマートポインタはGCではない』
GC言語
[対象] 全て
[手段] プログラマーは何もしない
[期限] プログラマーは意識していない
[適用] プログラマーから適用機構は見えない
[機能] 解放のみ
C++のshared_ptrやRustのRc
[対象] 所有者が複数となるレアケースのみ対象
[手段] 明示的にshared_ptrやRcをプログラマーが使用
[期限] どうなると解放されるかタイミングをプログラマーが把握
[適用] 解放のためにdelete(デストラクタ)やdropが適用される
[機能] 解放時にデストラクタにて関連プログラミングが可能 (ファイルを自動クローズなど)
したがってC++やRustは手動メモリ管理でありGCの定義「自動的に解放する機能である」を満たしていない
あくまでもC言語と同じく手動メモリ管理の延長(省力化)でありGCではない
【結論】
『C++やRustのスマートポインタはGCではない』
698デフォルトの名無しさん
2021/11/16(火) 00:54:53.09ID:O0etR+7l >>697
その定義でwikipediaの説明風にGCの説明書いてみてよ
その定義でwikipediaの説明風にGCの説明書いてみてよ
699ハノン ◆QZaw55cn4c
2021/11/16(火) 00:56:44.96ID:cq8/Yorc >>697
主観的な記述だと思いますね
私は循環参照を許容できなければ、それはもはや GC ではないと思っています
マークスゥイープかコピーGC（そしてその発展系）しか私は認めません…①
①はともかく、何ができて何ができないか、により GC か GC でないかを明晰に分別すべきかと
主観的な記述だと思いますね
私は循環参照を許容できなければ、それはもはや GC ではないと思っています
マークスゥイープかコピーGC（そしてその発展系）しか私は認めません…①
①はともかく、何ができて何ができないか、により GC か GC でないかを明晰に分別すべきかと
700デフォルトの名無しさん
2021/11/16(火) 03:05:17.23ID:O0etR+7l プログラマがfree相当の処理を明示的に書かなくてもメモリが解放されるのがGC
解放契機がGCの回収だろうがスコープを抜けるタイミングだろうが
コンパイラやランタイムといった処理系が暗黙的に解放処理を挿入するという点では同じ
サイクルを回収できる/できないの違いは、保守的GCと正確なGCの差違のように、GCという大枠の中での細部の差違でしかない
解放契機がGCの回収だろうがスコープを抜けるタイミングだろうが
コンパイラやランタイムといった処理系が暗黙的に解放処理を挿入するという点では同じ
サイクルを回収できる/できないの違いは、保守的GCと正確なGCの差違のように、GCという大枠の中での細部の差違でしかない
701デフォルトの名無しさん
2021/11/16(火) 03:08:48.13ID:O0etR+7l 単にGCと言ったときにガベージコレクションを意味するのかガベージコレクタを意味するのかが場合によって異なるから混乱を招いているのか
702デフォルトの名無しさん
2021/11/16(火) 03:19:14.90ID:cHZw5Yem >>700
プログラマーがfree相当の処理を明示的に書くことが
プログラマーがスマートポインタを明示的に宣言することに変わっただけなので
『スマートポインタはGCではない』となりますね
つまりプログラマーが明示的に関わっているか否かが要点
プログラマーがfree相当の処理を明示的に書くことが
プログラマーがスマートポインタを明示的に宣言することに変わっただけなので
『スマートポインタはGCではない』となりますね
つまりプログラマーが明示的に関わっているか否かが要点
703デフォルトの名無しさん
2021/11/16(火) 05:03:45.36ID:GjD3AmtU >>702
「スマートポインタを明示的に宣言すること」がどうして「free相当の処理を明示的に書くこと」
になるのか理解できないなぁ。
宣言している時点では参照先のリソースを使用しているので、その宣言で解放されると困るわな。
ついでに言うと、shared_ptrにリソースの管理を任せるときは、shared_ptrがプログラムコードの
どの部分で（ソースコード記述的に）リソースを解放するのか決定できないことが多々ある。
これは「free相当の処理を明示的に書くこと」と決定的に異なる部分だな。
「スマートポインタを明示的に宣言すること」がどうして「free相当の処理を明示的に書くこと」
になるのか理解できないなぁ。
宣言している時点では参照先のリソースを使用しているので、その宣言で解放されると困るわな。
ついでに言うと、shared_ptrにリソースの管理を任せるときは、shared_ptrがプログラムコードの
どの部分で（ソースコード記述的に）リソースを解放するのか決定できないことが多々ある。
これは「free相当の処理を明示的に書くこと」と決定的に異なる部分だな。
704デフォルトの名無しさん
2021/11/16(火) 06:34:55.21ID:2/DPJM9H じゃRustは所有権管理方式のGCってことでいいのかな？
705デフォルトの名無しさん
2021/11/16(火) 06:46:59.83ID:rMNMpo6C >>704
これまでのお約束とは異なる新しい判断ですね。
これまでのお約束とは異なる新しい判断ですね。
706デフォルトの名無しさん
2021/11/16(火) 08:06:16.34ID:KQuNI5Eh707デフォルトの名無しさん
2021/11/16(火) 08:37:19.90ID:mhJuEb25 「GC機能」とやらはどこで定義されてるん？
708デフォルトの名無しさん
2021/11/16(火) 08:42:24.55ID:KQuNI5Eh709デフォルトの名無しさん
2021/11/16(火) 08:47:56.56ID:cHZw5Yem 以下いずれもやっていること・行われることは全て同じ
抽象化と省力化が進んだのみ
C「free()で解放」
↓抽象化＋付加機能
C++「deleteでデストラクタを呼んで解放」
↓自動化＋所有概念(専有vs.共有)
現C++「スマートポインタ利用でdeleteを自動行使」
↓全般化＋静的完全性チェックbyコンパイラ
Rust「全てがスマートポインタ相当扱い」
これらとGC言語の違いは「プログラマーがメモリ管理をしていること」
つまり一見すると自動解放されるためメモリ管理していないように見えるが
プログラマーは所有権を管理することでメモリ管理をしている
GCの定義を「利用者がメモリ管理をせずとも自動的にメモリが解放される」とすることで皆が納得できる
抽象化と省力化が進んだのみ
C「free()で解放」
↓抽象化＋付加機能
C++「deleteでデストラクタを呼んで解放」
↓自動化＋所有概念(専有vs.共有)
現C++「スマートポインタ利用でdeleteを自動行使」
↓全般化＋静的完全性チェックbyコンパイラ
Rust「全てがスマートポインタ相当扱い」
これらとGC言語の違いは「プログラマーがメモリ管理をしていること」
つまり一見すると自動解放されるためメモリ管理していないように見えるが
プログラマーは所有権を管理することでメモリ管理をしている
GCの定義を「利用者がメモリ管理をせずとも自動的にメモリが解放される」とすることで皆が納得できる
710デフォルトの名無しさん
2021/11/16(火) 08:59:05.41ID:2/DPJM9H >>706
Arc/Rcのことじゃないよ
動的に確保したメモリ領域を指してる所有権のある変数が
ムーブされずにスコープを抜ければ解放されるようコンパイラがよろしくやってくれる
これも参照カウント方式？
Arc/Rcのことじゃないよ
動的に確保したメモリ領域を指してる所有権のある変数が
ムーブされずにスコープを抜ければ解放されるようコンパイラがよろしくやってくれる
これも参照カウント方式？
711デフォルトの名無しさん
2021/11/16(火) 09:08:46.14ID:mhJuEb25 >>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 ね
ソースは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 ね
712デフォルトの名無しさん
2021/11/16(火) 11:32:23.17ID:O0etR+7l RustやC++にGCがないという言及でGCが意味するところはガベージコレクタというランタイム処理ののことで
ガベージコレクションの仕組みがないとは言っていないという理解をしている
ガベージコレクションの仕組みがないとは言っていないという理解をしている
713デフォルトの名無しさん
2021/11/16(火) 11:59:42.80ID:cHZw5Yem714デフォルトの名無しさん
2021/11/16(火) 12:16:23.63ID:/J0mEe48 いつまでやるんだよこの話
GCスレでも作ってそっちでやれ
GCスレでも作ってそっちでやれ
715デフォルトの名無しさん
2021/11/16(火) 13:00:34.21ID:KQuNI5Eh716デフォルトの名無しさん
2021/11/16(火) 13:01:16.80ID:pnSrHZZq ぼくのかんがえたさいきょうのGC言語の定義なんぞ
プログラム作成になんの役にも立たんから
好きにしてくれ
プログラム作成になんの役にも立たんから
好きにしてくれ
717デフォルトの名無しさん
2021/11/16(火) 13:24:00.95ID:cHZw5Yem718デフォルトの名無しさん
2021/11/16(火) 14:12:09.47ID:2/DPJM9H >>712
その場合はガベージコレクタとは何か？
ランタイム処理とは何か？って定義がないと境界線が曖昧なまま
ガベージコレクションを行う主体(行為者)をガベージコレクタ、
コンパイル時じゃなく実行時に解放タイミングを決定する意味でランタイム処理と言ってるなら
RustのRcやC++shared_ptrはGCの意味するところに当てはまる
ランタイム処理がGoやObjective-Cのようなruntime libraryによって行われる処理って意味で言ってるならあてはまらない
その場合はガベージコレクタとは何か？
ランタイム処理とは何か？って定義がないと境界線が曖昧なまま
ガベージコレクションを行う主体(行為者)をガベージコレクタ、
コンパイル時じゃなく実行時に解放タイミングを決定する意味でランタイム処理と言ってるなら
RustのRcやC++shared_ptrはGCの意味するところに当てはまる
ランタイム処理がGoやObjective-Cのようなruntime libraryによって行われる処理って意味で言ってるならあてはまらない
719デフォルトの名無しさん
2021/11/16(火) 14:12:38.51ID:vHF3kJ9c wikipedia含め自然言語の定義など絶対的なものじゃないよ
その言葉を使った文脈で意味が正しく伝わればいいだけ
その言葉を使った文脈で意味が正しく伝わればいいだけ
720デフォルトの名無しさん
2021/11/16(火) 14:16:08.22ID:x6Dvmgzi >>714
Rust狂信者がGC無いということにして布教したくて、大暴れして嫌われてる真っ最中。完全頭がイカれてる
個々人の見方によればどうでも良い事なんだが、狂信者の"信仰が揺らぐ"ので納得しない。
Rust狂信者がGC無いということにして布教したくて、大暴れして嫌われてる真っ最中。完全頭がイカれてる
個々人の見方によればどうでも良い事なんだが、狂信者の"信仰が揺らぐ"ので納得しない。
721デフォルトの名無しさん
2021/11/16(火) 14:24:20.34ID:JxdD+I2A 科学技術と科学技術が対立するのはよくある現実
対立するのは科学と宗教だと思ってるのは現実逃避
対立するのは科学と宗教だと思ってるのは現実逃避
722デフォルトの名無しさん
2021/11/16(火) 14:25:50.64ID:SlziVE7V723デフォルトの名無しさん
2021/11/16(火) 14:26:44.88ID:2/DPJM9H >>715
参照カウントじゃないとしてGCの定義にしたがった場合にRustのやり方は何らかの方式のGCなのかどうか？
あとSafe Rustなら他が参照してればコンパイルエラーじゃないかな
unsafeなら参照側を長生きさせるバグを埋め込むことは可能
参照カウントじゃないとしてGCの定義にしたがった場合にRustのやり方は何らかの方式のGCなのかどうか？
あとSafe Rustなら他が参照してればコンパイルエラーじゃないかな
unsafeなら参照側を長生きさせるバグを埋め込むことは可能
724デフォルトの名無しさん
2021/11/16(火) 14:28:43.97ID:QRdL5Qqy 参照カウントは、GCか、GCじゃないのか
クソどうでもいい
まあGCだけどね
クソどうでもいい
まあGCだけどね
725デフォルトの名無しさん
2021/11/16(火) 14:28:57.30ID:hZl5lwq3726デフォルトの名無しさん
2021/11/16(火) 14:31:25.51ID:x6Dvmgzi Rust寄りの話をすればGCの有無という定義より、現時点のコンパイラの方法は、Rustがメモリー回収の
コスト(CPU消費）が他に比べて小さいだけの話。参照カウントやBoxのようなスコープで解放と確保を
繰り返す事を「GCの有無に関せず」コストを話している人にも定義の有無の話にレイヤーが違うなどと
言いつつ巻き込んでくる。マジもんの狂信者には言葉は通じない
コスト(CPU消費）が他に比べて小さいだけの話。参照カウントやBoxのようなスコープで解放と確保を
繰り返す事を「GCの有無に関せず」コストを話している人にも定義の有無の話にレイヤーが違うなどと
言いつつ巻き込んでくる。マジもんの狂信者には言葉は通じない
727デフォルトの名無しさん
2021/11/16(火) 14:34:03.96ID:SlziVE7V >>725
Arcはマルチスレッドで共有する時にRcに対してアトミック操作が必要な時にRcの代わりに用いる
シングルスレッド共有: Rc
マルチスレッド共有: Arc shared_ptr
もちろん後者の方がコストが高い
Arcはマルチスレッドで共有する時にRcに対してアトミック操作が必要な時にRcの代わりに用いる
シングルスレッド共有: Rc
マルチスレッド共有: Arc shared_ptr
もちろん後者の方がコストが高い
728デフォルトの名無しさん
2021/11/16(火) 14:40:58.65ID:x6Dvmgzi SwiftやObjective Cなんかはさらに進んでいて、ARCだけだとカウントがボトルネックになる場合があるから
特定のデータ構造についてはGCみたいのを自作する。狂信者は聖典に書いてあることが真理。
レイヤーはネ申が決めた侵さざるべき領域、なんじネ申の言葉たるRustを喋れ、邪教たる他言語を駆逐せよ
特定のデータ構造についてはGCみたいのを自作する。狂信者は聖典に書いてあることが真理。
レイヤーはネ申が決めた侵さざるべき領域、なんじネ申の言葉たるRustを喋れ、邪教たる他言語を駆逐せよ
729デフォルトの名無しさん
2021/11/16(火) 14:42:11.98ID:SlziVE7V >>725
そしてもちろんshared_ptrもArcもRcも所有権を管理するために用いる
所有者が複数可能
一方でunique_ptrやRustの一般は所有者が1人のみなので所有権は維持するか譲渡するかになる
そしてもちろんshared_ptrもArcもRcも所有権を管理するために用いる
所有者が複数可能
一方でunique_ptrやRustの一般は所有者が1人のみなので所有権は維持するか譲渡するかになる
730デフォルトの名無しさん
2021/11/16(火) 14:57:58.41ID:bbFwgKot >>727
ARCってこれのことでは？std::sync::Arcじゃなくてさ
https://en.m.wikipedia.org/wiki/Automatic_Reference_Counting
ARCってこれのことでは？std::sync::Arcじゃなくてさ
https://en.m.wikipedia.org/wiki/Automatic_Reference_Counting
731デフォルトの名無しさん
2021/11/16(火) 15:08:54.50ID:SlziVE7V732デフォルトの名無しさん
2021/11/16(火) 15:26:54.21ID:mhJuEb25 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)をさらに活用して、手動のフレームワーク内でメモリの割り当て解除を自動化します。
> 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)をさらに活用して、手動のフレームワーク内でメモリの割り当て解除を自動化します。
733デフォルトの名無しさん
2021/11/16(火) 15:32:41.58ID:hFtCxoVx 嫌われ者の屁理屈大会
734デフォルトの名無しさん
2021/11/16(火) 15:45:11.75ID:SlziVE7V735デフォルトの名無しさん
2021/11/16(火) 16:05:00.39ID:hZl5lwq3736デフォルトの名無しさん
2021/11/16(火) 16:07:51.68ID:wMIJ1Zq8 GC言語でもどの変数がどのオブジェクトの所有者か意識してコードを書けばそれは手動管理しているからGCじゃないってことになるの？
C++やRust使ってても所有者を気にせずに全部shared_ptrかRcにするようなコードの書き方をすればGCになっちゃうの?
C++やRust使ってても所有者を気にせずに全部shared_ptrかRcにするようなコードの書き方をすればGCになっちゃうの?
737デフォルトの名無しさん
2021/11/16(火) 16:09:38.42ID:QRdL5Qqy Perlでメモリリークしがちな参照カウント方式でもGCとみなしてくれるなら許す
738デフォルトの名無しさん
2021/11/16(火) 16:21:49.03ID:SlziVE7V739デフォルトの名無しさん
2021/11/16(火) 16:39:25.01ID:mhJuEb25 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
コンストラクタの時点で豊富にプログラマに選択肢を与えてる
アロケータやデリータも指定できて自由自在
このように、色々やることあるねプログラマ側は
ここにもズラズラ並んでるけどいろんな手動管理をさせてくれるよね
reset, swap, get, use_countなどなど
そもそも
https://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr
コンストラクタの時点で豊富にプログラマに選択肢を与えてる
アロケータやデリータも指定できて自由自在
このように、色々やることあるねプログラマ側は
740デフォルトの名無しさん
2021/11/16(火) 16:42:40.84ID:mhJuEb25 あ、ズラズラというならRcのほうを引用したほうがさらにズラズラだったか…
741デフォルトの名無しさん
2021/11/16(火) 16:49:31.73ID:XOoLtgC/ ちなみにshared_ptr/RcがGCじゃない派の人って
C++のBoehmGCはどっち判定なの？
使い方的にはshared_ptrと同じくプログラマが明示的にBoehmGCからメモリ割り当てないといけないから
GCじゃないって扱いになるわけ？
C++のBoehmGCはどっち判定なの？
使い方的にはshared_ptrと同じくプログラマが明示的にBoehmGCからメモリ割り当てないといけないから
GCじゃないって扱いになるわけ？
742デフォルトの名無しさん
2021/11/16(火) 17:11:12.20ID:SlziVE7V743デフォルトの名無しさん
2021/11/16(火) 17:15:07.88ID:7dBj/34m 屁理屈大将
744デフォルトの名無しさん
2021/11/16(火) 17:18:12.78ID:4mjXbMzz >>741
「手動メモリ管理はGCじゃない」んだからBohemGCもGCじゃないんだろ、そいつらの中では。
「手動メモリ管理はGCじゃない」んだからBohemGCもGCじゃないんだろ、そいつらの中では。
745デフォルトの名無しさん
2021/11/16(火) 17:23:12.05ID:SlziVE7V >>744
BoehmGCはプログラマーが何も管理しないので自動メモリ管理ですよ
BoehmGCはプログラマーが何も管理しないので自動メモリ管理ですよ
746デフォルトの名無しさん
2021/11/16(火) 17:29:26.94ID:R8o6+SB5 GC_MALLOC(100000); // なにも管理しないぞ！mallocじゃないけどな！必死に自分の考えを押し付けようと１日張り付いてるニート
747デフォルトの名無しさん
2021/11/16(火) 17:35:28.45ID:4mjXbMzz748デフォルトの名無しさん
2021/11/16(火) 17:37:18.20ID:R8o6+SB5 vec![ 0; 100000 ]; // 何も管理しないぞ！GCじゃねえったらGCじゃねーんだ！黙れ小僧！Rustの宣伝を受け入れろ！
749デフォルトの名無しさん
2021/11/16(火) 18:01:15.45ID:SlziVE7V >>747
本気で言ってますか？
スマートポインタではプログラマーが所有権の管理をしているからこそ
毎回プログラマーはここで使うべきはunique_ptrでいいのかshared_ptrにすべきかあるいは既存スマートポインタの参照にすべきかもしくは譲渡すべきか等を管理しながらプログラミングしているのです
これを使い間違えるとメモリ管理ミスとなる多重解放や解放忘れや解放済み領域参照などが起きてしまうのです
Rustでもほぼ同様ですが使い間違えているとコンパイルが通らない点だけ異なります
C++とRustどちらもプログラマーが上述の手動メモリ管理をしながらプログラミングする点で同じです
一方でBoehmGCでは上述の手動メモリ管理をせずに使えます
自動メモリ管理方式となっています
本気で言ってますか？
スマートポインタではプログラマーが所有権の管理をしているからこそ
毎回プログラマーはここで使うべきはunique_ptrでいいのかshared_ptrにすべきかあるいは既存スマートポインタの参照にすべきかもしくは譲渡すべきか等を管理しながらプログラミングしているのです
これを使い間違えるとメモリ管理ミスとなる多重解放や解放忘れや解放済み領域参照などが起きてしまうのです
Rustでもほぼ同様ですが使い間違えているとコンパイルが通らない点だけ異なります
C++とRustどちらもプログラマーが上述の手動メモリ管理をしながらプログラミングする点で同じです
一方でBoehmGCでは上述の手動メモリ管理をせずに使えます
自動メモリ管理方式となっています
750デフォルトの名無しさん
2021/11/16(火) 18:41:22.00ID:c2zT3/Zj Rustも使い方を間違えると循環参照ができてコンパイルは通ります。Boehmでもnew (GC) char[size]で
class Foo: public gc{}しなければ回収されません。
その他ではディストラクタの回収ではなく不定期改修ではnew (GC)で、gc_cleanupから派生させる必要が
あります。とてもではないですが、「手動」「自動メモリ管理方式」などと、屁理屈を捏ねて言い負かそうと
必死こいてる哀れな狂信者は言葉は通じないです。
class Foo: public gc{}しなければ回収されません。
その他ではディストラクタの回収ではなく不定期改修ではnew (GC)で、gc_cleanupから派生させる必要が
あります。とてもではないですが、「手動」「自動メモリ管理方式」などと、屁理屈を捏ねて言い負かそうと
必死こいてる哀れな狂信者は言葉は通じないです。
751デフォルトの名無しさん
2021/11/16(火) 19:14:07.66ID:cHZw5Yem >>750
BoehmGCは言語の機能ではなくライブラリなのだから呼ばなければGCが始まらないのは当たり前
自動メモリ管理と手動メモリ管理の区別はそんな表層的などうでもいいことではない
それを理解できない人がいるとは驚いた
C++スマートポインタとRustでは手動メモリ管理のため
使い方を間違えるとメモリ管理が破綻して深刻なバグが生じたりコンパイルが通らなかったりする
これを解決するにはプログラマーがメモリ管理を常に考えてどこにどんなスマートポインタを用いたり所有権は渡さずに参照にするのか譲渡するのかコピーするのかなど毎回各所で全て考えて手動メモリ管理を行なう
一方でGC言語やBoehmGCなどは自動メモリ管理なのでプログラマーは上述のようなことを考えなくてもよい
言語システムやGCライブラリにお任せとなる
BoehmGCは言語の機能ではなくライブラリなのだから呼ばなければGCが始まらないのは当たり前
自動メモリ管理と手動メモリ管理の区別はそんな表層的などうでもいいことではない
それを理解できない人がいるとは驚いた
C++スマートポインタとRustでは手動メモリ管理のため
使い方を間違えるとメモリ管理が破綻して深刻なバグが生じたりコンパイルが通らなかったりする
これを解決するにはプログラマーがメモリ管理を常に考えてどこにどんなスマートポインタを用いたり所有権は渡さずに参照にするのか譲渡するのかコピーするのかなど毎回各所で全て考えて手動メモリ管理を行なう
一方でGC言語やBoehmGCなどは自動メモリ管理なのでプログラマーは上述のようなことを考えなくてもよい
言語システムやGCライブラリにお任せとなる
752デフォルトの名無しさん
2021/11/16(火) 19:27:51.29ID:4mjXbMzz >>749
プログラマが
「unique_ptrでいいのかshared_ptrにすべきかあるいは既存スマートポインタの参照にすべきかもしくは譲渡すべきか等を管理しながら」
プログラムしているからGCじゃないという主張か。
なら、すべてshared_ptrに統一して所有権の管理なんてしなければいい。実際、既存コードとの互換性問題やプログラムの性能問題が無ければ推奨されるshared_ptrの使い方だしな。
そうすれば>>749の主張する「自動メモリ管理方式」とやらも実現できるからBoehmGCみたいなものだ。
あと、>>751の主張をするなら、まず初めに「自動メモリ管理方式」「手動メモリ管理方式」の定義と差分を明確にしなくては話にならない。
「使い方を間違えると」とか、曖昧な話でごまかすなよ。「それを理解できない人がいるとは驚いた」みたいな人格攻撃する暇あったら、グウの音も出なくなるぐらい堅牢な議論をしてみろよ。
プログラマが
「unique_ptrでいいのかshared_ptrにすべきかあるいは既存スマートポインタの参照にすべきかもしくは譲渡すべきか等を管理しながら」
プログラムしているからGCじゃないという主張か。
なら、すべてshared_ptrに統一して所有権の管理なんてしなければいい。実際、既存コードとの互換性問題やプログラムの性能問題が無ければ推奨されるshared_ptrの使い方だしな。
そうすれば>>749の主張する「自動メモリ管理方式」とやらも実現できるからBoehmGCみたいなものだ。
あと、>>751の主張をするなら、まず初めに「自動メモリ管理方式」「手動メモリ管理方式」の定義と差分を明確にしなくては話にならない。
「使い方を間違えると」とか、曖昧な話でごまかすなよ。「それを理解できない人がいるとは驚いた」みたいな人格攻撃する暇あったら、グウの音も出なくなるぐらい堅牢な議論をしてみろよ。
753デフォルトの名無しさん
2021/11/16(火) 19:27:54.43ID:mhJuEb25 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 なんよね
しかもガベージコレクションの代替として使用できるとのこと
なんか知らんけど色々プログラマ側から触れるようになってるんだとしたら
結局は手動メモリ管理って感じもするけど（よく知らない状態での想像）
結局一度も触ったことが無いな
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 なんよね
しかもガベージコレクションの代替として使用できるとのこと
なんか知らんけど色々プログラマ側から触れるようになってるんだとしたら
結局は手動メモリ管理って感じもするけど（よく知らない状態での想像）
754デフォルトの名無しさん
2021/11/16(火) 19:28:00.82ID:ayQ3yI+l Rustの不都合なことを言われて、知りもしないのに墓穴を掘る狂信者ｗ
さっきはRustならコンパイルが通らない点だけ異なりますと言っていたのに、今度は深刻なバグが生じたりと言い出す。
手動自動なんていう浅はかな考えを押し通そうとしているから、知らない事を突かれる。
まあRustの肩をもつなら、Rustは独立したスレッドのサイクルコレクターが無い点が「フルスペックのGC」では無いといえるかもしれんが
狂信者の話には１つも出てこない。あんたのその理論というにはお粗末な考えで全員が黙ったとしても、ここに顔出す人以外は
GC的なアルゴリズムだろ？と言われてまたワンワン噛みつくのか？めっちゃ迷惑だと思うがｗ
さっきはRustならコンパイルが通らない点だけ異なりますと言っていたのに、今度は深刻なバグが生じたりと言い出す。
手動自動なんていう浅はかな考えを押し通そうとしているから、知らない事を突かれる。
まあRustの肩をもつなら、Rustは独立したスレッドのサイクルコレクターが無い点が「フルスペックのGC」では無いといえるかもしれんが
狂信者の話には１つも出てこない。あんたのその理論というにはお粗末な考えで全員が黙ったとしても、ここに顔出す人以外は
GC的なアルゴリズムだろ？と言われてまたワンワン噛みつくのか？めっちゃ迷惑だと思うがｗ
■ このスレッドは過去ログ倉庫に格納されています
