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/07(木) 18:42:48.91

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

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

今どきシステムハンガリアンもどきなんてやだよぅ

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

vectorからlistに変えられなくなる

◆QZaw55cn4c · 2020/05/07(木) 20:14:04.24

>>761
vector から list に変えるときに、名前もいちいち変えないといけないのだったら、その命名ルールは今いちですね…

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

Animalsの話題はわたくしがC++最大の謎と呼ぶvector継承不可問題だ
Javaだと「class Animal extends ArrayList<Animal>{」とできる
でもC++だとvectorそのものの継承はデストラクタの関係で認められていない

つまりクラスを作るかtypedefするか、C++には2通りの解決方法が存在する

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

自分作りゃいいだろ
コンテナくらい

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

別にvector継承してもいいんだよ
protectedかprivate継承する分には何の問題もない
役には立たないけど

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

この程度でs付け忘れるとか不注意にもほどがある

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

いや、vectorは今となっては継承すべきでないってこともないだろ

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

vector<>のデストラクタが仮想でないのは仕様の欠陥ですか？

**はちみつ餃子** ◆8X2XSCHEME · 2020/05/07(木) 21:30:23.98

注意深さに自信があるならデストラクタが virtual でないクラスを public 継承しても
それ自体は言語仕様には反しないけど、人間は間違うのでな……。

>>768
private 継承した上で外部から呼び出しを許すメンバ関数は using すればいい。
役に立たないということはないと思う。

**デフォルトの名無しさん** · 2020/05/08(金) 01:16:40.31

基本的なことだと思うけどよく
よくあるイベントループってどうやったらシンプルかつMT安全かつ効率的に実装できる？
次のような条件で
- qeueuが空ならwaitする
- qeueuにイベントが追加されたら直ちにおきてdispatchする
- dispatchに長い時間かかることもありえる
- add_eventは可能な限り短い処理で完了する。
- stopがよばれたらloopから直ちにぬける。dispatch中の場合は終わってから抜ける。

次に雰囲気コード書きます。

**デフォルトの名無しさん** · 2020/05/08(金) 01:21:33.28

loop()がこれではいかんのはわかってるけど、どうすれば簡潔に書けるのかわからん
他にもあやしいところがある気がする

bool running = true;
std::deque<int> unsafe_queue;
std::mutex mtx;
std::condition_variable cond;
using unique_lock = std::unique_lock<std::mutex>;
void stop() { running = false; }
void add_event(int i)
{
　　unique_lock _(mtx);
　　unsafe_queue.push_back(i);
　　cond.notify_one();
}
void dispatch(int) { /*do something*/ }
void loop()
{
　　unique_lock lock(mtx);
　　while (running) {
　　　　cond.wait(lock, [] { return !unsafe_queue.empty(); });
　　　　auto ev = unsafe_queue.front();
　　　　unsafe_queue.pop_front();
　　　　dispatch(ev);
　　}
}

**デフォルトの名無しさん** · 2020/05/08(金) 03:21:51.97

まずconcurrent_queueを持ってくるなり作るなりして用意した方がいいよ
イベントループにロックやイベント混ぜて書くとわけわからなくなる

**デフォルトの名無しさん** · 2020/05/08(金) 03:34:19.21

イベントって同期イベントね

**デフォルトの名無しさん** · 2020/05/08(金) 03:38:35.90

concurrent_queueは必要ないと言うかこの用途だと無駄な処理増えるだけじゃね

**843** · 2020/05/08(金) 05:40:01.72

>>773
BlockingCollection使えばいいだけじゃねーの？

**デフォルトの名無しさん** · 2020/05/08(金) 06:51:21.78

>>774
それ、イベント発行しないと止まらなくね？

**デフォルトの名無しさん** · 2020/05/08(金) 11:45:01.04

>>775
concurrent_queueって標準であります？どれのこと？
MT安全なqueueクラスを作ると
イベント待ちしてるときのstopで即終了が面倒かなと思いました

**デフォルトの名無しさん** · 2020/05/08(金) 12:06:11.41

>>779
そうなんですよね
runningのチェックって一回のままで実現できないですかね？

**デフォルトの名無しさん** · 2020/05/08(金) 12:18:21.10

>>778
BlockingCollectionってどこにあります？
ぐぐったらC#のクラスは見つかりましたが
上に書いた通り、stop時の処理がまわりくどくなりそうなのを気にしてます
実行時のロジックがシンプルなやり方を追求したいです

**843** · 2020/05/08(金) 12:23:41.84

>>782
> BlockingCollectionってどこにあります？
> ぐぐったらC#のクラスは見つかりましたが
触れちゃ駄目な人だったか…

**デフォルトの名無しさん** · 2020/05/08(金) 12:39:35.76

普通は終了を意味する番兵オブジェクトを用意するんじゃないの
キューの中身を最後まで処理して欲しいなら単に番兵を積めばいいし、無理矢理終わらせたいならキューを強制的に空にしてから番兵放り込めばいい

**デフォルトの名無しさん** · 2020/05/08(金) 13:50:27.60

>>784
なるほどそれだときれいに書けますね
runningフラグは不要にできると

しかしわりとクリティカルな処理を想定してるので
stopを呼ぶスレッドで(イベントオブジェクトの)解放処理が起るのは問題に
なるかもしれないです(例ではintですが実際はもうちょっと凝った構造体)
runningフラグ前提だときれいに書けないですかね？

**デフォルトの名無しさん** · 2020/05/08(金) 17:13:05.00

こんなんでいいのでは。running2回チェックは避けられそうにないなあ。チェックよろ
start() {
{
lock()
running = true
}
run(loop)
}
stop() {
{
lock()
running = false
}
notify()
join()
}
loop() {
lock()
while(true) {
cond_wait(!empty() or !running)
if (!running) {
break
}
pop()
}
}

**デフォルトの名無しさん** · 2020/05/08(金) 17:29:10.43

スレッド動作トリガーはcond 1個にして
スレッド内で、キューやrunningフラグを見る

**デフォルトの名無しさん** · 2020/05/08(金) 17:32:31.56

Windowsみたいな高機能な同期が有れば
イベント、タイマー、ファイルアクセス、ネットワーク通信
などなど色々な物を同時にトリガーに出来る

linux系はその辺が貧弱
スレッドを動かす為のスレッドが必要になったりする

**デフォルトの名無しさん** · 2020/05/08(金) 17:46:30.97

>>788
全部selectやepollでまとめて待てるけど、winはもっと高機能なん？

**デフォルトの名無しさん** · 2020/05/08(金) 18:43:53.40

yes

**デフォルトの名無しさん** · 2020/05/08(金) 19:10:58.40

>>786
インデントつけました

void loop() {
　　lock()
　　while (true) {
　　　　cond_wait(!empty() or !running)
　　　　if (!running) {
　　　　　　break
　　　　}
　　　　pop()
　　}
}

cond_waitの前にrunningみなくて大丈夫ですかね？
startの直後loopが始まる直前でstopが呼ばれた場合cond_waitって起きます？

**デフォルトの名無しさん** · 2020/05/08(金) 19:27:16.63

>>790
違いは同期オブジェクトを含められるかどうかぐらいでは？
それ以外ならlinuxでもたいていfdになってる
少なくとも>>788の後ろ三つは可能
イベントもパイプで代用できることが多い

**デフォルトの名無しさん** · 2020/05/08(金) 20:07:48.20

>>791
cond.waitはブロックする前に一度条件式を確認する動きになってる。
条件式が初めからtrueであればそもそもブロッキングをしないからcond.waitの前にrunningをみなくても大丈夫だと思う

**デフォルトの名無しさん** · 2020/05/08(金) 20:36:08.72

>>793
そうでしたか
ありがとう

**デフォルトの名無しさん** · 2020/05/08(金) 22:51:30.97

もうひとつ質問させてください
>>774 のrunningはstd::atomic_boolにする必要はあります？

C言語だとこの手の変数はvolatileにすると思うのですが
C++ならatomicでしょうか？
上の方でatomicのこといろいろ書いてありますがこの場合はどうなんでしょう？

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

void Foo::pushReq(const XXXReq& req)
{
　EnterCriticalSection(&m_csec);
　{
　　if (!m_bTerminate) {
　　　m_requests.push(req);
　　　SetEvent(m_hEvtNewRequest);
　　}
　}
　LeaveCriticalSection(&m_csec);
}

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

bool Foo::popReq(XXXReq& req)
　for (;;) {
　　if (!m_bInOperation) {
　　　// イベント待機
　　　WaitForSingleObject(m_hEvtNewRequest, INFINITE);
　　　if (m_bTerminate) {
　　　　return false;
　　　}
　　　m_bInOperation = true;
　　} else {
　　　EnterCriticalSection(&m_csec);
　　　{
　　　　if (m_requests.empty()) {
　　　　　m_bInOperation = false;
　　　　　// 今入っているイベントはbInProcess中に入ったもので
　　　　　// 明らかに古いのでリセット
　　　　　ResetEvent(m_hEvtNewRequest);
　　　　} else {
　　　　　// 要求があればpopして処理
　　　　　req = m_requests.front();
　　　　　m_requests.pop();
　　　　}
　　　}
　　　LeaveCriticalSection(&m_csec);

　　　if (m_bInOperation) {
　　　　// 処理すべきリクエスト有り
　　　　break;
　　　}
　　}
　}
}

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

ウィンドーズの同期APIの仕様により
同期API呼び出し時点であらゆる変数のメモリへの書込みとメモリからの読み込みが完了するので
とくにvolatileは不要
なはず、

**デフォルトの名無しさん** · 2020/05/09(土) 06:06:39.41

>>795
>>786のようにrunningの更新をlockで保護するのであればatomic_boolにする必要はないと思うよ
void stop() {
　　std::lock_guard<std::mutex> lk(mtx);
　　running = false;
　　cond.notify_all();
}
お手本でも普通のboolを使ってる
https://cpprefjp.github.io/reference/condition_variable/condition_variable.html
https://cpprefjp.github.io/article/lib/how_to_use_cv.html

**デフォルトの名無しさん** · 2020/05/09(土) 11:17:56.00

>>799
loop()内のrunningは毎度メモリから読まれる必要があるので
C言語ならvolatileにすると理解しています
つまりループ内で最適化されてしまわないようにするためだと思います

これがC++だと仕様的にもともと問題ないのでしょうか？
逆に最適化がかかりにくくなってしまう気がします
ただ手元で実装したものは最適化かけていても確かに期待通り動いています

**デフォルトの名無しさん** · 2020/05/09(土) 12:59:28.79

>>800
POSIX準拠のシステムでは同時アクセスを防ぐ書き方(mutexによるlockとかstd::atomicによるstore/loadとか)
をすれば自動的にメモリ同期(メモリへのフラッシュ)が行われる作りになっていてvolatileとかを気にする必要がないらしい
https://yupo5656.hatenadiary.org/entry/20040618/p2

**デフォルトの名無しさん** · 2020/05/09(土) 13:06:53.14

>>800
>>774のコードの全体の当否はおくとして
while()の中でlockしているのであればlockされるブロックに出入りする際に
>runningは毎度メモリから読まれる
が実現されるからrunningフラグはvolatile無しでもむ無問題、

C++の標準的なlockの仕様は知らんがlockに出入りするときに
CPUのライトキューやリードキューに未処理のライトコマンドやリードコマンドが乗ったままだと
正しいロックにならないから普通のlockの実装ではメモリバリアを行う

メモリバリアはコンパイラに対してはイントリンシックな関数か何かとして定義されており、
それらの呼び出しのときコンパイラは空気を読んでレジスタに乗ったままの変数を放置しないはず…
（変数に対する副作用がある関数呼び出しとみなす

**デフォルトの名無しさん** · 2020/05/09(土) 13:16:40.60

POSIXスレッドはetchになってからようやく使い物になった
woody以前は酷い出来だったのは酔い思い出

**デフォルトの名無しさん** · 2020/05/09(土) 13:46:46.99

しかし以下のような実装のときrunningにvolatileが本当に要らないかどうかわわからん…

void bar() { (内部でlockを行う) }

====↓↓↓異なる翻訳単位↓↓↓====

void foo {
　bool running = false;　　// runningはローカル変数
　while (running) {
　　bar();　　// 一見runninguへの副作用が考えられないシグネチャ
　}
}

どうやっているのかは知らんが、ウィンドーズの同期系API（上の例でbar()にあたる）は
うまいことやってくれる（と思う！

◆QZaw55cn4c · 2020/05/09(土) 13:51:04.20

>>801
というか、pthread や pthread 採用の C++11orlater で記述するのが普通です
volatile のみでなんとかするようなものじゃない

**デフォルトの名無しさん** · 2020/05/09(土) 13:52:06.16

よく考えたら上のコードではrunningへのポインタを他のスレッドが知っていることもありえないから、
そういう意味でvolatile不要（最適化上等）か…orz

一方、runningがグローバル変数なら、異なる翻訳系で定義された関数を呼び出した後に、
runningは改めてメモリから読まれることはコンパイラが生成するコードの規定の動作なので
volatile不要

まとめると、runningがグローバル変数でありかつ同期目的の関数内でメモリフェンスしており、
かつそこが毎回通る限り、runningにvolatileは不要

**デフォルトの名無しさん** · 2020/05/09(土) 13:53:07.30

>>804
running がローカル変数なら bar() での副作用は無理だから volatile の有無によらず foo() は空にできちゃうのでは？

**デフォルトの名無しさん** · 2020/05/09(土) 13:54:44.10

（リロードしてなかった・・・）
>>806 つまり volatile が必要なケースは無いね？

**デフォルトの名無しさん** · 2020/05/09(土) 14:01:00.47

>>808
多分、orz
計算機科学や実際のプログラムの実装は複雑怪奇なので、
病的な反例が何かあるかも((((;ﾟДﾟ))))ｶﾞｸｶﾞｸ

**デフォルトの名無しさん** · 2020/05/09(土) 14:22:58.21

>>801
それはメモリバリアのことですよね
つまりCPU内のリオーダーの制御で
lockからunlcokまでメモリアクセスはその外にリオーダーされることがない

>>800 で気にしてるのはそれではないです
レスわけます

**デフォルトの名無しさん** · 2020/05/09(土) 14:32:48.74

>>802
> >>800
> >>774のコードの全体の当否はおくとして
> while()の中でlockしているのであればlockされるブロックに出入りする際に
> >runningは毎度メモリから読まれる
> が実現されるからrunningフラグはvolatile無しでもむ無問題、

一度目はメモリから読まれるのは確実だと思います
ただループの場合、2度目のリードからはコンパイラが最適化をかけて
一度目の値を使いまわす可能性があると思います

void loop()
{
　　unique_lock lock(mtx);
　　auto r = running
　　while (r) {
　　　　....
　　}
}

と置き換えてしまう可能性があるのでは？ということを心配しています
私のC言語開発の経験ではこの場合はvolatileにするのが鉄則でした

c++のコンパイラはかしこくrunningは都度メモリから読み出すべしと判断していると
なるとその判定はどうやって行っているのでしょう？
一律にローカル変数以外はメモリから呼び出すわけではないと思います
(それだとかなり性能が落ちると思います)

**デフォルトの名無しさん** · 2020/05/09(土) 14:56:31.18

>>811
コンパイラ視点で見れば中身のわからないcond.wait()と言う関数呼び出しが
グローバル変数runningに対する副作用を持たない（値を書き換えない）ことの保証が無いから、
cond.wait()をループ外にくくりだす最適化が行われることは普通は無い。 --- （A）
また、ソースコード上cond.wait()を呼び出した後にrunningを参照する箇所があれば、
普通はかならずメモリからrunningを読み直すコードが吐かれる　--- （B）

普通でない場合というのはコンパイラがcond.wait()メソッドの中身まで知っていて
runningに対する副作用が無いと結論付ける場合が考えられるが、
それでもcond.wait()の中で
　(1) メモリバリアを行っており、
　(2) その意味をコンパイラが知っている
限り、コンパイラが「（cond.wait()呼び出しによる）runningに対する副作用が無い」と結論付けることはありえない --- (C)

というわけで、普通は(A)、(B)が成立するからrunningのvolatileは不要
(A)、(B)非成立な変に賢いコンパイラでも、(1)と(2)が成立するなら(C)が成立するからrunningのvolatileは不要

**デフォルトの名無しさん** · 2020/05/09(土) 15:08:39.92

>>811
ループは>>791の方法で行くんじゃなかったの

**デフォルトの名無しさん** · 2020/05/09(土) 15:08:46.08

>>812
それはstd:::condition_variableを使った場合に限定していますか？
基本的にpthreadのwrapperだと思うのですが、仮にコンパイラがそれを特別扱いしているとすると
pthreadをダイレクトに使った場合はどうなりますか？
あと客観的な文献を示してほしいです

**デフォルトの名無しさん** · 2020/05/09(土) 15:11:10.97

>>813
そうですが別の話題なのでわかりやすく書きました
ただ >>791 もイベント処理中はunlockしておく必要があったのでそこは変えました

**デフォルトの名無しさん** · 2020/05/09(土) 15:20:05.99

>>815
それだと>>811のコードでwhile(r) (あるいはwhile(running))ってなってるのがわからない
>>791だとwhile(true)の中でif(!running)ならbreakするって形でそもそもrunningは一回しか評価しないはず

**デフォルトの名無しさん** · 2020/05/09(土) 15:38:10.36

>>814
>それはstd:::condition_variableを使った場合に限定していますか？
いいえ

>pthreadをダイレクトに使った場合はどうなりますか？
どう使うつもりかわわからんが、コンパイラに中身を知りようが無い関数の
呼び出しがループ内に生じる限り同じ話

>客観的な文献を示してほしいです
(1) 変数に対する副作用がある（かもしれない）関数がループ外にくくりだされないこと
　コンパイラはソースコードをオブジェクトコードに翻訳する際、
　ソースコードに書かれたアルゴリズム（有限ステップで終わる＆非同期要素無し）の
　動作結果を変えてはならない。この原則はコンパイラの教科書に書いてあるし常識と言っても過言ではない
　で、変数に対する副作用がある（かもしれない）関数の不適切な最適化はこの原則にひっかかる

(2) 少なくともMSVCがメモリバリアの意味を知っている根拠
https://docs.microsoft.com/ja-jp/cpp/intrinsics/readwritebarrier?view=vs-2015
これ、VS2010までは非推奨ではなかったし、サンプルコードも載っていたが無くなってたorz

**デフォルトの名無しさん** · 2020/05/09(土) 15:40:22.80

>>814
標準スレッドライブラリを使った前後の読み書きについては、
ライブラリ関数呼び出し（ lock/unlock など）が提供するスレッドをまたぐ "synchronize with" 関係と
スレッド内での, "sequenced before/after" による前後関係とをつないだ
"inter-thread happens before" 関係（順序付け）に基づく挙動が規定されている。
https://timsong-cpp.github.io/cppwp/n4659/intro.multithread#intro.races-9
>811 のような書き換えは許されない。

規格化以前の pthread などをダイレクトに使った場合は >>812 の挙げるような
「事実上問題にならない」に頼ることになり、これに volatile を加えても「事実上問題にならない」の
範疇であることに変わりはない。
問題の可能性が減ったり、実際に起こっていた問題の解決につながることはあっただろうけどね。
これについては「客観的な文献」といったものが無かったことも規格化の動機になっただろう。
https://isocpp.org/wiki/faq/cpp11#cpp11-specific-goals
> - Machine model and concurrency ? provide stronger guarantees for and better facilities
> for using modern hardware (e.g. multicores and weakly coherent memory models). ...

**デフォルトの名無しさん** · 2020/05/09(土) 16:27:23.02

>>817
なるほど
つまりc/c++コンパイラの最適化において、
副作用がある(pure functionでない)関数があると、それをまたいだ
リオーダーや値の流用をすることはない

当然メモリバリアを張るcond(pthreadも含む)は副作用ありなので
これがループ中に存在する場合はrunningは毎度メモリから読み出されることになる

ということですね
非常によくわかりました

**デフォルトの名無しさん** · 2020/05/09(土) 16:30:24.63

>>817
しかし、この場合volatileが不要といえることはわかりましたが、
これはあくまで副作用あり関数の存在に依存しています

と考えると一般的にはvolatileはつけておく方習慣の方がやはり無難だと思いますがいかがでしょう？
(c++ならatomicに置き換えるとして)

**デフォルトの名無しさん** · 2020/05/09(土) 16:33:07.67

>>818
ありがとうございます
ちょっとこれを読み解くのは難しそうですね・・・
あとでじっくり読んでみます

**デフォルトの名無しさん** · 2020/05/09(土) 16:41:37.74

>>819
レジスタに載ったままな変数の流用はともかく、
リオーダーは副作用がある(pure functionでない)関数をまたいでも特に阻害されないんじゃね；
リオーダーの効果はプログラムの実行に関して普通の状況では透過的なので、普通の状況でコンパイラがそれをやめさせる理由が無い

普通でない状況としては>>714みたく同一データに対する複数コアからの同時アクセスがありえるケース
（コンパイラが知りようが無い非同期事象が生じるケース）があるが、
これは（ユーザーコードかライブラリの）プログラマがメモリバリアを明示的に書き、
コンパイラが空気を呼んでその前後の変数の流用も抑止することで処置される

と思うが真実は知らん
気分としてはあくまで>>800の立場であって非同期の問題に関してはノーコメント
事実として出来上がったプログラムが正しく動いているなら問題ないのじゃガッハッハッハ、

**デフォルトの名無しさん** · 2020/05/09(土) 16:43:21.63

訂正orz
誤： >>714 ==> 正： >>774
誤： >>800 ==> 正： >>809

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

>>820
複数スレッドで共有する変数を読み込む以上絶対にlockなりatomicなりを使うわけだから必ず副作用あり関数が存在する

**はちみつ餃子** ◆8X2XSCHEME · 2020/05/09(土) 18:56:58.72

>>820
見かけ上の挙動が仕様通りだったらどうコンパイルしてもよいというのが言語としての基本的なルール。
https://timsong-cpp.github.io/cppwp/n3337/intro.execution
昔は並列実行に関する動作モデルの既定がなかったので、
既定にないことをするプログラムを書いたときに
最適化で除去されたり順序が入れ替わったりしてもそれは仕様通りだったんだよ。

volatile はプログラムとして書いてある通りのことを (たとえ観測できなくても) 実際の動作にも
反映させろというヒントをコンパイラに伝えるものではあるけど、
言語仕様の記述に用いられる抽象機械と実際の実行環境が完全にマッピングできるわけでもない
から volatile が具体的にどう影響するかってのは分からん。
言語仕様外のことをするときのために用意されていると考えてもいい。

つまり、ロックやアトミックまわりの仕様で規定されていることなら volatile を付けようが付けまいが
その通りになるし、既定されていないことなら volatile を付けても言語仕様として得られる保証は何もない。
処理系として言語仕様以上の保証を付けているということはあるだろうけど。

**デフォルトの名無しさん** · 2020/05/09(土) 18:58:03.61

>>824
確かに、正しく排他制御しているのならばそれはいえそうです

**デフォルトの名無しさん** · 2020/05/09(土) 19:14:29.09

volatileは簡潔に言うとregisterの逆の作用だね

**デフォルトの名無しさん** · 2020/05/09(土) 22:27:01.93

volatileはコンパイラに、コード通り読み書きを行うコードを吐けと指示するだけ

CPUが勝手に順番を変えたりしないようにCPUに指示をする命令は別途行わなければならない

x86の場合は何もしなくて良い場合が多く
ARMの場合は追加しなければならない場合が多い

**デフォルトの名無しさん** · 2020/05/09(土) 22:31:00.74

いいえ、単に昔からGCCが糞なだけです。

**デフォルトの名無しさん** · 2020/05/09(土) 22:42:09.15

最近日本式のやつが再注目されてるじゃないか。
それは欧州式のやつのことじゃないか？

**843** · 2020/05/09(土) 23:22:12.13

>>824
片方は書き出し、もう一方は読み出しだけなら排他制御しなくてもアトミックでありさえすれば大丈夫だし、そういう実装はそれなりにあるよ

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

可変長引数テンプレートから型の文字列を組み合わせて配列を定数化して取り出せるようにするために
以下のようなコードを書いたのですが、

template<typename ... ComponentsData> struct ComponentTypeGroup {
static constexpr std::size_t ComponentCount = sizeof...( ComponentsData );
static constexpr std::string_view TypeTexts[ComponentCount];

template<typename Type> constexpr void TypeGroupText( std::size_t _uIndex ) {
TypeTexts[_uIndex] = Detail::Nameof<Type>(); // 定数文字列を生成する関数です。
}

template<typename First, typename Second, typename ... ArgTypes> constexpr void TypeGroupText( std::size_t _uIndex ) {
TypeGroupText<First>( _uIndex );
TypeGroupText<Second, ArgTypes...>( _uIndex + 1 );
}
constexpr ComponentGroup(){ TypeGroupText<ComponentsData...>( 0 ); }
};

constexpr ComponentGroup()で「型指定子がありません」と出てコンパイルエラーが取れません。
何故このエラーが出ているのかがいまいちわからず、途方に暮れています。
誰かご教授いただけないでしょうか？

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

ComponentTypeGroupのtypoでなくて？

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

まずそのインターコンチネンタルホテルみたいな長ったらしい名前やめろ

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

古いコードの一時的メンテのため、stdとstd::tr1をC++11で混在させて使う話なんですが、
元々C++11以前のコンパイラ用に書かれた
using namespace std;
using std::tr1::shared_ptr;
shared_ptr<Hoge> hoge = ...

みたいなコードをC++11でビルドすると、C++11には std::shared_ptr があり ambiguous エラーになりますよね。

最初 share_ptr を std::shared_ptr ということにしてビルドしようかと思ったら、ところどころ std::tr1::shared_ptr と
フル宣言してあり面倒なことが判明。なので shared_ptr は std::str1::shared_ptr とみなす方針に戻りました。

なので using namepace std; を保持しつつ shared_ptr を std::tr1::shared_ptr としてビルドしたいんですが、
それって可能でしょうか? 例えば using namespace std; で std::shared_ptr を除外するようなことってできます?

古いコードを出来るだけいじらずビルドしたい、というのが一番のポイントですw

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

単に#include<tr1/memory>してstd::tr1::shared_ptrのusingを消すんではあかんの？
新しいコンパイラではstd::shared_ptrとstd::tr1::shared_ptrって同じものでしょ

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

>>836
using std::tr1::shared_ptrを取るとただのshared_ptrはstd::shared_ptrになります (using namespace std)。
すると今回の場合、
　std::tr1::shared_ptr<Hoge> boge; // たまにちゃんと名前空間を使ってる宣言がある
　boge = shared_ptr<Hoge>(new Hoge);
みたいなコードが駄目になるようですが。

std::tr1::shared_ptrとstd::shared_ptrはとりあえず名前としては違うんじゃないですか? 違うとコンパイラー
が認識しているように見えますが。

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

淫乱チンポメンタルヘルス？

◆QZaw55cn4c · 2020/05/10(日) 11:14:15.96

>>838
それ、面白いと思ったのですか？

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

>>835
これで全部 std::shared_ptr になるんじゃない？
namespace std { namespace tr1 = ::std; }

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

インサートチンポレンタルホテル！

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

>>840
> namespace std { namespace tr1 = ::std; }

おお、これで std名前空間の中に tr1 のエイリアスを定義できる感じですか?
結果 std::tr1 は ::std -> std を指す、と。

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

>>832
constexpr ComponentGroup()の返り値がない。

constexpr void ComponentGroup()じゃない？

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

コンストラクタの綴り間違えているんじゃね？
何れにしろconstexpr static memberをコンストラクタやメンバ関数内で初期化は出来ないと思うが。
やるならstatic constexpr member関数の戻り値で初期化するとかしないと

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

>>843
>>844

あ……すみません。
コンストラクタの綴り治せばエラー取れました(汗
ご教授ありがとうございました

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

namespace std { inline namespace tr1 {} }

#include <memory>

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

std名前空間に何かするのは基本的に未定義動作に繋がるのでやめようね

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

カラオケで自分が歌いながら録音したカセットテープを爆音でドライブしながら女に聞かすようなものだな
これどう？オレが歌ってんだけど？的な

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

>>848
それ良くやる

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

女「さむっ・・・オープンカーかと思ったわ」

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

>>846
どうもです、しかし自分の環境だとうまくいかないですね。gcc 5.4.0 です。
error: ‘shared_ptr’ is not a member of ‘std::tr1’
std::tr1::shared_ptr<Hoge> hoge;
^
とりあえず>>840を試してみたんですが、やってみるとインクルードファイルが意外と多く、そのほとんどに
#include <tr1/なんちゃら> があり、これらを全て tr1無しにする必要が。
コンパイラーのフラグ等でtr1無しをインクルードするようなことってできましたっけ? うわーさらに脇道。

とりあえず上記を書き直すとした場合、変更量が増えるにつれ、やっぱ全部のファイルで素直にtr1を
全部置換したほうがいいんじゃないかという気が徐々に... っておい > 自分

>>847
御意。ちなみにstdは普通の名前空間とは違うということですか?
しかし namespace の使い方の勉強になりました。いやあ色々思い付かれてすごいです。

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

>>851
#include <tr1/～> も保持するなら、自分のソースツリーに tr1/～を捏造して
その中に #include <～> と >>840 を並べて書けばいいでしょ。

まぁ置換で済むならそっちだろうけど。

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

>>851
std名前空間の中は標準とその実装のための特別な場所
https://ja.cppreference.com/w/cpp/language/extending_std

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

使われないけど標準なんです。

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

関数内で宣言した変数を途中でconst化したいときってどうやったらいいですか？
関数というのはこんな感じです

void func() {
int a;

～aの値を設定する百行くらいの処理～

～aを用いたメイン処理。途中で誤ってaを変更しないようにしたい～
}

aをconstで宣言しておいてaを設定するところはconst_castするというのはやりたくないです。
初期化用関数initializeを作って const int a = initialize(～); とするしか方法はないですか？
できればそれもしたくないのですが

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

&a にアクセスする権限を readonly にするとか
環境依存だろうけど

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

>>855
a に設定する値を求める処理を関数化して、その戻り値でconstのaを初期化する。

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

あ、したくないって書いてあったね

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

>>855
初期化用関数を作るのが嫌な理由は何？
外のスコープに名前を付けて置くのが嫌ということならラムダ式で済むと思うんだけど。

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

>>857>>859
関数作るのが嫌なのは、気分ですね。バカバカしい理由ですみません。

関数外に置くのが嫌でラムダ式は多用しているのですが、使うときはある程度まとまった処理をするときなので
初期化程度のことにラムダ式を持ち出すのは大仰な気がしてやりたくありません。
これまた個人的な好みで恐縮ですが。

（ちなみに>>855で挙げた初期化処理が百行くらいというのは大げさで、概ね数行くらいです。）

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

どうしてもなら、こうだな
int a_;
//a_で初期化処理をする
int const& a = a_;
//aはconst