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/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 中に読み書きすればよいのではないですか？

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

OSカーネルの実装以外では、命令自体の atomic 性に期待するのではなくて、
ちゃんと、OS が用意している API や system call を使って、CriticalSection
的なブロックを作って、その中で読み書きするのが基本ではないですかね。

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

>>686
それで十分ならそれでいいよ
無理して難しいことしなくていい

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

MotherBoard上にもキャッシュがありますし、マルチコアではなく、マルチCPUの
環境だと、いくらCPUがatomicに書いているつもりでも、バスでつながっている
他のCPUのキャッシュには反映されていない可能性もあるのではないでしょうか。

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

>>689
だから難しいこと気にしなくていいって
だまってCriticalSection使ってろ

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

お前のバカなところはてめぇの無知を自覚せずに
atomicは不要というぶったぎり論を始めたところだ
もしいい年したおっさんなら芽がない

◆QZaw55cn4c · 2020/05/06(水) 14:52:33.37

>>689
＞MotherBoard上にもキャッシュがありますし
それは Pentium 世代でしょうね、PenII 世代からはマザーにキャッシュを乗せるというのはきいたことがありません

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

>>691
そんなに物知りなら、こんなところで聞かずにIntelマニュアルでも調べたら分かることじゃないか。

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

はっきり言って、ここで double 値への書き込み atomic だなんて言ってる人の言うことはどこまで信用できるか分からん。
x86 CPU的には、xchg命令など一部の命令を除いてはそんなことは保障されてるかどうか定かではない。

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

>>693
お前こそマニュアル読めよ
メモリ操作にはlockプリフィクスがつけられるんだよ

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

lock prefix は、mov 命令には付けられないがな。

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

データ競合と競合状態ごっちゃにしてない？

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

アトミックはいわゆるout of thin airな値の発生を防ぐためのもの
それ以上でもそれ以下でもない

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

std::atomic の意味付けとごっちゃになるから、「割り込み不可」「不可分」あたりと使い分けてほしいなぁ。

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

もしかして、
double　　g_dbl[1024];
に対して、何かの値を足すような動作を、2つ以上のスレッドで
分担して行うことで高速化しようとしているのか？
そんなやり方は、マルチスレッドプログラミングでやっていいのだろうか。
普通は、要素番号 0～511 までをスレッド1が、512～1023 までをスレッド2
が計算して高速化する。
全く同じ場所に複数のスレッドが書きこむことは原則としてやらないはずだ。

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

>>701
GPGPUを使ったレイトレーシングでも、画面上の別のピクセルをそれぞれのコアが
計算するのが原則で、1つのピクセルを複数のコアが分担して計算するには、それなりの
工夫がいる。
工夫というのは、途中までは別のワーキングエリアに書きこんでおいて、最後に
その結果を基本的にシングルコアで足し合わせて最終結果とするようなことだ。
これだと、例えば、途中の計算を double型で行うとしても、doubleへの書き込みが
atomicであることは特に必要ない。

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

>>696
そうだけどmovはそもそもatomicじゃん
>>694 で何をいいたいのかわからないな
(ちなみに最近のコンパイラはfpu命令でなくsimd使うのでmovと書いてる)

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

気になったのは、「atomic」というコンピュータサイエンスで用いられている
言葉を >>611 のように実際のCPUで出来ているかどうか質問していること。
IntelのCPUマニュアルでは、atomicという言葉は使わずに、#LOCK PINアサート
が立つかどうかや、キャッシュコヒーレンシー、といった言葉で説明されている。
「atomic」という言葉は、キャッシュなどが「無いものとして分かり易く」
理解するには有効であるが、実際のCPUではキャッシュの一貫性や、PCIバス規格
と絡んだ詳細な説明が必要となる。
何を持って「atomic」というか、という問題が起きるからだ。

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

>>702
movも、実際のCPUでは必ずしもatomicとは限らない。
まず、alignment 境界を跨いででいるような場合や、
物理的に複数のCPUがマザーボード上にある場合のキャッシュの一貫性の問題が
あるから。
Intelの最適化マニュアルなどで、マルチコア並列化の例として上がってないような
方法は、勝手にやると破綻するかもしれない。
実機で実験してやるのは自由だが、他の人のCPUでは誤動作するのは覚悟した方がいい。
「アメリカ人は、書いてないものを勝手に使ったあなたが悪い」
という思想だぞ。

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

>>704
マニュアルに安全な具体例として載ってないから疑ってるって話ね
ご自由にどうぞ
でもそれはあくまでお前の判断
メジャーコンパイラがintelのサポートうけてないとは思えないから
おれはコンパイラの出力眺めてみるけどね

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

>>705
並列化の処理は研究されているから、Intelが例として一度も書いてないんだったら
多分やめた方がいいと思う。

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

>>703
atomicとコヒーレンシーや同期がごちゃまぜになってる

もうちょっと勉強するか
素人なら素直に既にある同期や排他制御の仕組みを使いなさい

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

色々な理由でやむを得ず使う上級者の技を
素人がまねしなくて良い

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

>>706
ちなみにメジャーコンパイラが
std::atomic<double> ＆ std::memory_order::relaxed
をどう展開するか知ってるんだよね？
これを疑ったらコンパイラを自作するしかないんでは？

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

>>709
そのoperator=()関数は、store() 関数を使っていて、その関数は lock(), unlock()
で囲ってから書き込みをしている。

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

>>710
そりゃご愁傷様
おれの環境だと普通にmovqだけどね

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

>>711
だったらそれでいいじゃない。

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

>>712
おれは最初から困ってないしw
お前がいろいろ大丈夫かよ

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

ちょっ（キャッシュの）一貫性とアトミック（なアクセス）は別概念なのでは…
後者はあくまで>>664の括弧内の意味
一貫性が保証されている単一キャッシュライン内のデータに対するアクセスでも
アトミックでないケースが理論上はありえる

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

なんで揉めてんだか訳わかんね

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

つか同一キャッシュラインに乗っているからといって
配列アクセスは非アトミック、

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

>>679
じゃあ電話交換機のプログラマーとか？

災害に際して実際に活躍したシステムの例を引き合いに出したのに
なんで白昼夢スレに誘導されるのかがわからん…

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

C++でdoubleで同期取ろうとしてることすら意味不明なんだがキミたちは結局何がしたいんだい？　
処理系依存するものはOSの同期を使えよ。

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

>>703
atomicっていう言葉は使われてるが
https://xem.github.io/minix86/manual/intel-x86-and-64-manual-vol3/o_fe12b1e2a880e0ce-258.html

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

同期がめっちゃ遅いから困ってんだってよ

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

同期は遅くて当たり前だろ。
並列化したら速くなるとか同期コスト知らないIT音痴の妄想なんだから。

処理系依存していいならIntelのTSX試せよ。

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

同期を速くするのは無理だぞ
高速化したければ同期を減らすんだぞ

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

>>718
できるかどうかと
やるべきかどうか
は別の話
区別しようぜ

**843** · 2020/05/06(水) 21:51:51.19

Atomicの話と同期の話の区別も宜しくねw

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

>>718
誰もdoubleで同期を取るなんて話はしてない
atomicなアクセスの話題

>>716
複数ならSIMDレジスタを使う
YMMなら4個、ZMMなら8個までatomic

**デフォルトの名無しさん** · 2020/05/07(木) 00:01:22.08

同期をとればatomicである必要はない
そういうことじゃないのか

**デフォルトの名無しさん** · 2020/05/07(木) 00:24:54.15

話をまとめるとこうなる。

・8byteの読み書き命令がatomicかどうかは処理系依存する話でC++の話ではない。スレチだが聞くならチップを指定して聞け。チップ仕様見れば答えは出る。議論の余地はない。
・8byteの読み書きを同期したい、atomicにしたい。OSの同期か適当な同期ライブラリ使え。悩む余地なし。
・atomicと同期は話は別だ　→ありえないw ハードでatomic命令の実装に同期が必要だし、ソフトの同期処理の実装にCPUのatomic命令を使う。atomicの実装を知りたければVHDLスレにでも行け。
・馬鹿は同期を理解できない←30年前から言われてる名言。C++スレでdoubleがatomicかというアホ質問自体が証左。

**デフォルトの名無しさん** · 2020/05/07(木) 01:03:56.90

EOF

**デフォルトの名無しさん** · 2020/05/07(木) 01:11:02.02

>>719
なんだ、そこにそのまま書いてあるじゃない。
つまり、alignされているなら quadword は atomically に Read/Write できる。
キャッシュラインの中に納まっているなら align されてなくても OK、と。
8.1.1 Guaranteed Atomic Operations
The Intel486 processor (and newer processors since) guarantees that
the following basic memory operations will
always be carried out atomically:
・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 that
the following additional memory operations will always be carried out
atomically:

・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 that the following additional memory operation will always be carried out atomically:
・Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line.

**デフォルトの名無しさん** · 2020/05/07(木) 06:07:03.34

>>611に対する回答は既に>>673で明確に示されて終わってる話。
それを急に同期の話と勘違いしてとんちんかんな蒸し返し方をした>>680がおかしい

**デフォルトの名無しさん** · 2020/05/07(木) 06:35:21.80

その486の話でいうと、当時、486は自己書き換えコードを駆逐した。Prefetchされたコードは非同期のまま実行されたからだ。Prefetchされたものはメモリではないと言い訳してもPGはそうは思ってないのだから高速なCPUだけ動かないコードがいっぱいあったわけだ。
結局、Intelが折れたのかPenから正しく同期されるようになった。TSXといいIntelも結構やらかしてるし、PICじゃ今でも同期エラッタてんこ盛り。MIPSの実装なんて言わずもがな。

**デフォルトの名無しさん** · 2020/05/07(木) 06:52:28.04

同期って用語の使い方に違和感があるなあ

**843** · 2020/05/07(木) 07:35:15.71

>>732
同意
そもそも486の時代に自己書き換えコードがいっぱいあったとかにわかに信じがたい

**デフォルトの名無しさん** · 2020/05/07(木) 08:02:12.59

8086時代は結構あった
古いコードのおもりをさせられた人は苦痛だったろうね
今よりはるかにパズルコードが多かったし

**デフォルトの名無しさん** · 2020/05/07(木) 08:27:36.65

>>730
atomic命令=排他制御(同期処理)された命令。同義。
doubleアクセスがatomicか知りたい=double値で同期したいと解釈するのは普通じゃないかな。
まぁatomicであろうとなかろうと、C/C++的にはOSの同期オブジェクト使えって結論になるわな。
マルチスレッドの再現性ないバグの99%は同期のおれおれ実装が原因だし。

**843** · 2020/05/07(木) 09:26:23.94

アトミックと排他制御と同期処理って同じじゃねーぞ
doubleでアトミックと言うのは例えば
double d = 1.23;
…
d = 2.34;
ってやった時にdが1.23と2.34以外の値にならない事を言う
どっちの値になるかまでを保証するわけじゃない

**デフォルトの名無しさん** · 2020/05/07(木) 09:34:04.25

何に基づいた主張なのかわからない
論拠も書くべき

**デフォルトの名無しさん** · 2020/05/07(木) 09:50:51.36

>>736
おれは同じ意味で使ってるし、
世界の技術者もそうだからボクたちに合わせてくれないかな。

**デフォルトの名無しさん** · 2020/05/07(木) 09:53:56.60

>>735
> まぁatomicであろうとなかろうと、C/C++的にはOSの同期オブジェクト使えって結論になるわな。

お前 ID:lE4/XlkX だよね？

**843** · 2020/05/07(木) 10:01:49.95

>>738
> おれは同じ意味で使ってるし、
それは勝手にしてくれ、どうせ人の言うことを聞かないだろうし
> 世界の技術者もそうだから
妄想乙w

**デフォルトの名無しさん** · 2020/05/07(木) 10:21:20.74

>>739
単発IDのくせにいなきり「お前」かよ。GWはほんと口の聞き方も知らないリアルクズ野郎ばかりだな。
おまえのような礼儀も知らず妄想しかできない低能クズに寛容なるおれ様が特別に教えてやろう。

違いますよ^^　礼儀を知らない馬鹿は二度とおれにレスすんなw

**デフォルトの名無しさん** · 2020/05/07(木) 10:32:16.12

同期とアトミックと排他制御が同じとは
ヤバいのがいるなこのスレ

ソフトウェアの基礎を学んだ方が良い

**デフォルトの名無しさん** · 2020/05/07(木) 10:36:17.88

個人的に並列化処理といえば、例えば2coreの場合、
double buf[1024];
の内の、0-511 までを core1、512-1023 までを core2で処理するものだと思っていた。
atomicであるかどうかを気にしている人は、
buf[0] を core1とcore2で
[core1]
for(・・・) {
　buf[0] += 1.0;
}
[core2]
for(・・・) {
　buf[0] += 1.0;
}
みたいに同時に書きこみたいと思っているの？？？？
でも、atomicというのは、書き込みのみ、または、読み込みのみ、のどちらかの
場合だと適用できるけど、↑のコードの場合、+= 演算子は、直前の値を読み取ってから、
1.0 を足して、同じ場所に書きこむ動作をするので、いくら、double値の書き込みが
atomicであっても、結果はめちゃくちゃになるよ。

**デフォルトの名無しさん** · 2020/05/07(木) 10:45:35.17

>>741
- std::atomicの使いどころを理解してない
- "OS"の同期プリミティブを使えと主張 (なぜOSと限定？)

この二つの条件を満たす別人が現れる確率は結構低いと思ったんでね
非礼の詫びとしてatomicの使いどころ知りたかったら教えてやるけどどう？

**デフォルトの名無しさん** · 2020/05/07(木) 10:50:13.38

>>743
そんなraceばりばりの例だめにきまってんじゃん
単純に一方がwriter、他方がreaderでもatomic性は必要でしょ

**843** · 2020/05/07(木) 11:13:09.18

>>743
> atomicであっても、結果はめちゃくちゃになるよ。
+= の話はレイヤーが違う
2 threadで元々0.0の変数に各々 += 1.0を10回実行した時に結果が20.0増えないことがあるって言う話をしてるんだろうけど結果は1.0~20.0に範囲になる
>>611のは浮動小数点フォーマットとして正しいかどうかもわからん

**デフォルトの名無しさん** · 2020/05/07(木) 11:20:48.41

std::atomic<double>はoperator+=ないね

**デフォルトの名無しさん** · 2020/05/07(木) 12:09:28.57

>>746
>>611のは浮動小数点フォーマットとして正しいかどうかもわからん
それも、個人的には分かっているつもり。

**デフォルトの名無しさん** · 2020/05/07(木) 12:11:04.76

>>745
>単純に一方がwriter、他方がreaderでもatomic性は必要でしょ
確かに必要だね。
でも、個人的には具体的にどういう利用例があるのか分からない。

**843** · 2020/05/07(木) 12:17:56.15

>>748-749
書き込みスレッドが書き込んでいるデータを読み出しスレッドが読み出して表示する
とかの場合アトミックでないと不正なデータを表示してしまう
計測器等でありがちな処理だよ

**デフォルトの名無しさん** · 2020/05/07(木) 12:53:58.73

>>749
一番原始的なスレッド通信

>>743
複数命令を使って事実上アトミックに出来るCPUもあるし
整数ならアトミック加算出来る命令があるCPUもある

ARMやMIPSは前者、x86は後者

**デフォルトの名無しさん** · 2020/05/07(木) 17:00:45.03

C++に限ったことじゃないかもしれないんですけど質問させてください
typedefで型に別名つけることについてです。今いじってるコードでたとえばvector<animal>にanimalsって型名をつけるようなのが山のようにあるんです
これすごくわかりにくいなと思います。例えばvector<animals>で宣言されてればその変数にどんな操作ができるのか一発ですが突然animalsで宣言されても何ができる型なのか初見では分かりません
別名をつけることがメリットになることってあるんでしょうか

**デフォルトの名無しさん** · 2020/05/07(木) 17:14:48.12

メリットは君が言ってる通り特定の言語に限った話では特定の回答は出て来ないし
言語を取り巻く環境(エディタや統合環境や諸々)でも答えは変わってくる

◆QZaw55cn4c · 2020/05/07(木) 18:04:16.36

>>752
using animals = std::vector<animal>;
わたしも、こういう typedef はしない方ですね、リッチなエディターを使っていないせいかもしれません
書いた人は別名を細かく付けた方がいいと考えているようですが、こういうのは記述の粒度の問題かもしれませんね

**デフォルトの名無しさん** · 2020/05/07(木) 18:08:47.80

>>752
例えば後からvectorじゃなくてlistにしたいなーと思ったときに修正箇所が一箇所で済む

**デフォルトの名無しさん** · 2020/05/07(木) 18:14:03.65

テンプレートで使うからでは。

**デフォルトの名無しさん** · 2020/05/07(木) 18:29:01.78

>>752
書くのが簡単になり、見るのも分かり易くなることがある。
また、animal_s とちゃんと最後に複数形を現す「_s」を付けるという
自分なりの命名規則を付けておけば、vector<animal> のことである
こともすぐに分かる。

**デフォルトの名無しさん** · 2020/05/07(木) 18:31:07.04

>>757
なお、型名は小文字ではなく、Animal か、CAnimal、TAnimal のようにするのが慣例。
vector<Animal> の場合、AnimalVector とすると、書くのも理解するのも楽になる。
templateのままをコード中に大量に書くとわずかな書き間違いで変な動作になりかねない。

**デフォルトの名無しさん** · 2020/05/07(木) 18:36:04.65

>>758
templateは、C++の中でも最も複雑で、書き間違えたときのエラーが理解しにくい
とされる部分。
だから、vector<Animal>とコードのそこかしこに書きまくるのはお勧めしない。
それと、<や> は、キーボードの配置からして打ち込みにくいという事情もある。
指が届きにくい場所にあるというか。
また、vector<Animal
と> を書き損じたような場合、>を探してコンパイラが変な場所でエラーを出して
しまい、どこでエラーが始まったか探し出すのに苦労するようなこともある。
だから、このような「組み立てられた型」は、毎度毎度そのまま使うと痛い目に
遭う可能性があるので、animals と typedef した人は賢い。

**デフォルトの名無しさん** · 2020/05/07(木) 18:37:12.86

>>744
レスするなと言ってるのにほんと人の話を聞いてないな。だから別人だって言ってるだろう。
std::atomicの使いどころってstd::atomicの話題に一度もレスしてないし、std::atomicの話を振られてもいない。

しかもOS限定とか妄想そのもの。
> OSの同期か適当な同期ライブラリ使え。悩む余地なし。
と最初に言ってる。逆にキミのその発言で、キミは今まで禄にコードを書いたことのない糞ガキの学生ということがよくわかったよ。

仮にOS提供の同期機構かstd::atomicかという選択であっても1nmもstd::atomicの選択余地はない。0%だ。
枯れてないライブラリは論外。同期バグはOr****やIntelでもやらかすし、枯れてるほうを使う。
何十年もカーネル開発者が注力し、コキ使われてきた実績のある同期コードを選ぶのがまともな社会人。
キミのような無責任な子供やテストしないOSSな人じゃないからね。OS提供がなくても同じ。
組み込み系ならチップメーカーが提供する同期ライブラリを使う。

**デフォルトの名無しさん** · 2020/05/07(木) 18:39:12.04

命名規則は、animals よりも、
vector<animal> の時には、AnimalVector
list<animal>の時は、AnimalList
とするのがお勧め。
最後の s だけだと、見落とす可能性があることと、集合体であることだけは
分かっても、それが、どんな種類の集合体かまでは分からないため。

**デフォルトの名無しさん** · 2020/05/07(木) 18:42:48.91

もうひとつ、vector<animal> より、AnimalVector とした方がいい理由は、
正規表現検索する場合のため。
正規表現だと、< や > は何らかの meta 表現的な意味を持っている場合があるかも
知れないので、型名は単純な alphabet 列の方が何かと便利。