C++相談室 part137 - 暇つぶし2ch

C++相談室 part137 ..

238:デフォルトの名無しさん
18/09/05 19:15:02.29 BafBBEgt0.net
どっちもコンパイルエラー出る点では同じ

239:デフォルトの名無しさん
18/09/05 19:32:27.66 YeNc+rPy0.net
>>233 C言語に対して重大な勘違い、または質�

240:窿激Xに些細な打ち間違い、どちらかだと思うが、どちらかは分からない。

241:235
18/09/05 19:33:03.57 YeNc+rPy0.net
C言語じゃなくてC++だね、ここ。

242:デフォルトの名無しさん
18/09/05 22:59:59.06 yXdlNP4XM.net
selectしろや

243:
18/09/05 23:22:24.89 juRrGCxW0.net
>>215
内容をみてくださり感謝いたします、とても考えさせられました
まず >>211 に二点誤りがありました
・コンストラクタ引数に与える bit 数から、内部 vector<atomic<int>> の確保容量を計算する方法に誤りがあった
・CAS 後にスピンロックするかどうかの判断にあやまりがあった
修正 URLﾘﾝｸ(ideone.com)
>>215
＞while (!_v[q]. _a.compare_exchange_weak(e, e|(1<<r)) {}
＞while (!_v[q]. _a.compare_exchange_weak(e, e& ~(1<<r)) {}
＞(e は未初期化状態でも構わない）
>>195 「やりたいことはエラトステネスのふるいなので、この場合オンしたあとオフすることはありません」
に範囲を限定するのならば >>215 はうまくいくと思います。これには「なるほど！！」と思いました。
ビットセットの最中は別スレッドのビットリセットやビットテストをスピンロックさせたい、
とかの排他制御をやるのならば、dirty-bit（というか1ビットセマフォ）を作らないといけないと考えています

244:デフォルトの名無しさん
18/09/06 02:04:16.57 Gt7E2PT1M.net
>>234,235
すみません
C++にあまり詳しくないのでわからないのですが、どこがおかしいのでしょうか？
これなら内容等しいですか？
void hoge(int x, int& ret){
ret = int * 2;
}
int hoge(int x){
return int * 2:
}

245:デフォルトの名無しさん
18/09/06 02:08:35.51 itCyrIVk0.net
それはギャグで言っているのか？
void hoge(int x, int& ret){
ret = x * 2;
}
int hoge(int x){
return x * 2:
}

246:デフォルトの名無しさん
18/09/06 02:15:35.03 Ev1vpWJGM.net
>>240
すみません素でボケてました…
それなら同一ですか？
returnする場合と参照渡しする場合の違い(速度など)があるのか知りたかったです

247:デフォルトの名無しさん
18/09/06 02:38:44.74 itCyrIVk0.net
えーっと、
上段の参照渡しは呼び出し時に渡した変数そのものがやってきて書き換える。
下段のやつはコピーを返すので一手間ある。
理論的には下段の方がちょっと遅い。
まぁ、コンパイラが頑張ってきえるかもしれんし、
デルタ時間的に差はあるかもしれないが最近のコンピュータならあまり問題にならない。
それよりも速度を気にするなら採用しているアルゴリズムを精査したほうが効果的。
ちょっと変な文になった。

248:デフォルトの名無しさん
18/09/06 05:45:03.77 UQb09hzL0.net
厳密なところはアセンブラ出力を個別に見ないと分からない、
という前提はひとまず措くとして…。
int x, ret1, ret2; // x が未初期化ってところは見逃してくれ
hoge_ref(x, ret1); // void hoge(int x, int& ret)
ret2 = hoge_val(x); // int hoge(int x)
上は第2引数に参照を渡す手間が必要な代わりに返り値の処理は不要
下は引数1個で済む代わりに呼出側で返り値を別の変数に代入しなきゃいけない
相殺してどっこいどっこい大差なし、じゃないかな。
計算結果を変数に入れる必要がない場合、等はまた別のお話。

249:はちみつ餃子
18/09/06 05:49:16.79 IzfX8EX20.net
>>240
後者の末尾がコロンになってるのがそのままやで。

250:はちみつ餃子
18/09/06 05:59:16.76 IzfX8EX20.net
仮に差があったとしてもナノ秒レベルの話やん

251:デフォルトの名無しさん
18/09/06 07:14:55.98 3Sjg8sdP0.net
速度どうこうは1兆回回すループの中にあるとか1マイクロ秒以内に完了しないと原子炉が爆発するとか
プロファイラでクソ時間がかかってることが判明したとかした時だけ気にしよう

252:243
18/09/06 08:27

253::46.68 ID:UQb09hzL0.net

254:はちみつ餃子
18/09/06 08:44:12.19 IzfX8EX20.net
早すぎる最適化は諸悪の根源っていうもんな。

255:デフォルトの名無しさん
18/09/06 08:51:51.10 j/wx9LUv0.net
同意。固定長オンリーなどの最適化を最初から入れ込むとロクなことがない。

256:デフォルトの名無しさん
18/09/06 09:29:04.75 mrWZ3sxKM.net
そーそー
尻拭く時間だけ早くしてもンコが早く出なきゃしゃーない

257:デフォルトの名無しさん
18/09/06 10:29:33.35 c/F3wcvdM.net
>>242
何言ってんの、逆でしょ
差が観測できるかは別にして下の方が速い(効率的)
int返すならレジスタ返しなんだから
メモリアクセスよりずっと速い

258:はちみつ餃子
18/09/06 10:57:52.18 IzfX8EX20.net
>>251
関数単独を見るとそうだが、
レジスタで返してもそれを結局は変数に書き込むじゃんという >>243 の話と合わせて考えると
レジスタを経由する分だけ遅くなり得るっしょ。
ただ、この関数を実行した結果を長期には保存しない (式の途中でこの関数を使うとか) のだと
後者の方が速かったりもするだろうし、まあ、状況によるよな。

259:はちみつ餃子
18/09/06 10:58:36.13 IzfX8EX20.net
実際のところ、インライン化されて更に他の最適化とコンボが起こったりすると
普通の人間にはどうなるか予測がつかんので考えるだけ無駄。

260:デフォルトの名無しさん
18/09/06 11:15:06.66 c/F3wcvdM.net
>>252
なんで呼び出し側の話がはいってくるんだよ
そっちの話を含めるとしても
呼び出し側もレジスタのまま処理が行われるのが普通だし、
メモリに書き出されるとしても、
参照と同程度になるってだけ
このABIを理解するのはc/c++使う上で基本
無意味と思うのは結構だがそれはお前の関心がないってだけ
レスしなけりゃいい

261:デフォルトの名無しさん
18/09/06 12:11:07.39 uRta3OIBM.net
intの場合は速度差は特に考慮しなくて良いんですねありがとうございます
それと、関数内でOpenCVで画像をゴニョゴニョして、結果の画像をリターンしたい場合は、どちらが良いのですかね？
特にメモリリークを起こしたくない(今現在起きてるので改善したい)ので、もし何か重大な違いがあるなら知りたいです
void hoge(cv::Mat x, cv::Mat ret){
ret = x + cv::Scalar(100);
}
cv::Mat hoge(cv::Mat x){
return x + cv::Scalar(100);
}

262:はちみつ餃子
18/09/06 13:28:43.07 IzfX8EX20.net
>>254
呼出し側の状況によっても変わりうるから呼出しの状況を含めるってのがそんなにおかしな話かね。
あと、あくまでもこれは C++ という言語を中心にした一般原則としてどうコンパイルされることも「有りうる」ということを述べているのであって、
特定のアーキテクチャやコンパイラや ABI を想定したものではないよ。
多くの (あるいは主要な) 処理系であなたが言うような結果になるというなら、
それはそうかもしれないが、そこには単に私の関心がないのも確か。

263:はちみつ餃子
18/09/06 13:34:38.93 IzfX8EX20.net
>>255
前者のコードの cv::Mat ret は cv::Mat& ret の間違い？

264:デフォルトの名無しさん
18/09/06 13:53:20.00 c/F3wcvdM.net
>>256
それはお前の間違った理解であって一般とは言わない
だいたい呼び出し側も含めて反論されてんのになにぼけたレスしてんだよ
お前の理屈だとレジスタの返しが無用となるじゃないか
x64ならraxでaarch64ならx0で返り値を返す
32bitのレガシーならいざしらず64bitでもabiはそう決められてるわけ
お前の興味のない低いレイヤーではそういうのを最大限活用して効率的にcpu回してんだよ

265:はちみつ餃子
18/09/06 14:06:16.01 IzfX8EX20.net
>>258
> だいたい呼び出し側も含めて反論されてんのになにぼけたレスしてんだよ
それは >>254 のことだろ？
それは特定の命令セットや ABI でないと成り立たないから、
そうでない一般論としてはどうともなりうると私は言っているので論点が違うし、
私はそっちの論点は気にしてなかったという話じゃないか。

266:デフォルトの名無しさん
18/09/06 14:09:29.47 c/F3wcvdM.net
>>259
現実のはなししようぜ
成り立たないシステムあげてみなよ

267:はちみつ餃子
18/09/06 14:11:05.68 IzfX8EX20.net
>>255
知らんな。
関心は無い。

268:はちみつ餃子
18/09/06 14:27:25.26 IzfX8EX20.net
>>255
前者については & の脱字だと仮定して答えるけど、
その脱字が無ければ、前者でも後者でも最終的な結果に差はないと思う。
特にメモリリークにつながりそうな要素もない。
ただ、単純に、局所的に考えるならば後者の方が効率的と言えると思う。
前者だと呼出し側では結果を受け取るための cv::Mat 型の変数を用意しなければならないが、
そのときにデフォルトコンストラクタが走ってから結果は operator= で格納するという形になる。
後者だとコピーコンストラクタ一発で済むので簡単。場合によっては RVO が適用されるかもしれない。
一度作った変数を何度も結果格納用に使いまわすのならば、
前者の方がメモリアロケーションの回数を抑制できる (効率的になる) 可能性も有るけど、
Mat の実装次第ではそうならないかもしれないし、
そこらへんは実際にやってみないとわからない。
ところでメモリリークが起きていると判断したのは何かツールを使って検証したの？

269:はちみつ餃子
18/09/06 14:31:00.99 IzfX8EX20.net
あっ、 >>261 で >>255 にアンカーを付けちゃったけど、これは >>260 の間違いね。
現実の話というなら、インライン化や最適化が入れば ABI もクソもねぇし、
そんなの考えたらキリがないやろ。

270:デフォルトの名無しさん
18/09/06 18:25:26.14 c/F3wcvdM.net
>>263
関数内の最適化のみで考えればいいだけなんだからきりはあるだろ
つまりインライン展開なし、LOTなし
ABIを意識するのは全然特殊じゃない
言語間のよびだしはざらだし、
クラッシュダンプにスタックトレース残すためにあえてインライン抑制したりする
お前が経験不足なだけだよ

271:はちみつ餃子
18/09/06 18:41:01.02 IzfX8EX20.net
>>264
そっちの脳内でどんな前提を置いてるかなんて知らんがな。

272:デフォルトの名無しさん
18/09/06 19:48:52.61 c/F3wcvdM.net
>>265
コテハンの割に薄いやつだ
もとの質問は関数から値の返し方についてどちらが速いかという質問なんだから、
関数のインライン展開がないと仮定すれば、定性的に答えられる問いだ
かつその仮定は別に現実ばなれしてるわけでもない
それをお前はその知識が有用であることも知らずに考えるだけ無駄とかぶったぎってるわけだ
このスレは相談室
無駄なのはそういうお前の存在ではとおれは思うわけ

273:デフォルトの名無しさん
18/09/06 20:12:24.70 64ZwjQvb0.net
malloc()したﾋｰﾌﾟはfree()解放するのは当然
ｳﾝｺしたあと水で流さないぐらい行儀が悪い

274:デフォルトの名無しさん
18/09/06 20:23:27.14 itCyrIVk0.net
メモリーリークは基本的に自分でNEWすることで起こる。
最近のC++では基本的に自分でNEWすることはほとんどない。
動的なメモリが欲しければvectorを使う。
後は、ポインタにインスタンスを確保しないで関数に投げるとかもやってはいけない。メモリを破壊することになる。
あと、どうしてもnewが必要だったりGCが必要な時はスマポを使う。
そういう作法でやると、ユーザーコードでnewすることはほぼない。

275:デフォルトの名無しさん
18/09/06 20:47:20.81 itCyrIVk0.net
えーっと、関数にポインタを投げる時はその関数の仕様を精査して扱わないとほんとやばい。

276:デフォルトの名無しさん
18/09/06 21:04:04.33 bw6Oo6uj0.net
newとdeleteを使いこなせない補助輪付C++グラマってのも問題だけど

277:デフォルトの名無しさん
18/09/06 21:10:02.71 iyjSCMca0.net
スマポはGCじゃねえよぼけ

278:デフォルトの名無しさん
18/09/06 21:14:09.31 itCyrIVk0.net
shared_pointerは参照カウントっていうGC機構ですよ？

279:デフォルトの名無しさん
18/09/06 21:17:21.85 itCyrIVk0.net
>>270

280:デフォルトの名無しさん
18/09/06 21:18:00.66 itCyrIVk0.net
おっと。
>>270
補助輪があろうがバグ出すよりマシだと思うよ。それと保険的な意味もあるし。

281:デフォルトの名無しさん
18/09/06 21:18:22.90 iyjSCMca0.net
CGってそもそも何だ？
アプリが「今、解放しろ」というタイミングで動くのをGCというならfreeもGCだぞ

282:デフォルトの名無しさん
18/09/06 21:20:24.16 64ZwjQvb0.net
いつ解放されるか分からないとか
そもそもｵﾌﾞｼﾞｪｸﾄの外部でﾎﾟｲﾝﾀの生存期間を制御できてないｺｰﾄﾞがﾔﾊﾞｲわ

283:デフォルトの名無しさん
18/09/06 21:24:58.09 itCyrIVk0.net
>>275
そういう、広義解釈は話題が滅茶苦茶になるのでやめましょう。
GCはガベージコレクションだよ。freeは解放関数だよ。
シェアードポインターの解放タイミングは普通コントールしないのでGCだと思ってます。
というか、開放タイミングが未定だからシェアードポインタ使うんじゃないですか？

284:デフォルトの名無しさん
18/09/06 21:27:59.96 itCyrIVk0.net
それは全能でないとバグが出ちゃうのでこういう機構が発明されました。
書くときは大まかには寿命は把握しているとは思うのですが、細部までは精査しないことが多いんじゃないでしょうか。
自分のクローンに共有オブジェクトを持たせるときとか普通に書くと滅茶苦茶大変ですよ？

285:デフォルトの名無しさん
18/09/06 21:37:24.49 iyjSCMca0.net
>>277
広義解釈してるのはおまえだよ
シェアードポインタの解放タイミングはデストラクタだろうがよ
freeと何がどこが違うんだよ
おまえどこまでオレオレ空想してるんだ？

286:デフォルトの名無しさん
18/09/06 21:38:17.39 itCyrIVk0.net
>>276
それはある程度アクセス権の範囲を考えれば何とかなりそうな予感。
それと開放した後のメモリ叩かれた時とどっちがいいか相談ってことで。

287:デフォルトの名無しさん
18/09/06 21:41:02.92 itCyrIVk0.net
>>279
複数の共有がある場合、一個のデストラクタが走った程度では解放されませんよ？
freeは別にデストラクタに仕込む必要ないじゃないですか。
それと、複数の共有がある場合適切にfreeできますか？

288:デフォルトの名無しさん
18/09/06 21:42:45.15 JT+LXegNM.net
コレクションしてないのになんでgcなんだよ。アホすぎる

289:デフォルトの名無しさん
18/09/06 21:43:23.10 bw6Oo6uj0.net
シェアードはマルチタスクには不向きだし

290:デフォルトの名無しさん
18/09/06 21:49:40.12 itCyrIVk0.net
コレクションサイズが1のコンテナはないのですね。まぁ、冗談は置いといて。
物事を知ってるなら後は任せました。無知でごめんなさい。

291:デフォルトの名無しさん
18/09/06 21:51:04.10 itCyrIVk0.net
>>283
マルチスレッドならアトミックにできた気

292:がしますけど、どうでしたっけ。マルチプロセスならそもそもメモリ空間が違うのでお門違いですね。

293:
18/09/06 22:00:46.00 N2ZzCqNY0.net
>>272
参照カウンタは普通GCに含めないのでは？

294:デフォルトの名無しさん
18/09/06 22:02:22.60 itCyrIVk0.net
URLﾘﾝｸ(ja.wikipedia.org)参照カウント
こういう記事を見つけました。

295:デフォルトの名無しさん
18/09/06 22:04:19.65 itCyrIVk0.net
ホントお前ら人殺すことばっか考えてるよな。
そういうのは良いから初心者殺すのマジやめて。

296:デフォルトの名無しさん
18/09/06 22:04:41.28 vgkXomJH0.net
gcの一実装として参照カウンタ方式があるだけで、スマポはgcじゃない。

297:デフォルトの名無しさん
18/09/06 22:06:33.66 itCyrIVk0.net
それならそれでいいです。

298:デフォルトの名無しさん
18/09/06 23:18:28.17 8cSq8zHP0.net
>>288
横からでスマンが、他の初心者に偉そうに大嘘教えてるやつを初心者とは普通呼ばない
都合のいいときだけ初心者ヅラはだめよ

299:デフォルトの名無しさん
18/09/06 23:34:23.61 3bNAvGWPM.net
>>262
ありがとうございます
forの中で何回も関数呼び出すので前者が良さそうですね

300:デフォルトの名無しさん
18/09/06 23:34:43.07 itCyrIVk0.net
>>291
嘘の範囲を限定しないと俺大罪人じゃないですか。
まぁ、いいや。
メモリーエラーで落ちろ。

301:
18/09/06 23:34:53.93 N2ZzCqNY0.net
>>289
スマートポインターのうち std::shared_ptr は参照カウンタを内蔵しているのだから
①参照カウンタが GC、故に、std::shared_ptr も GC
②参照カウンタが GC でない、故に、std::shared_ptr は GC でない
①②のどちらかしかない
参照カウンタが GC なのにスマートポインタが GC でない、というのは矛盾しているのでは？
私は「参照カウンタは GC じゃない」と思う

302:デフォルトの名無しさん
18/09/06 23:48:27.91 8cSq8zHP0.net
>>293
>>251
もちろんインライン展開される場合は除く（展開されたら多分同じコードになると思うが
あと
 >>255の質問に対して >>268は不適切、>>268から話が変な方向に行ってる
OpenCV使ってるって言ってるし、間違った使い方してリーク（>>255がnewしたのではない部分）
の可能性の方が高いと思うけどね

303:デフォルトの名無しさん
18/09/06 23:52:47.61 HW23dE280.net
>>294
なにも矛盾してないよ。
GCの一実装として参照カウント方式を使ったものがある。
スマホの中に参照カウントを使ったものがある。
だからといってGC=スマポじゃない。
エンジンで走る車があって、エンジンで飛ぶ飛行機があっても、車は飛行機じゃないのと一緒

304:
18/09/07 00:04:30.19 WaHB6+zk0.net
>>296
＞エンジンで走る車があって、エンジンで飛ぶ飛行機があっても、車は飛行機じゃないのと一緒
is-a の話の例えに has-a の話を使うのは論理的ではありませんね
「車 has エンジン、飛行機 has エンジン」の話と「参照カウンタ is GC、スマポ is ＧＣ」の話は別ですよ

305:デフォルトの名無しさん
18/09/07 00:12:24.59 YR0a2VfT0.net
>>297
いやgc=参照カウンタなんて言ってないんだけど。
gcに参照カウント方式を使っているものがあるといってるの。はじめからhas_a関係しか言及してない。

306:
18/09/07 00:15:18.97 WaHB6+zk0.net
>>298
＞いやgc=参照カウンタなんて言ってないんだけど。
そこに「＝」記号を使うのがおかしいのでは？
真偽は別として、記号を使うのなら ⊂ とか ∈ じゃないですか？

307:はちみつ餃子
18/09/07 00:17:33.32 EL+7DMJm0.net
参照カウンタは GC だろ。

308:はちみつ餃子
18/09/07 00:22:54.57 EL+7DMJm0.net
>>266
元々の質問はどちらが速いかではない。

309:
18/09/07 00:53:47.67 WaHB6+zk0.net
>>300
では std::shared_ptr も GC でしょうか？

310:はちみつ餃子
18/09/07 01:28:57.33 EL+7DMJm0.net
>>302
私は std::shared_ptr を GC だと思ってるよ。
解放のタイミングがコンパイル時に確定しないようなのは GC だろってくらいのカジュアルな認識だけど。
基準の妥当性はともかくとして、とにかく私はそういう基準で考えてる。
QZ 氏の中で std::shared_ptr と GC を隔てるのは何だと思ってるの？

311:デフォルトの名無しさん
18/09/07 02:17:04.39 obwFdGuS0.net
Qt5触ってみてるけど生ポインタばっか使ってて気持ち悪い、これでいいのか？

312:デフォルトの名無しさん
18/09/07 07:52:15.03 KDtg+GuV0.net
GC ⊇ shared_ptr

313:デフォルトの名無しさん
18/09/07 08:31:14.42 M/DU9wQ1M.net
>>304
生は触って気持ちいいものしかないよ

314:デフォルトの名無しさん
18/09/07 11:18:53.99 f8oqes6vH.net
parentクラスがあってそれを継承したchildクラスがあります。
vector<parent*> getParentlist(){//省略}でこんな感じでparentクラスのポインタのリストを返す関数があります。
それでここからが質問なのですが、
vector<child*> childList = (vector<child*>)getparentlist();
こういうコードがあってびっくりしています。
機能はしているみたいですがこれ作法的にオッケーなんでしょうか。
ダウンキャストは良くないと聞いていたりそもそもこれダウンキャストなのかとかちょっと分からないんです。
よろしくおねがいします。

315:デフォルトの名無しさん
18/09/07 11:20:41.99 /+XJI6DP0.net
>>281
話が通じてないなあ。。。
デストラクタでuse_count見てるのは当たり前だろ
シェアードポインタの話だぜ？
解放のタイミングがアプリのロジックに従属してるかどうかって話なのに
何を言い出すかと思えば

316:デフォルトの名無しさん
18/09/07 12:35:44.17 KEvh9jix0.net
>>307
試せる限りのコンパイラではそもそもコンパイルエラーだったけどなぁ
vector<parent *> &getParentlist();
じゃなくて？？
その上で
(vector<child *> &)getParentlist();
なら通るよ、通るし普通に使えるはず

317:デフォルトの名無しさん
18/09/07 13:23:59.20 f8oqes6vH.net
>>309
失礼しました。ポインタ抜けてました
vector<parent*>* getParentlist(){//省略}
で
vector<child*>* childList = (vector<child*>*)getparentlist();
こんな感じです

318:デフォルトの名無しさん
18/09/07 13:38:44.48 KEvh9jix0.net
おいおい・・・ｗ
ポインタでも同じことだ、そのキャストをreinterpret_castだと考えたらわかるはず
それでわからないならC++の継承の仕組みを勉強すべき

319:はちみつ餃子
18/09/07 16:38:51.51 EL+7DMJm0.net
基底方向へのキャストの実態は
サブオブジェクトまでのオフセット分だけアドレスをずらす操作なので、
>>310 のような場合にはそれは実現できない。
単に無理やり型を合わせているだけになってしまっている。
C++ 的にはあかんやつ。
ただ、実際に動いている理由をあえて考察するなら、
child が parent を単一継承した場合などには parent が child の先頭に配置されるようなメモリレイアウトにコンパイルされる可能性が高く、
アドレスをずらす量が 0 で済んでしまうので
型を読み替えるだけでも不整合が顕在化せずに動作してしまうということは有りうる。
あくまでも、処理系がやってることが偶然に組み合わさって動いているというだけなので、やめといた方がよい。

320:デフォルトの名無しさん
18/09/07 17:46:14.93 KEvh9jix0.net
そこまでご丁寧に説明してやるのなら、「Cスタイルのキャストは使うな」、を教えるべきじゃねーの？

321:デフォルトの名無しさん
18/09/07 18:34:49.58 mMEjLB3K0.net
parent * が child * なのかも分からないのに強引にキャストするのか
そこまで型無視するなら void * でいいんじゃない知らんけど

322:はちみつ餃子
18/09/07 20:57:02.69 EL+7DMJm0.net
>>313
せやな。

323:はちみつ餃子
18/09/07 20:57:32.70 EL+7DMJm0.net
C++ スタイルのキャストを、特に入門者の内は static_cast だけ使っておけばまあまあ大丈夫。
static_cast でエラーになるような変換は C++ 的にはだいたいイケてないやつ。

324:デフォルトの名無しさん
18/09/07 20:59:50.93 /+XJI6DP0.net
アホか
dynamic_castが使えないくせに初心者皆伝なんぞやれん

325:
18/09/07 22:12:33.50 WaHB6+zk0.net
>>303
＞私は std::shared_ptr を GC だと思ってるよ。
…GC発祥の地 lisp の使い手のはちみつさんがそうおっしゃるのなら、私の中の定義も書き換えないといけませんね
mark and sweep GC って、プログラム本体とは関係のないところで、それこそメモリの死にビットをも使ったりして、ごそごそやる、というイメージがあります
＞解放のタイミングがコンパイル時に確定しないようなのは GC だろってくらいのカジュアルな認識
＞std::shared_ptr と GC を隔てるのは何
「解放のタイミングを図る機構が表のプログラムとは独立している」
くらいでしょうか？表のプログラムからの参照が途切れることと free() されることに直接の関係性がない mark and sweep とその発展型のみを GC とみなしています
といって、GC の本は一冊しか持っていません

326:デフォルトの名無しさん
18/09/07 22:36:10.40 OXR/kEGJ0.net
は○ち○餃子はLisperか
言語選びは慎重にな�

327:I ttps://postd.cc/lisping-at-jpl/

328:はちみつ餃子
18/09/07 22:37:40.84 EL+7DMJm0.net
>>318
定義がひとつでなきゃならないとは思ってないよ。
だから自分なりに一貫した考え方があるのなら、それはそれでいいんじゃないかな。
ただ、「表の機構と分離されているか」という考え方だと、それは抽象化の仕方であって、メカニズム (アルゴリズム) の基準ではないね。
その基準だと std::shared_ptr が GC ではないとは言えても参照カウンタが GC ではないとは言えない。

329:デフォルトの名無しさん
18/09/07 22:45:54.86 Gz5E8uWmd.net
お返事遅れました >>213です
Overlappedの設定をCreateNamedPipe時点に引数として渡す構造体ことで同期制御を実現できました
ありがとうございました
メモリリーク探しきつい....

330:デフォルトの名無しさん
18/09/07 22:58:55.32 nLV7kBrTa.net
すみません質問があります
メインスレッドと通信スレッドがいて、
通信スレッドはメインスレッドのオブジェクトポインタ持ってます
メインスレッドはクラス化されており、スレッド用のstatic関数以外にもメンバ関数を持っています
通信スレッドがデータ受信して、メインスレッドの別のメンバ関数を呼び出した時、
メインスレッドで実行していた処理はどうなるのでしょうか？
メインスレッドで実行していた処理はあくまでもstaticな関数の処理で、staticでない他のメンバ関数は別に処理されるのでしょうか？

331:はちみつ餃子
18/09/07 23:04:25.63 EL+7DMJm0.net
>>322
説明が分かり難いなぁ。
通信スレッドとやらから呼び出した関数は通信スレッド上で走っているし、
メインスレッドはメインスレッドで走っている。

332:デフォルトの名無しさん
18/09/07 23:21:53.12 nLV7kBrTa.net
>>323
分かりずらくて申し訳ありません..
もし通信スレッドで呼び出した別のメンバ関数内でメンバ変数を変更した場合、
メインスレッドでもメンバ変数の変更値を参照できるのでしょうか

333:デフォルトの名無しさん
18/09/07 23:22:52.89 RvuhpJx80.net
スレッドとメモリの関係がよく分かってないようだ

334:デフォルトの名無しさん
18/09/07 23:23:07.46 OXR/kEGJ0.net
微妙な質問ｷﾀ

335:デフォルトの名無しさん
18/09/07 23:23:45.59 KDtg+GuV0.net
解放のタイミングがコンパイル時に確定しないのは shared_ptr でも同じでしょ。
任意のshared_ptrインスタンスを別のインスタンスにコピーした場合、解放のタイミングはコンパイル時に確定できない。

336:デフォルトの名無しさん
18/09/07 23:25:23.60 RvuhpJx80.net
vectorがconstexpr対応できるならshared_ptrもできそう

337:デフォルトの名無しさん
18/09/07 23:26:09.70 B/yxkRYZ0.net
staticなﾒﾝﾊﾞ関数ではstaticなﾒﾝﾊﾞ変数しか参照できない
staticでないﾒﾝﾊﾞ関数はstaticな変数もstaticでない変数も参照できる
staticなﾒﾝﾊﾞ関数とstaticでないﾒﾝﾊﾞ関数が作用しあうのであれば、
当然staticな変数になる
はっきりいってな
staticな変数はｸﾞﾛｰﾊﾞﾙ変数と同じだからな
とうぜん同じ実体の変数を参照することになる

338:デフォルトの名無しさん
18/09/07 23:26:58.48 OXR/kEGJ0.net
>>329は視野が広い人じゃなかったのか！？

339:デフォルトの名無しさん
18/09/07 23:29:06.23 B/yxkRYZ0.net
> スレッド用のstatic関数以外にもメンバ関数を持っています
> 通信スレッドがデータ受信して、メインスレッドの別のメンバ関数を呼び出した
> 通信スレッドで呼び出した別のメンバ関数内でメンバ変数を変更した
まず低学歴知恵遅れは質問を読解する能力がない

340:デフォルトの名無しさん
18/09/07 23:35:54.69 OXR/kEGJ0.net
こりゃーもう >>324には >>331に回答してもらうしか

341:はちみつ餃子
18/09/07 23:38:50.05 EL+7DMJm0.net
>>324
出来るが、データ競合が起こらないように気を付けよう。

342:はちみつ餃子
18/09/07 23:41:24.38 EL+7DMJm0.net
質問者が状況を理解してない説明をしてるから本当に回答になってるのかイマイチわからぬ。
無理に言葉にしようとせずにコードを示してくれた方がいいんだがなぁ。

343:デフォルトの名無しさん
18/09/07 23:41:30.87 B/yxkRYZ0.net
ﾊﾞｶじゃなければ
普通にｱﾄﾞﾚｽが固定されてるstaticなﾒﾝﾊﾞ関数のｱﾄﾞﾚｽを
ｽﾚｯﾄﾞを開始させるｱﾄﾞﾚｽにしてると推定できるからな

344:デフォルトの名無しさん
18/09/07 23:46:20.44 B/yxkRYZ0.net
このｽﾚのﾊﾞｶどもはｽﾚｯﾄﾞなんか
なんも分かってないからな
質問するﾔﾂもﾊﾞｶになにを聞いてもﾑﾀﾞだからな
そこの理解は必要

345:デフォルトの名無しさん
18/09/07 23:56:01.03 OXR/kEGJ0.net
>>335
>ｽﾚｯﾄﾞを開始させるｱﾄﾞﾚｽ
さすあに
スレッドを起こす質問に解釈しやがった；；
>>322の
>メインスレッドはクラス化されており
>通信スレッドはメインスレッドのオブジェクトポインタ持ってます
と、>>324の
>メインスレッドでもメンバ変数の変更値を参照できるのでしょうか
からすると通信スレッドで変更したメモリをメインスレッドでも参照できるのかという質問かとｵﾓﾀわ；；；

346:デフォルトの名無しさん
18/09/07 23:58:34.82 B/yxkRYZ0.net
> 通信スレッドはメインスレッドのオブジェクトポインタ持ってます
まず一番最初に書いてることが読めてない
致命的な頭のﾜﾙｻといっていい

347:デフォルトの名無しさん
18/09/08 00:00:18.18 j/6nk0eH0.net
普通にﾒｲﾝｽﾚｯﾄﾞのﾒﾝﾊﾞ関数呼び出して
ﾒｲﾝｽﾚｯﾄﾞのﾒﾝﾊﾞ変数を変更すると読めるからな
こんだけｺﾐｭﾆｹｰｼｮﾝﾚﾍﾞﾙが低いと
実生活でも支障があるﾚﾍﾞﾙといっていい

348:デフォルトの名無しさん
18/09/08 00:03:28.41 VqyCCBP80.net
>>330
半角クンは自分の見たいものしか見えない、すなわち常に半角クンの中ではすべてのものを見通している視野100%ということなのだろう

349:デフォルトの名無しさん
18/09/08 00:04:14.21 49ssh0n4a.net
>>333
mutexしときます
いろいろアドバイスありがとうございます
 >>329ですね

350:デフォルトの名無しさん
18/09/08 00:06:40.10 j/6nk0eH0.net
まずなこのｽﾚの低学歴知恵遅れたちは
自分たちがどんだけ低学歴知恵遅れかという自覚がない
致命的といっていい

351:デフォルトの名無しさん
18/09/08 00:18:54.01 6MRSNGru0.net
低学歴知恵遅れなので質問の解釈に関する >>337と >>339の違いがわからんが、
それはそうとして、当初の疑問に戻るが視野の広い >>342は
>とうぜん同じ実体の変数を参照することになる
には一切注釈をつけなくて良かったの？

352:デフォルトの名無しさん
18/09/08 00:20:24.81 j/6nk0eH0.net
また低学歴知恵遅れが負け惜しみ意味不明なこといってるしな
低学歴知恵遅れの負けず嫌いは異常だからな

353:デフォルトの名無しさん
18/09/08 00:22:38.67 j/6nk0eH0.net
低学歴知恵遅れほど自尊心だけは高い
ｺﾚは底辺に多い
そして自分がｺﾞﾐｸｽﾞの低学歴知恵遅れである自覚もない
つまり救いようがない

354:デフォルトの名無しさん
18/09/08 00:30:51.48 j/6nk0eH0.net
低学歴知恵遅れの底辺ｺﾞﾐｸｽﾞほど自己評価だけは高い
その根拠のない自己評価の高さは
どこからくるものなかははっきりとは分からない
低学歴知恵遅れの底辺ｺﾞﾐｸｽﾞほどそういう傾向がある
それは経験からかなり相関が高いと確信している

355:
18/09/08 00:31:21.19 t7GfMYxV0.net
みなさん厳しいですね…
私は質問側ですが、そして今 schme スレで質問を丸投げしちゃっていますが、わからないときは、なにがわからないかわからない、という感じだったりしています
 >>324
なにか断片的でいいからコード例をあげていただくと嬉しいです、例えば URLﾘﾝｸ(ideone.com)

356:デフォルトの名無しさん
18/09/08 00:45:27.68 j/6nk0eH0.net
むしろこのｽﾚの低学歴知恵遅れの底辺ｺﾞﾐｸｽﾞたちは
質問してるﾔﾂのﾚﾍﾞﾙにすら到達してない

357:デフォルトの名無しさん
18/09/08 00:46:44.54 49ssh0n4a.net
>>347
pthread使ってる以外はほぼ同等な考え方です
実例作っていただきありがとうございます。

358:デフォルトの名無しさん
18/09/08 01:03:30.65 6MRSNGru0.net
>>326で書いたとおりスレッドAで変更したメモリをスレッドBで正しく参照できるのか否かというのは
微妙な問題なんじゃ
 >>347のコードでf::nの書き換えと参照が正しく動くのは
20行目のC::f()呼び出しで呼び出されたstd::coutがメモリバリア的な効果を果たしたに過ぎないかもしれん
（中でmutexとかcritical sectionとかなシステムコールを呼んでいるなら普通のOSならメモリバリアが効く
と自尊心だけは高い低学歴知恵遅れなので難癖をつけておく
実証はしない

359:デフォルトの名無しさん
18/09/08 01:10:28.57 6MRSNGru0.net
>>347のコードがそもそもC::nがvolatile宣言されていないのに安全に動いている理由は…
と始めると荒れる…！
それはともかくスレッド間のメモリの読み書きを >>341のmutexでガードするというのは大変良い心がけです
多少遅いかもしれないが遵守する限り泥沼に踏み込まずに済む

360:デフォルトの名無しさん
18/09/08 01:32:58.78 LCjnyCTn0.net
>>322

361:メインスレッドとサブスレッドで並列に起動して同じ変数を書き換えた場合、書き換えレースになる。ロックっていう機構があるのでそれを参照。

362:
18/09/08 01:41:37.02 t7GfMYxV0.net
>>351
よろしければ教えていただけますか？
＞20行目のC::f()呼び出しで呼び出されたstd::coutがメモリバリア的な効果を果たした
メモリバリアって要するに x86 の lfence, sfence, mfence のことですか？
これはCPUキャッシュがメインメモリに吐き出されることを保証するものですか？
これらの命令は Pentiumu2 あたりにはなかったと思います、でも Pen2 とか特に Celeron-BP6(abit) で普通にデュアルプロセッサできていたのはどうしてでしょうか？

363:デフォルトの名無しさん
18/09/08 02:36:49.43 6MRSNGru0.net
>>353
>これはCPUキャッシュがメインメモリに吐き出されることを保証するものですか？
ちげう
実行したコアのライトコマンドキューかリードコマンドキュー上の命令をその場で全部実行してしまうというもの
キャッシュのinvalidateやfillが起きるかどうかとは別の話（結果的に起きることもあるが常にではない
キャッシュと関係あるみたいな説明のページがあることは承知しているが苦情は漏れに言わないでﾎｽｲ
>これらの命令は Pentiumu2 あたりにはなかったと思います、でも Pen2 とか特に Celeron-BP6(abit) で普通にデュアルプロセッサできていたのはどうしてでしょうか？
古代の話は知らん
OoO（アウトオブオーダー実行）はすでにあったはずなので、ライトコマンドキューやリードコマンドキューもすでにあった
全くの推測だが、キャッシュのinvalidate操作が（invalidateを常に伴うため効率の悪い）メモリバリアと同じ効果があったとかではないかいや知らんけど

364:デフォルトの名無しさん
18/09/08 02:52:26.13 6MRSNGru0.net
ちなIA（Intel Architecture）のうちでも常識的なコア数のやつは
コア間のキャッシュコヒーレンシをハードウェアで勝手に取ってくれるので、
コア間のメモリ参照の不整合はメモリバリアだけ注意したら逝ける（キャッシュの存在は透過的

365:はちみつ餃子
18/09/08 02:58:07.14 VmsJpbI+0.net
>>353
こないだ atomic を使ってたけど、
atomic について調べたならそこらへんの話もどこかに書いてなかったか？
C++ 用語ではバリアでなくてフェンスって言ってるけど。

366:デフォルトの名無しさん
18/09/08 03:04:22.19 RizVmglH0.net
メメリバリアやフェンスの意味を知るにはcpuのメモリモデルの理解が必要
URLﾘﾝｸ(yohhoy.hatenablog.jp)

367:
18/09/08 03:04:32.58 t7GfMYxV0.net
>>354
＞実行したコアのライトコマンドキューかリードコマンドキュー上の命令をその場で全部実行してしまうというもの
＞キャッシュのinvalidateやfillが起きるかどうかとは別の話（結果的に起きることもあるが常にではない
なるほど…ちょっとだけ理解が進んだかもしれません
「はるか遠くにあるメインメモリに変更が反映されるかどうか」はプログラムの書き手にはあまり関係がなく、
「各コアから見る限りにおいて、各コアが発したライトあるいはリードの結果すべてが反映され、各コアからはみえている」と考えればいいのですね
これらのメモリの可視性について URLﾘﾝｸ(www.cs.tsukuba.ac.jp) 等を熟考しています
mutex や cond にその方面での効用があるとは…、pthread のメモリ可視性に関する効果はあまり意識していませんでした
重要なヒントをくださりありがとうございます

368:
18/09/08 03:17:34.12 t7GfMYxV0.net
>>356
ええ、atomic に関係する話をいろいろと読んではいたのですが、正直なところ、あまりよくわからなかったことを告白します
acquire とか release とか、いまひとつイメージできなかった…
atomic の各メンバ関数の memory_order は C++デフォルト引数として sequence-consist(ency) を与えていることはわかりましたので「最強にしているから、まあいいか」くらいですましていました
 >>354
＞実行したコアのライトコマンドキューかリードコマンドキュー上の命令をその場で全部実行してしまうというもの
この記述が一番しっくりきました

369:
18/09/08 04:20:01.69 t7GfMYxV0.net
>>352
＞書き換えレース
ええと、これを読んで reset-set flip-flop の禁止入力「R=S=1」のことを思い出してしまったんですが、それはさておき
複数のコアが同一メモリに対して「同時に書き込み」する、というのは、このフリップフロップ禁止入力と同じ意味あいですか？
つまり「どっちの書き込みが後になるか、予想がつかないから禁止」…①
それとも、「複数のコアが本当に同時に書き込んでしまった場合、結果が不定になる」…②
（昔のフロッピーディスク供給のソフトウェアプロテクトの方法としての「コロコロビット」＝読み出すたびに 0/1 が変わる）という意味なのか
いや、①も②も同じような意味なのかもしれませんが、
>>215 の「CAS 連続スピンロックや CAS 連続スピンロック中に別コアから書き込んだり読み込んだりすること」
が②の意味で危険で、ソフトウェア側で mutex や dirty-bit (>>238) を設けて本当に意図的にコントロールしなければならないのか、と、ちょっと心配になりました
最初から安全側にふっておくとは思いますが

次ページ