[過去ﾛｸﾞ] C++相談室 part137 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
848(4): (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)06:48 ID:d4gXl3Bi0(1/10) AAS
>>846
ポインタ使え思想はすでにC#とかなクラスが参照型な言語で実現されているが
オブジェクトの解放にガベージコレクタが要る言語になった
これはガベージコレクタ無し・所有権の無条件移動だけだと、次のようなケースで早速話が破綻するから仕方が無い
void bar(int n) {
std::unique_ptr<Foo> a(new Foo());
for (int i = 0; i < n; i++) {
省6
851(1): (ﾌﾞｰｲﾓ MM7b-uZyL) 2018/09/30(日)09:10 ID:3yGUdTqFM(1/2) AAS
>>848
よくわからんな
848の問題はそれmoveでも一緒だよね
単にデフォルトの挙動がmoveかborrowかだけの話で、unique_ptrがたまたま前者なだけ
スマポ使えば間接参照はどうしても増えるけど、実際>>849のようなケースで特定の要素だけ所有権捨てたりしないでしょ
所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、その場合に限ってスマポを使えばよい
コーナーケースのために全てを複雑にする必要はない
852(1): (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)09:21 ID:d4gXl3Bi0(4/10) AAS
>>851
>所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、
有り得ない仮定すぐる…
>>848なケースにおいて、オブジェクトaの生成時点というのは、
ライブラリー制作者がfunc1()を設計してビルドまで完了した後やがな…
854(4): (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)09:46 ID:d4gXl3Bi0(5/10) AAS
>>853
いやｽﾏﾝ言い方がまずかったそういう意味ではない
確かに
>所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、
というのは真だが、ライブラリのインターフェースに解放が必要なオブジェクトのmoveなど認めたら有り得ないコストが生じるという話
func1()の制作者が所有権を寄越すことを強制した（そういうインターフェース仕様にしてしまった）場合、
func1()を使う人はfunc1()に所有権を渡さねばならない。この結果、
省5
859: (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)10:45 ID:d4gXl3Bi0(8/10) AAS
>>858
>>848、>>849は、現行C++におけるスマポのmoveと本体のmoveの優劣は問題にしていない
848を現行C++のコード風に書いたから誤解を招いたのかもしれないが、比較はあくまで現行C++と846思想の比較であって、
846の次の思想を実行に移したら>>854のコストが避けられませんよという話
1. スタックを使うスタイルはやめるべき（全部スマポであるべき）
2. 所有権の管理さえ適切に行えるようになってさえいれば（現行C++のムーブセマンティクスみたいな）ムーブなんか要らん
1は現行C++との比較において、間接参照回数に響く
省1
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 1.161s*