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

C++相談室 part137 ..

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) を設けて本当に意図的にコントロールしなければならないのか、と、ちょっと心配になりました
最初から安全側にふっておくとは思いますが

370:デフォルトの名無しさん
18/09/08 08:05:39.39 RizVmglH0.net
考える前に学んだ方がいい
cas が使い物にならないならなぜそんな物があると思う？
というか mutex の実装にも cas は使用される。
使い方がわからないからcasは使わず mutex を使うという判断は正しいが、
例えば前の例のエラトステネスの篩で実装1ビットセットする毎に
mutex で排他していたらコアがかなり沢山あってもシングルスレッドの方が速い
(mutex api を処理する時間が大半を占めてしまう)

371:デフォルトの名無しさん
18/09/08 08:13:01.68 RizVmglH0.net
質問する前にスレッドセーフとか排他制御とかレースコンディションとか
弱いメモリモデルとかでググって時間くらいしっかり読んで

372:デフォルトの名無しさん
18/09/08 08:13:34.47 RizVmglH0.net
>時間くらい
「1時間くらい」のタイプミスでした。

373:デフォルトの名無しさん
18/09/08 11:49:10.23 +e2Zk2SC0.net
>>360
cpuのメモリモデルの説明読んだら最初の方に書いてあると思うけど
普通ワード単位のアクセスは何もしなくてもハード的にアトミックであることが保証されてる
そこで壊れたらやってられないからな

374:デフォルトの名無しさん
18/09/08 13:52:50.37 UCzuGyPmM.net
>>360
> つまり「どっちの書き込みが後になるか、予想がつかないから禁止」…①
順序は予測できないと言うのは正しい
> それとも、「複数のコアが本当に同時に書き込んでしまった場合、結果が不定になる」…②
通常のプロセッサならこれはない
排他制御がなされていてどちらかの結果が最終的に反映される
ただ CAS (Compare And Swap) 命令はそう言う話じゃなくて読出動作 (Compare) と書込動作 (Swap) がアトミック（つまりその間には他のアクセスは無いように制御されてる）ってこと
ソフトでどうのこうのできる話じゃないからシステムから提供されてるAPIを素直に使いなさい
 >>364
中途半端な知識で語るなよ

375:デフォルトの名無しさん
18/09/08 16:38:24.58 +lRq1NsW0.net
>>364
だよな
同一のCS, WE/OEをファンアウトさせるわけで
配線遅延があってもクロック同期で関係なくなるし

376:デフォルトの名無しさん
18/09/08 20:07:53.81 6MRSNGru0.net
このスレは荒れる…！
マルチスレッド、マルチコア、アウトオブオーダー実行（OoO）にまつわる3つの問題は分けて考えられねばならない；
　(A) 書き換えレースの問題（>>352）
　(B) アドレスxに対する読み書きのatomic性（>>364）
　(C) メモリバリア（>>354）
(A)はマルチスレッドすればシングルCPUでも起きる問題
(B)はこれは何ビット幅までの読み書きを他コアが割り込み不可能なバスサイク

377:ルで行えるかという話。マルチコア固有 (C)はマルチコア状況化でのアウトオブオーダー（OoO）実行の影響をソフトで制御して無問題にするテクの話で、マルチコア×OoO固有の話 >>364は(B)のことを言っており、だいたい合っているんじゃ（IAの場合、4バイト境界に整列した32ビットまでは(B)の意味でatomicに読み書きできる　整列していないデータの読み書きは16 bitであっても(B)の意味でatomicではない　インテルのマニュアルに書いてある　自尊心だけは高い低学歴知恵遅れなのでいちいちソースは示さないが

378:デフォルトの名無しさん
18/09/08 20:29:14.34 6MRSNGru0.net
とはいえ、読み書きをミューテックスなりロックなりでガードする、…(D)
これだけを遵守すれば >>367の問題は全部忘れて良い（>>351の後段にも書いた）
メモリモデルとかまともに勉強する必要は無い
さらに言うと、まともなコンパイラなら（中でどんな副作用やメモリバリアを行うかわからない）システムコールを跨いだ
変数のレジスタ割り当てとかしないから、(D)を守れば実際のところ（ほとんどのケースで）volatileも要らん
メモリモデルを勉強する必要があるのは、(D)の速度に不満が生じて改善する必要に迫られたとき、
例えばdouble-checked lockingテクがちゃんと動くのかとか不安になったりロックレスハッシュを作らねばならなくなったときだけ！

379:デフォルトの名無しさん
18/09/08 22:09:03.01 Mc6Ny40VM.net
>>367
マルチプロセッサとかNUMAの事は考慮しなくても良いのけ？

380:デフォルトの名無しさん
18/09/08 23:30:32.50 ZUEeKRTR0.net
バスサイクルと言ったりミューテックスって言ったり話のレベルがぐちゃぐちゃすぎる…

381:デフォルトの名無しさん
18/09/09 01:33:18.67 XJaXrhZ00.net
なんせC++は生ポが使える低水準言語ですし・・・

382:デフォルトの名無しさん
18/09/09 03:24:55.55 Q3MV1FJL0.net
要するにあらゆる左辺値をatomicにして更にミューテックスでガードしとけば（これはキチガイ）
ハード系の知識を学ぶ必要はない（ハードソフトという名の蛸壺）という無茶苦茶な主張だな
勉強嫌いにもほどがあるだろ、何が低学歴だ

383:デフォルトの名無しさん
18/09/09 08:36:42.55 BqWnELncM.net
周辺チップからのメモリ書換をミューテックスでガード出来るのか

384:デフォルトの名無しさん
18/09/09 08:59:15.50 9h0HyZsY0.net
実際プログラミングする上でハードの知識はいらんだろ

385:デフォルトの名無しさん
18/09/09 09:25:43.25 BqWnELncM.net
ハードの知識無しでデバドラ書けるのけ？

386:デフォルトの名無しさん
18/09/09 10:19:49.00 Q3MV1FJL0.net
>>374
メモリのゴーストとか普通に出てくるだろ
PCという狭い牧場から出たことのない家畜は知らんだろうけど

387:デフォルトの名無しさん
18/09/09 10:31:54.13 9h0HyZsY0.net
>>375
は？プログラミングが書けると言っただけでデバドラのプログラミングするなんて言ってねえよ
じゃあお前は信号処理を知らずに音声合成のプログラミング書けるのか？
>>376
だからそんなの考慮知らなくもソフトウェアは作れるんですが

388:デフォルトの名無しさん
18/09/09 10:37:46.17 kQslwDxe0.net
作文したら推敲しろ、って小学校で習うはずなんだけどな

389:デフォルトの名無しさん
18/09/09 10:39:04.08 9h0HyZsY0.net
>>378
え？
お金も払われないのに推敲？
時間の無駄じゃん

390:デフォルトの名無しさん
18/09/09 11:01:35.79 Q3MV1FJL0.net
>>377
ああ家畜か
人間よばわりして悪かったな

391:デフォルトの名無しさん
18/09/09 11:25:28.91 lGJ+2GvF0.net
ハードウェア部分を隠すためのOSによるアクセスの抽象化とか、
標準ライブラリがあるわけだし、ハードウェアの知識が絶対に必要でもないでしょ。
デバイスドライバを書くプログラマが優れているとか、その反対に
高レベルな(抽象度の高い)ソフトを作る人ほど偉いってものでもない。

392:デフォルトの名無しさん
18/09/09 11:26:29.90 l6rR/pccM.net
>>380
逆に家畜はお前じゃね？
ハードウェアを意識しないとプログラミング出来ないなんて可哀相

393:デフォルトの名無しさん
18/09/09 14:43:15.61 TxROatu90.net
何これ？

394:デフォルトの名無しさん
18/09/09 15:02:39.54 //bKOaXP0.net
いつものマウントごっこだろ

395:デフォルトの名無しさん
18/09/09 16:27:56.67 TAQT5wBea.net
for i in {0..15}; do
mount /dev/dm-$i /mnt
done

396:デフォルトの名無しさん
18/09/09 17:06:11.77 V1LakR3i0.net
捕食される側の人類最底辺同士で争ってる

397:デフォルトの名無しさん
18/09/09 17:19:50.37 xES8AK750.net
低レベルプログラミングって言う面白そうな本が出てたなあ

398:デフォルトの名無しさん
18/09/09 18:06:25.87 acpzPeVw0.net
そういえば、さいきんの低レベルいじる時ってどうするんやろね。
BIOSなくなってきてるし、作法かわってきてるのかなぁ・・・。

399:デフォルトの名無しさん
18/09/09 18:53:37.14 +aTtRZce0.net
古き良きシリアルポートが普通のPCではほぼ絶滅してるからなあ
USBきらい

400:デフォルトの名無しさん
18/09/09 19:01:40.42 acpzPeVw0.net
USB制御のノウハウってあんまり周知されてない感じがする。

401:デフォルトの名無しさん
18/09/09 19:09:08.66 Q3MV1FJL0.net
アイソクロナス？

402:デフォルトの名無しさん
18/09/09 19:38:22.19 eYgKQZDEM.net
>>382
高級ってのを誤解しているアホがここにもいたわw

403:デフォルトの名無しさん
18/09/09 21:21:28.72 TxROatu90.net
>>390
LINE EYEで見てるとエラー出まくったりしてるね

404:デフォルトの名無しさん
18/09/10 22:46:19.98 IGaBABI/d.net
dllからexeをCreateProcessで起動するとメモリリークするとかある？
debugging tool forなんたらみたいなやつでメモリリークチェックしてるのだけど
exeから呼んだやつはリークなし
dllから呼んだやつはリークありとなっている
監視開始ポイントと終了ポイント及び呼び出しソースコードに差分がなく
その他にも差分がないんだ

405:デフォルトの名無しさん
18/09/10 23:03:06.10 XzQQxj6r0.net
dllから呼びだす場合
dllは呼びだした側のﾌﾟﾛｾｽと同じｱﾄﾞﾚｽ空間にﾏｯﾋﾟﾝｸﾞされ
dll側の関数を呼び出して生成されたﾋｰﾌﾟも
呼びだした側のﾌﾟﾛｾｽと同じｱﾄﾞﾚｽ空間にﾏｯﾋﾟﾝｸﾞされる
ﾌﾟﾛｾｽから呼び出した場合、
呼び出した側のﾌﾟﾛｾｽと関係ない呼び出された側のﾌﾟﾛｾｽのｱﾄﾞﾚｽ空間に
ﾋｰﾌﾟは生成されるから
呼び出した側のﾌﾟﾛｾｽを監視してもそのﾘｰｸについて検出されることはない
分かった？

406:デフォルトの名無しさん
18/09/11 05:56:49.25 3QLqjO4o0.net
質問と回答が違う

407:デフォルトの名無しさん
18/09/11 09:46:04.97 THBnA1g1M.net
そのツールでもうちょっと情報とれないんかいって思うが、
ランタイムライブラリの指定とか見直してみたら？
というかexe起動を繰り返したら繰り返すだけリークする？
最初の一度だけならあんまり気にしなくていいんじゃない？しらんけど

408:デフォルトの名無しさん
18/09/11 22:07:19.41 i7axZbyN0.net
質問通りの
ｺﾚ以上ないｴﾚｶﾞﾝﾄなﾚｽになってる

409:デフォルトの名無しさん
18/09/11 22:09:50.93 BTBlWiGG0.net
あかねちゃん。

410:デフォルトの名無しさん
18/09/12 00:18:15.71 B23czwA60.net
>>394
umdhじゃないかと思うが、スタックトレースは見てみたの？
プロセスの標準入出力に名前付きパイプが指定されてるとdllの明示的なアンロードのタイミングでApplication verifierでリーク検出されたことはあった。

411:デフォルトの名無しさん
18/09/12 09:57:57.91 OqmF7RQ90.net
>>394
dll ってことは何かの exe の中で動いてるんだろ
そっちのコードが他スレッドで何かアロケートしてるとか
単に dll の問題で CreateProcess しなくてもリークしてるとか

412:デフォルトの名無しさん
18/09/12 19:18:39.87 BIkz+Ggud.net
>>397
>>395
>>400
>>401
色々とありがとう。UMDHです
色々と試してみたところ繰り返し行ってもリーク量は増えなかったので、自分が作成したロジック以外でのリークみたいでした
UMDHは増えず、タスクマネージャー上のプライベートメモリとかが増えてくのは気になったけども....

413:デフォルトの名無しさん
18/09/14 01:05:55.69 y0a2qOvJ0.net
>>402
メモリはコミットサイズを確認。
あとはハンドルをクローズしてないとかはないよね。

414:はちみつ餃子
18/09/14 01:26:50.31 NOYHI4qj0.net
>>402
UMDH は増えずにタスクマネージャー上のプライベートメモリが増えるということは必ずしも問題があるわけではない。
(もちろん問題がある場合もある。)
malloc や new で割り当てるメモリは、
OS からある程度のメモリを融通してもらった塊をアプリケーションのレイヤ (ランタイムライブラリ) で切り分けて提供することになる。
足りなくなったらまた OS に要求する。
しかしその要求というのも、メモリ空間を予約するだけで物理メモリはまだ割り当てないかもしれない。
「プライベートメモリ」というのは予約したメモリ空間のサイズを表すらしく、
実際のメモリ使用量を表さないので、
基本的には UMDH をあてにした方が良いと思う。

415:デフォルトの名無しさん
18/09/14 04:46:07.61 Ln8BSCnm0.net
gflagsで対象exeのメモリ割り当てをコンパチブルモードにしてみたら

416:デフォルトの名無しさん
18/09/14 07:55:52.78 05hGeAAsd.net
>>403
コミットサイズを確認すれば良いんですね
ハンドルクローズもしてますね
ありがとうございます
 >>404
分かりやすくありがとうございます
差分が出ることもあり得るのですね
丁寧でとても助かりました

417:デフォルトの名無しさん
18/09/14 20:22:01.09 KUzt6BBd0.net
プログラム全体で使いたい変数を宣言する際は
グローバル変数として宣言するのと#defineするのって何か違います？
どっちを使えばいいんですかね？

418:デフォルトの名無しさん
18/09/14 20:34:55.91 9HmXun5pa.net
#define という事は定数だと思われるのでconstexprな変数に一票。

419:デフォルトの名無しさん
18/09/14 20:44:10.13 kDrjUGbb0.net
グローバル変数だとコンパイルのときにエラーを出してくれる
#defineは値がヘンでもエラーを出さない

420:デフォルトの名無しさん
18/09/14 20:54:15.35 c9w6X9S4M.net
どっちとか言う前にもう少し言語仕様を理解してこいよ…

421:デフォルトの名無しさん
18/09/14 21:06:34.91 YK4Q2JFR0.net
>>407
そのレベルならいったんdefineは忘れるべき。
defineはほとんどの場合ただの置換に過ぎない。

422:デフォルトの名無しさん
18/09/14 21:31:46.88 fXySkelb0.net
C++なら値変更不可な参照のみのｼﾝｸﾞﾙﾄﾝにしとけばいい
ｼﾝｸﾞﾙﾄﾝを動的にｲﾆｼｬﾗｽﾞできるようにすれば起動時に設

423:定の変更ができたりするようにできるめんどくさかったらdefineでいい defineかえてｺﾝﾊﾟｲﾙしなおせばしまいだからなそういうdefineはｶﾃｺﾞﾘｰ毎にまとめてぜんぶ一か所に書いときなさいｼﾝｸﾞﾙﾄﾝでも裸の外部変数はやめておいたほうがいいそれさえしなければどうでもいい

424:デフォルトの名無しさん
18/09/14 21:53:36.47 YK4Q2JFR0.net
し、シングルトン？
この話題でまさかのsingleton笑
さすがにこれはネタだよね？

425:デフォルトの名無しさん
18/09/14 21:55:11.25 fXySkelb0.net
外部変数はｼﾝｸﾞﾙﾄﾝの変数だからな
なにもおかしくない

426:デフォルトの名無しさん
18/09/14 21:56:25.39 YK4Q2JFR0.net
ここで言ってるsingletonって所謂GoFデザインパターンのsingletonだよね？

427:デフォルトの名無しさん
18/09/14 21:58:26.14 fXySkelb0.net
そもそも池沼のID:YK4Q2JFR0はdefineがなにかすらわかってないからな
> defineはほとんどの場合ただの置換に過ぎない。
ほとんどもへったくれもなく
defineはただの置換だからな
頭悪い

428:デフォルトの名無しさん
18/09/14 21:59:24.65 fXySkelb0.net
頭悪いやつはﾑﾘしてﾚｽしなくていい
なにもわかってないんだからな

429:デフォルトの名無しさん
18/09/14 22:01:10.88 gH/Sje3Q0.net
>>416
結合と文字列化もあるから「ほとんど」であってるが

430:デフォルトの名無しさん
18/09/14 22:01:20.46 YK4Q2JFR0.net
いつもの半角くん病が発症したらしいw
毎度毎度、燃料投下、お疲れ様ですm(_ _)m

431:デフォルトの名無しさん
18/09/14 22:02:21.10 fXySkelb0.net
defineか外部変数にしたいとかいう質問だからな
普通にｸﾞﾛｰﾊﾞﾙを定数値をもたせたいという質問内容なのに
このｽﾚの低学歴知恵遅れたちがどう解釈したかはしらない

432:デフォルトの名無しさん
18/09/14 22:02:53.11 fXySkelb0.net
結合も文字列かもただの置き換え

433:デフォルトの名無しさん
18/09/14 22:05:22.67 fXySkelb0.net
まず低学歴知恵遅れは日本語を読解する能力がない
ものごとも抽象的にみる能力もない
つまり認知機能に著しい欠陥がある

434:デフォルトの名無しさん
18/09/14 22:05:58.57 BDjkgOYf0.net
ID真っ赤にして火病起こしたか

435:デフォルトの名無しさん
18/09/14 22:06:56.64 fXySkelb0.net
静的にどう置換されるかｺﾝﾊﾟｲﾙ時に決定されてるからな
このｽﾚに池沼たちは、いつもなにをいってるか意味不明なﾜｹ

436:デフォルトの名無しさん
18/09/14 22:07:36.57 YK4Q2JFR0.net
>>420
こういうtypoをツッコむのは本来嫌いなんだが、せっかく燃料投下してくれたお礼に一応指摘。
「ｸﾞﾛｰﾊﾞﾙを定数値をもたせたい」
毎回言うけど、C言語の前に日本語勉強したほうがええで。

437:デフォルトの名無しさん
18/09/14 22:09:30.41 fXySkelb0.net
低学歴知恵遅れが指摘できるのはこの程度
自分の著しい頭の悪さを棚にあげるからな
ｸﾞﾛｰﾊﾞﾙに定数値をもたせたい
とまともな日本語読解能力があれば
普通に読めるからな

次ページ