C++相談室 part150

**デフォルトの名無しさん** · 2020/03/24(火) 00:04:33.93

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part149
https://mevius.5ch.net/test/read.cgi/tech/1581974381/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

テンプレここまで

**デフォルトの名無しさん** · 2020/05/01(金) 19:22:30.31

32bit Windowsが4GBまでなのはWindowsの仕様であってCPU自体はそんな縛りは無いし

**デフォルトの名無しさん** · 2020/05/01(金) 19:51:53.68

>>587
典型的には、32BIT mode でも、PAE サポートによって OS は 4GB を超える
メモリーを扱えるね。

**デフォルトの名無しさん** · 2020/05/01(金) 20:58:17.99

64GBまで使えるようになったのPentium Proからだぜ？ｗ
Klamathより前！！

**デフォルトの名無しさん** · 2020/05/02(土) 00:04:20.13

>>547
釣り針でかいなw ここム板だぜw

**デフォルトの名無しさん** · 2020/05/02(土) 00:05:14.57

>>587
おまえ嘘ばかりだなw

**デフォルトの名無しさん** · 2020/05/02(土) 01:38:26.25

>>591
いや、彼は正しいことを言っている。
あなたがIntel CPUの仕様を詳しく知らないだけ。
PAEという仕組みなどで32BITモードでも4GBを超える物理メモリーを扱うことができるようになっていた。

**デフォルトの名無しさん** · 2020/05/02(土) 01:45:40.91

PAEが何なのか全く分かってなさそう

**デフォルトの名無しさん** · 2020/05/02(土) 02:28:22.28

QZは女なのだろうか。
ショックかも知れないがはっきり言えば、本質的に物事が正確に理解できていないようだ。

**デフォルトの名無しさん** · 2020/05/03(日) 09:20:54.04

EMSなら前に聞いたことがある

**デフォルトの名無しさん** · 2020/05/03(日) 09:24:35.32

8bit CPUは256Bしか扱えないと思ってる人いる？

**デフォルトの名無しさん** · 2020/05/03(日) 09:29:47.71

16bitのCPUでも16bitアドレスの最大値である64KBを超えて1MBもアクセスできていたからな。

**デフォルトの名無しさん** · 2020/05/03(日) 10:03:25.11

>>594
女なら180度対応を変えます

**デフォルトの名無しさん** · 2020/05/03(日) 10:22:47.73

>>597
16BIT CPU であった 8086は、16bit アドレスを超える範囲は、セグメントレジスタ
と合わせた seg:ofs の形式の far pointer を使わなくてはならならず、
単純に扱えるのは16BITまでで、16BITを超えた範囲では、seg レジスタの値を
足していかないといけなかった。しかも、segがアドレスの上位16BITだったなら
まだしも、16バイト単位のアドレスだったので、segレジスタに入れる値を計算
するのがとても重くなってしまっていた。
ところが、Z80 などの 8BIT CPUは、普通に 16BIT レジスタの
HL や DE, BC, IX, IY をもっており、8086 と比べれば扱いは容易だった。
その意味では、8086は、メモリーアクセスに関してはZ80と同じくらいしか
能力を持っていなかった。
それで8086の16BITモードでは限界が来て32BITモードのOSが待望された。
そしてMacのGUIを真似た機能を持っていたこととも合わせて32BITモードで
動いたWin95となった。

ただし、このような状況は64BIT化に関しては全く無い。

**デフォルトの名無しさん** · 2020/05/03(日) 10:32:19.81

そりゃまあ、64bitCPUがすでにいきわたっていてOS変えるだけで対応できたからね
WINAPIだって16→32のコンパイルはまず動かないけど32→64なら普通は動く
DOS時代のUMBみたいなみみっちい事態にならなくてよかったじゃん

**デフォルトの名無しさん** · 2020/05/03(日) 10:35:22.17

86用コンパイラでnearとfarの他にhugeが有ると知らず、無限ループ作ってOSごと来なくなったあの頃

**デフォルトの名無しさん** · 2020/05/03(日) 11:16:28.83

結局64bit CPUだと速度4倍のコードは？

**デフォルトの名無しさん** · 2020/05/03(日) 13:08:16.85

long longとint64_tの違いってlong longは環境によって64bitじゃなくなるけどint64_tは常に64ってことですか？

**デフォルトの名無しさん** · 2020/05/03(日) 13:13:36.85

>>603
まあ、そういうこと。

**デフォルトの名無しさん** · 2020/05/03(日) 14:04:07.52

　　　　　　　　　　　|
　　　　　　　　　　 |　　彡⌒ミ
　　　　　　　　　　　＼ (´･ω･`)　またhugeの話してる・・・
　　　　　　　　　　　　　(|　　　|)::::
　　　　　　　　　　　　　(γ　/:::::::
　　　　　　　　　　　　　　し＼:::
　　　　　　　　　　　　　　　　　＼

**デフォルトの名無しさん** · 2020/05/03(日) 14:24:10.29

>>604
ありがとうございます

**デフォルトの名無しさん** · 2020/05/03(日) 15:56:11.79

32bitの環境で32bitの境界を超えるような64bit値の計算ってどうやって実現してるの？

**デフォルトの名無しさん** · 2020/05/03(日) 16:00:56.90

cpuに命令なければソフト的にやるに決まってんじゃん

**デフォルトの名無しさん** · 2020/05/03(日) 16:06:34.35

ちなみに32bitの掛け算の答えに64bit必要ってわかってない人多いよね
同様に64bitなら128bit

**843** · 2020/05/03(日) 16:22:11.00

>>607
まずは筆算の足し算からやり直そうか

**デフォルトの名無しさん** · 2020/05/03(日) 16:54:49.03

64bitだとdoubleとかの書き込みはアトミックになるの

**デフォルトの名無しさん** · 2020/05/03(日) 17:17:29.21

C/C++にキャリーフラグ観る機能が無いのはなせ？

**デフォルトの名無しさん** · 2020/05/03(日) 17:56:41.69

アトミックにしたけりゃstd::atomicを使え
使わない場合は保証されない

**デフォルトの名無しさん** · 2020/05/03(日) 18:16:14.79

>>612
いれるとしたらどんな仕様でいれる？
そこまで考えてから書いてみたんだよな？

**デフォルトの名無しさん** · 2020/05/03(日) 18:19:51.49

>>613
64bitでない環境だとatomic持ち出したところで使えないじゃん

**デフォルトの名無しさん** · 2020/05/03(日) 18:25:40.26

使えるぞ
内部でロックするから遅いけど

**デフォルトの名無しさん** · 2020/05/03(日) 20:09:19.86

>>598
90度だろ？

**デフォルトの名無しさん** · 2020/05/03(日) 20:16:01.21

モダンc++入門ってどこみたらいい？

**デフォルトの名無しさん** · 2020/05/03(日) 21:01:49.43

cpprefjp

**デフォルトの名無しさん** · 2020/05/03(日) 22:43:31.73

>>611
ほとんどの環境でYES
32bit CPUでもアトミックな環境もある

**デフォルトの名無しさん** · 2020/05/03(日) 22:46:00.66

>>612
キャリーフラグが無いCPUも有るから
CPU固有の機能はintrinsicを使う

**デフォルトの名無しさん** · 2020/05/03(日) 22:52:17.09

>>609
整数の乗算を全範囲正確に求めたい場合の話だな
これもC++では書けない
intrinsicを使う

**デフォルトの名無しさん** · 2020/05/03(日) 22:53:53.78

>>617
なんで90度？
180度だって書いてるのに

**デフォルトの名無しさん** · 2020/05/04(月) 03:33:26.41

int128でもint256でも自由に型が作れるのがC++の強みなのに書けないってw

**デフォルトの名無しさん** · 2020/05/04(月) 06:12:26.01

int_<256>みたいの作ってたけど
サイズが発散する問題がすぐ起きる

**843** · 2020/05/04(月) 07:19:32.37

>>620
> 32bit CPUでもアトミックな環境もある
具体的な環境名教えて

**843** · 2020/05/04(月) 07:20:47.92

>>623
（女は）話をはぐらかすって事だろ

**デフォルトの名無しさん** · 2020/05/04(月) 07:22:03.70

x86

**デフォルトの名無しさん** · 2020/05/04(月) 08:03:18.75

shared_ptr<Hoge>をvoid *の領域に格納したいのですがどうすればいいでしょうか？
SetPointer(void *),void* GetPointer()で設定します
shared_ptr<Hoge> hoge
として
SetPointer(hoge)

取り出す時
shared_ptr<Hoge> hoge = GetPointer()

**デフォルトの名無しさん** · 2020/05/04(月) 08:04:47.44

後、SetPointerする前にshared_ptrの参照カウントを一つ増やしたいです。

**デフォルトの名無しさん** · 2020/05/04(月) 09:54:06.17

>>629-630
所有権込みで格納したいだけなら。
SetPointer(new shared_ptr<Hoge>(hoge));
shared_ptr<Hoge> hoge = *static_cast<shared_ptr<Hoge>*>(GetPointer());
あとはどうにか delete が抜けないようにする。

**デフォルトの名無しさん** · 2020/05/04(月) 10:27:13.66

本当にshared_ptrごと格納する必要があるの？
これで良かったりはしない？

shared_ptr<Hoge> p(new(buffer) Hoge, [](Hoge* p){p->~Hoge();});

**デフォルトの名無しさん** · 2020/05/04(月) 11:04:11.62

つまりshareする気がないけどshared_ptrを使いたいわけだな

**デフォルトの名無しさん** · 2020/05/04(月) 11:24:26.33

誰かと食べる気はないけど、マックのシェアポテトを食べたい感覚だね

**デフォルトの名無しさん** · 2020/05/04(月) 12:42:16.41

>>632
これ難しすぎて解読できません

まず、やりたいことはWindowsのTreeViewでノードを追加するときに、ノードにLPARAM型の任意のデータを関連づけれるんですが、そこに他の関数から受け取ったshared_ptr<Hoge>を関連付けたいのです

shared_ptrごと格納する必要ないと言えばないのかもしれません
でも中身だけ格納すると、deleter?の情報がとんじゃう?

**デフォルトの名無しさん** · 2020/05/04(月) 12:55:51.13

>>631
こっちの方で後で試してみます

**デフォルトの名無しさん** · 2020/05/04(月) 13:16:44.39

なにがしたいのだかいまいちよくわからない

**デフォルトの名無しさん** · 2020/05/04(月) 13:20:23.37

所有したいのか/参照持ちたいだけなのか
shared_ptrとして使う必要があるのか
参照だけ持ちたいとしてダングリングの可能性が有るのか

**デフォルトの名無しさん** · 2020/05/04(月) 13:46:24.04

あーあ。shared_ptrごと格納できるならそっちの方がいいです。
そうしないと誰が最後にdeleteするかめんどくさくなりなすね。
すみませんでした

**デフォルトの名無しさん** · 2020/05/04(月) 13:47:34.57

TreeViewが持つのはポインタだけで、オブジェクトの寿命管理するわけじゃないんだろ？
だったらshared_ptrのdeleterの情報なんか渡す必要ないんじゃないか
オブジェクトの寿命管理する奴が知ってればそれでいい

**デフォルトの名無しさん** · 2020/05/04(月) 13:56:33.16

>>639
shared_ptrはlparamに収まらないから無理
sizeofで確かめてみ

**デフォルトの名無しさん** · 2020/05/04(月) 14:01:15.39

すみません。何か頭混乱してきた・・
>>630が余計だったのか・・

まず、基本方針としてオブジェクトの寿命管理を楽にするためにクラス間でデータをやり取りする場合は
全部shared_ptr経由で参照カウントにより自動で管理してもらおうという方針です。

ですが、既存のライブラリとの都合で例えば、今回のTreeViewのノードにはLPARAM型のデータしか関連づけらられない
ということで、ノードに関連づけるときに参照カウント手動で？増やしてあげて、ノードを削除するときに、
参照カウントを手動で減らして？あげて調整するものなのかなぁーと思った次第です。

**デフォルトの名無しさん** · 2020/05/04(月) 14:02:14.17

データの本体は別にあってそっちで所有権管理しているなら、treeviewにはshared_ptr::getで得られるpointer持たせればいい
使う側でshared_ptrである必要があるなら、shared_from_this使う

ダングリングする可能性無いならならこれでおk

**デフォルトの名無しさん** · 2020/05/04(月) 14:12:18.91

void*で渡しちゃう以上はTreeViewに参照カウント減らさせるのは不可能なので、そこは外側で管理してやるしかない
だったらTreeViewはshared_ptrがどうのこうのという情報は知らなくていいし、知らせるべきでない

**デフォルトの名無しさん** · 2020/05/04(月) 14:19:40.83

>>644
TreeViewってのはWindowsの既存のコンポーネントだろ
ちょっとまとはずれだよ
答えは >>631 で出てる

>>639
手動deleteが本当にいやならあとは黒魔術使うしかないね
unique_ptrなら64bitにおさまるだろう

**デフォルトの名無しさん** · 2020/05/04(月) 14:23:16.16

>>645
既存のコンポーネントだからだよ
shared_ptrのこと知らんやつにshared_ptr渡したってろくなことにならんだろ

**デフォルトの名無しさん** · 2020/05/04(月) 14:33:47.37

>>646
荒らしたくないがもうちょっと質問者の内容くみとってから返事書いてやれよ
shared_ptrの型で渡すんじゃなくてvoid*の型で渡すって最初から言ってんじゃん

**デフォルトの名無しさん** · 2020/05/04(月) 14:47:05.48

何が気に食わなくて噛み付いてるのかよくわかんないけど
TreeViewはshared_ptrのことなんか知らないんだから、そんなものは知らせずに
関連のあるデータを与える(要はshared_ptr<Hoge>*じゃなくてHoge*を渡す)方が設計すっきりするんじゃない？
って言ってるだけなんだがそんなにおかしいか？

**デフォルトの名無しさん** · 2020/05/04(月) 14:51:53.81

何か追加して問題が出て別の何か追加して解決するの繰り返し
C++の仕様は余計なものが多い
メモリーの所有権の移動とかの暗黙知の極みを気にできるくらいならdelete忘れることはないだろうに

**デフォルトの名無しさん** · 2020/05/04(月) 14:57:19.53

Hoge* 渡して済むなら最初から相談なんて発生しないだろうと思ってたんだけど、
>642 みたいな「基本方針」だと shared_ptr の必要性が胡散臭いんで、確かに
Hoge* で済む可能性もありそうな気がしてきた。

**デフォルトの名無しさん** · 2020/05/04(月) 15:00:15.13

>>648
shared_ptrでわたってくるものをvoid*で管理したいってことで
それは質問の前提条件
解としてHoge* にするってのは破綻するからダメでしょ

**デフォルトの名無しさん** · 2020/05/04(月) 15:10:46.19

>Hoge* 渡して済むなら最初から相談なんて発生しないだろう
そうです。Hoge*で渡したくないから質問した次第です。

元のデータが先に捨てられようと、先にTreeViewのノードが破棄されようと、どっちが先でも
OKなように、それらを意識しないようになるべく参照カウントの仕組みで破棄したかったわけです。

**デフォルトの名無しさん** · 2020/05/04(月) 15:22:06.17

だったら>>631も、結局TreeViewの破棄を監視して破棄前にdelete GetPointer()かけないといけないんだけど
それでもいいのか？本当に意識すべきことは減ってるのか？無用な複雑さを持ち込んでるだけじゃないのか？
っていうことを一回冷静に考えた方がいいよ

**デフォルトの名無しさん** · 2020/05/04(月) 15:23:27.04

逆にHoge*で受け取って、
Tree破棄時にPointer破棄処理省いてしまって、
あとはsharedのスコープで全消しすればいい
もちろんノード追加時に参照カウンタ増やす必要もない

**デフォルトの名無しさん** · 2020/05/04(月) 15:24:48.96

>>653
それは問題ないです。
>>642に
>参照カウントを手動で減らして？あげて調整する
って元からそれをやる前提でした

**デフォルトの名無しさん** · 2020/05/04(月) 15:44:09.03

前調べたら
https://docs.microsoft.com/en-us/windows/win32/controls/tvn-deleteitem
ノード削除時に発生するイベントがあるので、ここ1か所にかくだけでいいのかなと
思ったので、その方が分かりやすいかなと思った次第です

てか、この方法駄目そうですね？
>delete GetPointer()
じゃなくて、参照カウントを減らしたいんですけど、無理っぽいのかな・・
COMならAddRef,Releaseで調整できるんですけど

もうちょっと調べて駄目そうならHoge*でいきます

**デフォルトの名無しさん** · 2020/05/04(月) 15:54:22.23

>>656
new した shared_ptr を delete すれば参照カウント減るよ。
でも Hoge* で済むならそっちで済ませたほうが面倒も無くて効率もいいだろうよ。

**デフォルトの名無しさん** · 2020/05/04(月) 16:04:26.16

そもそもTreeViewってViewだから見た目を整えるための奴でしょ
自分ならロジックデータの寿命管理にそんな奴参加させたくないな

まあ、削除時のコールバックが指定できるんだったら、それで後始末するのも手ではあるかもね
小さいプログラムで、見た目の要素の何かとHogeが論理的に一対一対応してるんだったら許容範囲かな

**デフォルトの名無しさん** · 2020/05/04(月) 16:11:26.04

>>653
質問者はクラス間で共有するデータは一律shared_ptrにすると言っている
これは全体設計の選択としてまぁある話

しかしこれによって既存コンポーネントのTreeViewで
インタフェースのミスマッチが起こった、さてどうしたらいいでしょう？
という質問なわけ
これもよくある問題

だからって全体設計のポリシーをとりやめようとはならのよ
解決できる手段があるなら部分的な問題は個別に解決したらそれでいい

**デフォルトの名無しさん** · 2020/05/04(月) 16:29:01.02

>>659
言ってることは分かるけど
それでどうしてTreeViewにshared_ptrを埋め込むことに固執するのかがわからない
そこはおとなしくTreeViewには生ポで参照してもらうっていうのも一つの「部分的な問題の個別解決」じゃないの？

**デフォルトの名無しさん** · 2020/05/04(月) 16:58:42.06

Linux でのライブラリについて質問があります。
静的リンクライブラリ（拡張子が.aのファイル）は複数のオブジェクトファイル（拡張子が.oのファイル）を ar コマンドでアーカイブしたものと理解しています。
一方自分で調べた限り、動的リンクライブラリ（拡張子が.soのファイル）を作る場合には gcc を用いる場合は-shared （と-fPIC ）を指定して一つのソースファイルから一つの.soファイルを作成しているように思います。
例: g++ -shared -fPIC -o sample.so sample.cpp

この理解の上で質問です。
動的リンクライブラリは静的リンクライブラリのように一つのファイルにまとめられないのでしょうか？ソースの数だけ.soファイルが出きてしまうのは避けられないのでしょうか？

**デフォルトの名無しさん** · 2020/05/04(月) 17:07:30.46

単に.oを複数与えればいいんじゃないの？
何か問題あったっけ

**デフォルトの名無しさん** · 2020/05/04(月) 17:11:45.42

>>656
汚い手段を避けるなら、
shared_ptr を受け取って保管し、管理用のハンドルを返すクラスを作って
TreeViewにそのハンドルを入れとけばいいのでは。

**デフォルトの名無しさん** · 2020/05/04(月) 17:12:19.55

>>628
ちょっx86やx64でアトミックに読み書きできる（バスサイクルが他コアに割り込まれない）ことが保証されているのは
32 bitまででしかも32 bit境界に整列している場合のみのでは…
ちなdoubleは64 bit

**デフォルトの名無しさん** · 2020/05/04(月) 17:30:50.31

>>662
あっ、それでできるんですか。
ありがとうございます、やってみます！

**デフォルトの名無しさん** · 2020/05/04(月) 18:05:00.17

>>664
64bit境界であることは必須
あとは大昔のCPUじゃなければアトミック

**デフォルトの名無しさん** · 2020/05/04(月) 18:43:33.39

wandbox上だとatomic<double>はロックフリーらしい、多分x86-64環境なら同じ
https://wandbox.org/permlink/0LWMsNPNmSn6rpZ4

**デフォルトの名無しさん** · 2020/05/04(月) 18:54:28.70

>>666
>64bit境界であることは必須
ハア(ﾟДﾟ)？
ていうことは
　char *p = ～;
　*p = 'a';
は、pが8の倍数でなければ非アトミック？？
　short *q = ～;
　*q = 123;
もまた、qが8の倍数でなければ非アトミック？？？

なんと？！

**デフォルトの名無しさん** · 2020/05/04(月) 18:56:20.07

doubleの話をcharに拡大して何がしたいのか

**デフォルトの名無しさん** · 2020/05/04(月) 18:57:04.84

アスペは文脈が読めない

**デフォルトの名無しさん** · 2020/05/04(月) 19:00:17.65

shortだって64bit境界跨いでたら非アトミックだぞ
わざわざ作らなければそんなことにならないだろうけど

**デフォルトの名無しさん** · 2020/05/04(月) 19:06:17.15

つかインテルアーキテクチャーのソフトウェアーデベロッパーズマニュアルによると
「8.1.1 Guaranteed Atomic Operations」
に書いてあったわｻｰｾﾝ；；；；

**デフォルトの名無しさん** · 2020/05/04(月) 19:09:35.51

The Intel486 processor (and newer processors since) guarantees：
- Reading or writing a byte
- Reading or writing a word aligned on a 16-bit boundary
- Reading or writing a doubleword aligned on a 32-bit boundary

The Pentium processor (and newer processors since) guarantees：
- Reading or writing a quadword aligned on a 64-bit boundary
- 16-bit accesses to uncached memory locations that fit within a 32-bit data bus

The P6 family processors (and newer processors since) guarantee：
- Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line

とのことなので「The Pentium processor (and newer processors since) 」ならおk

**デフォルトの名無しさん** · 2020/05/04(月) 19:15:43.74

で、「The P6 family processors (and newer processors since) 」において
キャッシュラインを跨ぐとatomicが保証されない旨がその下に書かれているので、
- Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line
は妄信はできん
やっぱalignedな場合しか信用できん

**デフォルトの名無しさん** · 2020/05/04(月) 19:18:59.34

まあ今時のプロセッサだとキャッシュライン単位でしかdramアクセスしないからそうなるのが自然なんだよね

**デフォルトの名無しさん** · 2020/05/04(月) 20:44:57.79

こういう非常時でも特に誰かがプログラムで社会貢献してるとは聞かないな

**デフォルトの名無しさん** · 2020/05/05(火) 05:46:34.77

アングル：コロナ感染経路、スマホ使った「接触追跡」の最前線
https://jp.reuters.com/article/health-coronavirus-tracing-idJPKCN21X0LE

つかビッグデータ取り扱い系分野は災害時に地味に活躍している印象
ホンダとか東日本大震災翌日からインターナビで収集した情報で被災地の道路寸断マップを
作って公開したんだったと思った（記憶モード
https://www.honda.co.jp/news/2011/4111109.html

**デフォルトの名無しさん** · 2020/05/05(火) 07:41:06.24

ビッグデータを公開してくれれば誰か作るんじゃね

**デフォルトの名無しさん** · 2020/05/05(火) 07:46:04.08

>>677
見た夢をそのまま書くスレ26
https://mao.5ch.net/test/read.cgi/occult/1584792697/

**デフォルトの名無しさん** · 2020/05/06(水) 11:06:32.37

>>611
その変の話は詳しくないので分からないのですが、この質問は、マルチコアやマルチCPUでの話ですか。
前から、その辺は、CriticalSection()などで排他処理すれば問題ないのではないかと思っていたのですが、その変どうなんでしょう？
それとも、自作OSなどで、 CriticalSection()のようなものを自作する場合の話でしょうか？
ちなみに、xor xchg などの話はよく理解できてません。
これらは、複数のCPUが1つのフラグを同時に読み書きした場合の問題なんでしょうか。

**デフォルトの名無しさん** · 2020/05/06(水) 11:15:03.91

>>680
マルチCPUなどの場合は、キャッシュの同期(?)も関係してくるので、
そもそも何を持って「atomic」かどうかということが疑問になってきます。
キャッシュの内側で、CPUが、atomicにキャッシュに書きこんだつもりで
あっても、他の CPU のキャッシュに反映されない可能性があるので意味が
ないように思えます。
となれば、キャッシュ制御まで含めて考えないといけません。
キャッシュも、1次キャッシュ、2次キャッシュ、データ用キャッシュ、
コード用キャッシュ、パイプライン、などものすごく複雑になっているので、
果たしてそういうようなものを含めて「atomic」という言葉ですべてを語ることが
出来るのかどうかも疑問です。

**デフォルトの名無しさん** · 2020/05/06(水) 11:18:02.52

自演かと思ったらレス繋いでるだけか
紛らわしい

**はちみつ餃子** ◆8X2XSCHEME · 2020/05/06(水) 11:26:57.76

>>680-681
https://cpprefjp.github.io/reference/atomic/memory_order.html

**デフォルトの名無しさん** · 2020/05/06(水) 12:03:09.47

>>611の意味は
読み書きの途中で他のCPUやコア、スレッドが別の処理を行う事で一貫性が無くなる事は無いということ

例えばatomicでないと
64bitの一部を書き込んだところで
他のスレッドが値を読んでしまって
64bit全体としてあり得ない値になる
というような事が起こらない
というだけ

同期とか他の読み書きとの順番とか
そういう事はatomicは何も保証しない

**はちみつ餃子** ◆8X2XSCHEME · 2020/05/06(水) 12:24:44.67

データベースとかで言う Atomicity と同じやね。

**デフォルトの名無しさん** · 2020/05/06(水) 14:18:32.19

>>684
あるスレッド書いたdouble値を別のスレッドが読みたい場合
CriticalSection 中に読み書きすればよいのではないですか？