[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
782: デフォルトの名無しさん (ﾜｯﾁｮｲ e563-0why) [sage] 2025/03/23(日) 01:58:28.60 ID:IgihfQRv0(1/4) AAS
>>778>>779
お騒がせしましたｻｰｾﾝ；；；orz ビルドが通らないというのは私めの勘違いだった模様。
コードはそれで良いです。
そのコード（最小サンプル）、および最小サンプルにする前のコード×VS2015でもfriend宣言部分をコメントアウトしてビルドが通った 。n_
フレンド宣言friend std::unique_ptr<Foo>; を付けるに至った履歴が無いので推測ですだが
デストラクタがprivateのままだったタイミングがあったのかも……
（m_pObjが生ポインタのタイプのSingletonはデストラクタがprivateでもビルドが通る（デストラクタを呼ぶ人が居ないため）
→この状態でm_pObjをstd::unique_ptr<Foo>に変更してビルドエラー、アクセス許可が無いとコンパイラに言われて慌ててfriend追加、だった可能性、
787: デフォルトの名無しさん (ﾜｯﾁｮｲ e563-0why) [sage] 2025/03/23(日) 10:56:08.84 ID:IgihfQRv0(2/4) AAS
>>784
サンプルコードでは省略したけんども、Double-checked lockingの実験をしたかったﾉﾃﾞｽ！
■ Double-Checked Locking is Fixed In C++11
https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/
つなみに関数内staticオブジェクト初期化（初回実行時）のスレッド安全性がどうーなっているのかは
よく知りま栓（よって採用には消極的
>>785
Singletonなので誰からもshareされないし……
この場合むしろshared_ptrの方が牛刀な可能性もあるし……
なぜなら、std::shared_ptrの参照カウンタはその利用特性上
異なるスレッドから非同期にインクリメント/デクリメントされることを想定せざるおえず、
スレッド安全性担保がそこそこ重い同期オブジェクトで一方unique_ptrの所有権移動は非同期に行われることはなさげ
788: デフォルトの名無しさん (ﾜｯﾁｮｲ e563-0why) [sage] 2025/03/23(日) 10:57:59.97 ID:IgihfQRv0(3/4) AAS
すまんこTeamsのノリで途中送信すたorz
誤： スレッド安全性担保がそこそこ重い同期オブジェクトで一方unique_ptrの所有権移動は非同期に行われることはなさげ
正： スレッド安全性担保がそこそこ重い同期オブジェクトで行われている危険性がある。一方unique_ptrの所有権移動は非同期に行われることはなさげなので多分軽量
789(1): デフォルトの名無しさん (ﾜｯﾁｮｲ e563-0why) [sage] 2025/03/23(日) 11:03:44.18 ID:IgihfQRv0(4/4) AAS
だいたいstd::unique_ptrとstd::shard_ptrでは前者が1個のポインタと同じサイズなのに後者は2個分ある（ヒープにとられた参照カウンタへのポインタを持つため
sizeof(shared_ptr)=16
sizeof(unique_ptr)=8
というのもあり、std::unique_ptr<T>で済むところをstd::shared_ptr<T>推しするのはいかがなものか……
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.038s