C++相談室 part166

**sage** (ﾜｯﾁｮｲ 8732-NXaD) · 2025/04/26(土) 10:34:58.41

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

※前スレ
C++相談室 part165
https://mevius.5ch.net/test/read.cgi/tech/1698705458/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2025/06/29(日) 13:14:06.51

上のコードの
>auto& st = x.refStruct(); // stはFooのprivateな型だがビルドが通る。
が識別子PrivateStructの可視性を無視してくれる理由がわからんぬ……
これ
>PrivateStruct& st = x.refStruct();
と書いたら型の名前PrivateStructの可視性がprivateなのでもちろんエラーになる

2025/06/29(日) 13:18:58.11

訂正orz
×: >PrivateStruct& st = x.refStruct();
○: >Foo::PrivateStruct& st = x.refStruct();

2025/06/29(日) 13:37:38.54

>>491
> 識別子PrivateStructの可視性を無視してくれる理由

識別子 PrivateStruct を使っていないから。
この場合は x.refStruct() という式から型を推論するので型名 (であるような識別子) の可視性は関係ない。

プライベートなデータメンバ m_st だってその参照を外へ持ち出してるだろ。
外で m_st という名前でアクセスできないが m_st に対応するオブジェクトへのアクセスは (アクセス経路があるなら) アクセス指定に左右されない。
同様に、プライベートに定義した型を型名ではアクセスできないが型を使えないわけではない。

2025/06/29(日) 13:59:10.64

>識別子 PrivateStruct を使っていないから。
>この場合は x.refStruct() という式から型を推論するので型名 (であるような識別子) の可視性は関係ない。
なんで？
不完全な型の参照はエラーになるのだから
コンパイラは型推論の際Foo::PrivateStructという完全な型の情報まで突き止めているはず……
なんでFoo::PrivateStructの可視性を無視してくれるのや……
無視せずエラーにする言語仕様もあり得たはず
ていうかエラーにならないのがおま環でない証拠がいまのところ無い……

2025/06/29(日) 14:09:12.19

>>494
名前に対する使用制限である旨がはっきりと書いてある。
https://timsong-cpp.github.io/cppwp/n3337/class.access#1.1

2025/06/29(日) 15:12:39.04

>>494
でもFoo::PrivateStructを指すpublicなtype aliasがあったらやっぱりエラーにしないで！
とか言ってきたらはっ倒すぞって感じの言語仕様やなあ

2025/06/29(日) 15:29:55.25

プライベートメンバーの参照を返す関数を public でアクセスできる設計の方が驚き

2025/06/29(日) 15:52:20.20

>>497
これ単体で見るとおかしいがプロキシパターンなどでそういう構成になることはある。

2025/06/29(日) 16:51:17.70

すまん。プロクシパターンではないな。
見当違いなことを書いてた。

まあこの場合は言語機能の確認のサンプルだと思うから設計がどうこうはあまり気にしなくていいんじゃね。

2025/06/29(日) 19:25:35.84

たしかに直感的には auto で private な型を推論してしまうのはヤバくね？という感覚になってしまうが
続くレスで指摘されてるとおり private な識別子だからといって外に持ち出せないわけではないので(それを禁止するほうが弊害が大きい)
そういうもんだと思ってプログラマが注意するしかないな
元々 C++ はやり方次第で言語仕様の本来の目的を外れたヤバい方法がいくらでもつかえる言語であり
どんな場面でも常にプログラマは注意を払うべきなので、そういう C++ の"性格"がこの場面でも出たというところか
こういうのがどうしても気になり完全な"性格"の言語が欲しいなら、他の言語にいったほうがよい

2025/06/29(日) 19:47:06.28

>>489
libcurl でいいと思う。便利だし。
curlコマンドと同じように使えるはずだし。

2025/06/30(月) 19:44:03.19

長い名前空間の扱いの質問なのですが、
例えばA::B::C::DみたいなクラスD内でP::Q::R::SのようなクラスSを使用していて
ヘッダーファイルが
namespace A::B::C {
public class D {
　void foo(P::Q::R::S& s);
};
}
みたいな感じになるのですが、実際にはこのP::Q::R::Sが非常に長く正直見苦しいです
かといってusingをヘッダー内で使うのは良くないですよね?
こういう場合にP::Q::R::Sの部分を簡潔な表記にする方法はありますでしょうか

2025/06/30(月) 20:47:28.37

namespace pqrs = P::Q::R::S
でいいんじゃない？

2025/07/01(火) 21:41:31.12

Sしか使わないならusing P::Q::R::S;

2025/07/01(火) 22:22:06.69

>>504
using P::Q::R::S; したらもしも using namespace A::B::C; したときに P::Q::R::S も探索対象になってしまう。
使う側に余計な影響を与えないようにするには別名をつけるほうがより良い。

2025/07/03(木) 00:24:37.09

エンベデッド分野は今でもC/C++が主流なの？
AIに任せられない分野だから生きのこれそうで気になっておりまする

2025/07/03(木) 09:26:35.93

良いんじゃね

2025/07/03(木) 11:06:49.67

>>506
組み込みシステムも多様なので性質や規模によるでしょ。
リアルタイム性が重要なところでは C/C++ は主流のままだと思うけど、プロジェクト全体が C/C++ だけで構成されることは少なくなるんじゃない？

2025/07/03(木) 11:57:31.86

リアルタイム性はOSがやることだし
言語関係ないよ

2025/07/03(木) 12:22:21.27

Javaや.NETはGCでストップ・ザ・ワールドが発生するからリアルタイムに弱いらしい
最近は目標停止時間を1ms以下に抑えるGCもあるけど、あくまでも目標であって保証ではないからね

2025/07/03(木) 15:27:43.14

>>509
イベントスレッドでIOされてもOSがなんとかすると思ってんの？

2025/07/04(金) 08:50:43.54

組み込み
リアルタイムOS
これほど曖昧な言い回しは他に無い

2025/07/04(金) 10:17:03.12

>>509
リアルタイム性が重要なところというのはまさにそのリアルタイム OS のことで、それらを書くのに C/C++ が主流という話なんやで。
そんで既存の OS を使う場合でも次にアプリケーションを用意すれば動くというわけではなくて、組み込みシステムなら大抵の場合にデバイスドライバも書かなければいけないし、 OS が面倒みてくれる範囲は小さい。

低レイヤの整備がすでに整っている状況ならアプリケーションはもうちょっと言語の選択肢はあるかもね。

2025/07/04(金) 10:58:10.60

リアルタイムOSでないOSで、リアルタイム性重視ならそうだが
リアルタイムOSで作るなら言語は何でもいい

2025/07/04(金) 10:59:28.16

例えば24時間365日止まってはいけない産業用制御なんて
C++でも何でもない

2025/07/04(金) 11:09:00.86

シェルで済むならシェルにしなさい。(UNIX)

2025/07/04(金) 11:13:55.32

言語なんでもいいって？
リアルタイムOSってそもそも言語の選択肢少ねーだろ

2025/07/04(金) 11:19:04.05

>>512
いうほどあいまいか？
せいぜい中身がLinux、Windowsでアプリのインストールも自由みたいなやつだけだろ

2025/07/04(金) 20:28:14.57

>>511
ちょっI/Oしたらやっぱリアルタイム性に影響出るの？！
んまー秒単位でwaitして帰ってこないみたいな極端なI/Oポートがあったらそうかもしれないが

2025/07/04(金) 20:39:26.88

>24時間365日止まってはいけない産業用制御
冗長構成かフェイルオーバーするような枠組みとしての取り組みが第一優先な希ガス……
ソフトウェアーの冪等性により同じバグが同じタイミングで発生して冗長構成が無意味化するする危険性については
十分テストしてバグを撮ったのちに起動タイミングをずらすなどの工夫を行えばポアソン分布の同時確率か何かに従って無視できうる（と思う
さすがに原子炉の制御とかだとプロセス単体も形式検証して他分野よりもっと十分検証するらしい（間接伝聞

2025/07/05(土) 12:14:15.08

そんなレベルはラダー図で書くやろ

2025/07/05(土) 12:31:12.20

というかリアルタイムOSの話から関係ない24/365システムの話を出すあたりよくわかってないことを雰囲気で話すタイプの人でしょ

2025/07/05(土) 20:19:54.08

>>521
C++ではないわな

2025/07/06(日) 06:14:16.80

質問なのですが
ケースA) std::stringstream ist("A B"); char c1, c2, c3; に対し、ist >> c1; ist >> c2; ist >> c3; とすると
ist >> c2 は正常に読めて、ist >> c3 を実施した時点で!ist.good()かつist.eof() となってgetc()と類似のEOF検知挙動なのですが
（ちなみに読み取った文字は c1='A'、c2='B'。c3の読み取りは行われない

ケースB) std::stringstream ist("A B"); std::string s1, s2, s3; に対し、ist >> s1; ist >> s2; ist >> s3; とすると
ist >> s2 を実施した時点で早々に!ist.good()かつist.eof() となって挙動が相違し
（ちなみに読み取った文字列は s1="A"、s2="B"。s3の読み取りは行われない

ケースC) しかしBの後に空白を追加してstd::stringstream ist("A B "); とすると、
ist >> s2 は正常に読めて、ist >> s3 を実施した時点で!ist.good()かつist.eof() となってgetc()と類似のEOF検知挙動になる
（ちなみに読み取った文字列は s1="A"、s2="B"。s3の読み取りは行われない

となってケースB)とケースC)で共通に使えるような最終要素まで読み取り完了判定ロジックが無く
std::istream神話が崩壊したんだけどこれっておま環？
一体どうすれば……orz

2025/07/06(日) 06:16:00.70

確認用サンプルコード：
https://ideone.com/Guifzs

2025/07/06(日) 06:47:52.68

とりま上のコードからフォークしたソースコード
https://ideone.com/4WPZtB
の
　parse_as_string_with_common_logic(std::istream& is, std::string& s, bool& bErr)
みたいな判定処理にしたらケースB、Cを共通に扱えるような印象
なのですが正しくはどうすればよいかわからん……

2025/07/06(日) 07:26:05.90

一般的な話ならchar以外の>>で一貫した挙動を期待するのに無理がある
期待した文字が来なかったらungetするかどうか？ファイル最後の改行をどうするか？シグナルが来たら？とか色々あるし
ケースBで言えば"B"の後に文字が続いていればs2に含まないといけないのだから内部的にはケースAで言えばc3まで試し済みの状態
EOFフラグを見るのではなく例外で受け取ったほうが確実

2025/07/06(日) 10:18:34.40

ケースB、Cを共通に扱える
ist.eof()でいいやん
Bが一回余分にループするのは気持ち悪いけど
気にしたら負け

2025/07/06(日) 10:53:22.37

普通はoperator bool（または fail()）を使う

2025/07/06(日) 10:56:09.61

>>527
だいたいわかりた
　is >> s
ライブラリの「>>」の仕様的にsが任意のクラスで有り得るから、
例えばsが複素数クラスで2つの要素を読み取るﾌﾞﾂなのに対し要素を1つだけ読み取れなかった場合、
みたいなのが生じ得るがis.eof()ではそこまで表現できない故にライブラリ側では
char以外の一般のケースについて責任を持たないというと理解すた、
従って、test_parse_as_string_with_common_logic(const char* szInput, bool& bErr)を
charの読み取りによってeof()判定するように直したわ
これならiostreamの正当な使い方だけで構成されておりかつ目的を果たせているはず……
https://ideone.com/eaYGEt

2025/07/06(日) 11:00:55.07

>>528
>Bが一回余分にループするのは気持ち悪いけど
いきなりis >> s してその直後のeof()を当てにするロジックである限り、
リンク先のケースBの挙動となり、最後の要素に引き続く空白文字がないとき
最後の要素が入力ストリームにあるのに受け取れないというもっと深刻な事態となる以下略

>>529
operator boolはis.good()と同じはず……
なおかつそれ単独では（is >> sのsがchar以外のとき）ケースBの解決になんね

2025/07/06(日) 11:06:26.76

ごめoperator boolは!is.fail()やった……orz

2025/07/06(日) 11:24:16.88

二転三転してすまんこ考えを改めたはｻｰｾﾝ……orz
入力ストリームはシリアルポートみたいな途中で入力がブチ切れる危険性があるﾌﾞﾂである
こともあるから、
　ケースB) (空白) (非空白文字列の期待する全体)
　ケースB') (空白) (非空白文字列が受信タイムアウトにより途中で切れたもの)
の区別が!isになったというだけでは区別がつかない。一方、
(空白) (非空白文字列) (空白)
まで受け取ったら、(非空白文字列) がタイムアウトにより途中で切れたものでないことが確実となりﾜｶﾙ
故に、ケースBやB'みたいな条件を扱うこと自体がライブラリの仕様想定外なのかもしれん……
通常のテキスト読み込みでは行末に改行文字（空白文字のうち）が1文字以上あるから、この枠内で話が収まる。

Unixみたいに改行文字が '\n' 1文字だけな環境で、改行文字を読み飛ばして
呼び出し元に返さないgetline()みたいなやつで読んだ結果を
istringstreamしようとするとケースBが顕在化するが、
この場合は強制的に末尾に空白文字を付けることができうる
そうすればケースBは発生しない（ただし空白文字を付け忘れるとバグ

2025/07/06(日) 11:56:43.72

iostreamなんかをテキストの厳格なパースなんかに使わなければならない理由から考え直した方がいい

2025/07/06(日) 12:20:19.64

末尾で改行無しでeofが来るファイルは多い

2025/07/06(日) 12:43:07.86

>>529
ｺﾞﾒ operator std::istream::bool() か std::istream::fail() だけでとりま解決したわｽﾏﾝｶｯﾀorz
https://ideone.com/Fd5zV6

オンメモリのストリームである std::istringstream であっても>>533のケースB'に当たるケース
（オンメモリなので非空白文字列でデータが終わっている場合）においてbadbitがセットされるっぽい
この挙動がおま環でないかどうかはわからん……

2025/07/06(日) 12:47:26.46

>>534
いまさらlex的な処理をgetc()で手で書いたりstrtok()に戻ったりしたくないし……

2025/07/06(日) 13:40:09.19

パーサコンビネータ的なものを先に作るのがモダンな方法だが……。
汚い部分を抽象の向こうに押し込めるだけなので汚さが無くなるわけではない。
小さい規模だと愚直な方法が楽だったりするよ。

2025/07/10(木) 15:17:59.65

C++を勉強して思ったのが
C++って基底クラスをリストに登録させて
派生クラスの機能をひたすら実行させることに特化してるように思うのだけどこの考え方で合ってる？
要はリストありきな感じ

2025/07/10(木) 15:54:02.04

>>539
ゲームのフレームワークでは全てのエンティティを登録してそれに対する更新を繰り返すというモデルがありふれているが、 C++ 的にそれが普通というわけではない。

2025/07/10(木) 16:45:53.90

>>539
一度デバッガで実行をトレースしてみ？

2025/07/10(木) 18:55:50.32

>>508
な、なるほど
何にしても、この先生きのこるには C/C++ は必要そうだね
Py や JS なんかだと若い衆がどんどん来るから負けそうだし・・・

2025/07/10(木) 21:11:59.82

>>540-541
ありがとうございます
リストを自作するなりstd::listを使うなりして
printfみたいな文字出力をする時も、出力部分をタスククラスにぶっこんでラッピングして
出力は派生クラスでオーバーライドしたc->draw();みたいなのに任せる、というのはゲーム専用で他ではあまりされないんですね

2025/07/11(金) 01:51:13.39

C++ は設計理念のひとつとして「人に何かを強制しない」というのを挙げていて、やりたいように書けることを重視してる。
同じパターンでプログラムを書いているように感じるなら単にあなたがそのやり方しか知らないだけ。
分野ごとに大枠ではやりやすいパターンが定着していたりはするので、ひとつの分野だけ見ていると頻出パターンがあるように見えることはあるかも。

2025/07/11(金) 11:58:09.09

BASICも同様の理念で作ればいいのに

2025/07/11(金) 12:28:00.28

>>544
Z世代にはRuby on RailsやRustのほうが良いかもしれませんね

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-zcFv) · 2025/07/11(金) 14:36:44.91

>>543
RustのDisplayやDebugなんてまさにそれだが

2025/07/12(土) 13:34:42.02

C++でデフォルトコンストラクタで確保したリソースだけデストラクタで破棄したくてコピーコンストラクタやコピー代入ムーブコンストラクタやムーブ代入で得たリソースはデストラクタで破棄させたくないときどうする？
rustみたいな所有権システム必要になるんですか？

2025/07/12(土) 14:19:56.77

なんでそんなことが必要なのかわからないけど、破棄するかどうかのフラグを持っておけばいいんじゃないの？
設計から見直した方が良いようなきがするけどｗ

2025/07/12(土) 17:03:35.88

>>548
俺もなんでそんなことが必要なのかわからないけど、pip使ってデフォルトコントラスタのオーナーだけにshared ptrでリソース管理させるとか？

これだとバグが怖いから、素直にshared ptrでリソースを共有したほうがいい気がする。

2025/07/12(土) 17:24:13.44

ゲームプログラムをマルチスレッドにするとき、何をマルチスレッドにするの？
ストレージのロードとかはともかく

2025/07/12(土) 18:45:10.30

マルチスレッドにしたいものをマルチスレッドにする

2025/07/12(土) 19:12:52.47

遠景のテクスチャのロードなんかは別スレッドかな？
当たり判定などのロジックは遅延なく1フレーム16ミリ秒以内にやらなきゃいけないのでメインスレッドでやるしかない
ゲームでマルチスレッド使うのって難しいよね

2025/07/12(土) 20:02:23.86

排他処理が入ると並列化の恩恵がだいぶん減るので高速化の意図でマルチスレッドを使うなら排他が不要な部分を見つけるのが第一だね。

メモリなどの各種のリソース管理の後始末を別スレッドに任せるという例も聞いたことはある。
デストラクタが起動するとサブオブジェクトのデストラクタも連鎖的に起動するからワンフレームの時間が限られている状況では間に合わないということも起こる。
だからデストラクタは後始末が必要なリソースをテーブルに登録するだけにして、別スレッドが実際の後始末をするってことね。
もう使うことの無いリソースだというのは分かってるから排他は少なくてすむ。
(ヒープメモリの管理テーブルはスレッド共通だから排他がゼロとはいかないと思うけど。)
後始末が少しくらい遅れてもどうということはないし。

2025/07/13(日) 11:30:27.40

まあ、
アクションとか以外の、1/60秒で同期させなくていい処理ですかね…
遠くのPhysXの物理とかもできるのかな…

数年ぶりで、レイトレーシングとか未経験だわ…

2025/07/13(日) 11:36:28.87

>>554
コンテキストスイッチとか気にしないといけないですね…
PlaystationとXboxとPCゲームで、それぞれに最適化とか大変そうですね…

2025/07/13(日) 21:38:10.94

・人間は犯罪を起こす種族と言い切っている
地球はすでに丸見え、レーダー電波で宇宙人に居場所をさらしている
公開： 2025-07-13 21:00
https://karapaia.com/archives/524757.html
　>>明らかに人工的なもので、200光年以内にある知的文明なら、地球の場所を把握できる可能性が高い。
　>>アレシボ天文台のような超高感度の望遠鏡を使えば、理論上は6万光年先からでも地球の電波を検出できるとされている。
　>>に宇宙空間で“丸見え”の状態にあり、その状況は75年前から続いているのだ。問題は、彼らが友好的な文明であるという保証がまったくないことだ。
★>>可能性としては、（我々人間のように）きわめて敵対的かつ侵略的な種族であるケースも十分にあり得る。

2025/07/14(月) 12:26:06.28

GPT-4.1超えの中国製AIモデル「Kimi K2」が無料公開される、複数のテストでGPT-4.1やClaude 4 Opusを打ち負かしエージェントタスクもこなす
2025年07月14日 11時10分
https://gigazine.net/news/20250714-ai-kimi-k2/
>>Kimi K2はベースモデルの「Kimi-K2-Base」と事後学習済みモデルの「Kimi-K2-Instruct」の2種類に分かれてリリースされています。以下の図は「Kimi-K2-Instruct」「DeepSeek V3」「Qwen3-235B」「GPT-4.1」「Claude 4 Opus」「Claude 4 Sonnet」「Gemini 2.5 Flash」のベンチマークスコアを並べたものです。Kimi-K2-InstructはすべてのテストでオープンモデルのDeepSeel V3とQwen3-235Bを超えるスコアを記録し、一部のテストでGPT-4.1やClaude Sonnet 4などの商用モデルに勝利しています。
◇上記サイト内にダウンロードリンクがある

2025/07/14(月) 14:37:25.45

>>540
お前ゲーム作ったこと無いやろ・・・

2025/07/14(月) 16:00:51.76

ただエンプティ言いたいだけ違うんかと

2025/07/14(月) 16:18:22.23

画面描画FPS（frames per second）を固定させる為に、以下の待ち処理を入れるとFPSがメッチャ安定する：
while (system_clock::now() < t_after_sleeping) {
Sleep(0);
}
しかし強制フリーズさせてるみたいで、ハード痛めたりしないか不安なんだが。どうなん実際の所？詳しい人教えて

2025/07/14(月) 16:27:01.51

マルチスレッドのセオリーとしてはSleepせずにビジーループするほうが問題
なんだけど、Sleepだと精度悪すぎてちゃんとFPS担保できるのか心配にはなる。動いてるならそれでいいけど

2025/07/14(月) 17:49:12.87

>>561
定石と言えるレベルの普通の処理だよ。
既に指摘されているようにタイマーの精度の問題はあるので工夫を入れる必要はあるけど、
精度が悪くても処理が遅れる (想定より FPS が下がる) 可能性があるだけ。

どういう理屈で不安に思っているのかがよくわからないので何を間違っているのか説明できない。
Sleep(0) が何をやってるかわからない (これが何らかの危険な処理だと思っている) ってこと？

2025/07/14(月) 20:03:36.26

test

2025/07/14(月) 20:04:22.78

>>563
ありがとう。Sleep(0)が何をやっているかはわかっている

2025/07/14(月) 20:05:51.19

>>561のwhile中を空にする（Sleep(0)しない）　＞　while中でSleep(0)する　＞　while中でSleep(1)する（時間単位を1msにして待ち時間を1ms縮める）
という具合にCPU占有率が上がる。精度は落ちるがSleep(1)を入れた方がCPUの負荷は減るので、何となく安心する。

2025/07/14(月) 20:06:23.37

>>561のwhileの中でSleep(0)しつつ準ビジー状態を強行するのがどれだけハードに悪影響なのか、その辺りの実績経験を盗みかった。卑しい盗人を助けてくれ下さい

2025/07/15(火) 00:13:36.01

C++スレ的にはthis_thread::yieldかと思ったんだが

2025/07/15(火) 04:24:49.25

>>561
グラフィックのAPIは何使ってる？
何と比べて安定したのかしらんけどそのやり方でディスプレイの出力と同期できるわけないのわかる？

2025/08/04(月) 06:40:16.41

ちょっ質問なのですが
　unsigned long m_ulAbortReasonBmp;
　std::mutex m_mutex;
　std::atomic<unsigned long> m_ulBias;
に対し、
　m_mutex.lock();
　m_ulAbortReasonBmp |= fooBmp; // (1) : m_mutex.lock()期間内
　m_mutex.unlock();
　m_ulBias.store(barVal, std::memory_order_release); // (2) : m_mutex.lock()期間外だがm_mutex.lock()期間の後
としたとき、
Q1. m_mutex.lock()している他スレッドから見て(1)、(2)の操作の順序（m_ulAbortReasonBmpが変化した後、m_ulBiasが変化する）は保証される？
Q2. m_mutex.lock()していない他スレッドから見てんも(1)、(2)の操作の順序（m_ulAbortReasonBmpが変化した後、m_ulBiasが変化する）は保証される？

2025/08/04(月) 07:34:20.02

Q1については、他スレッドから見てm_ulBiasのreadが
m_mutex.lock()期間（クリティカルセクション）内のm_ulAbortReasonBmpへの書き込みより
先行するようなことが起きるとクリティカルセクションの意味が消失するから保証される

Q2についてはm_ulBiasのreadがプロセッサコアにどう計画されるかわからないから
m_ulAbortReasonBmpへの書き込みの後になることは一般に保証されない、
が、現在人類が手にしているクリティカルセクションの実装（lock期間に入るときと出るときそれぞれで
いかなるreadもwriteも無差別にバリアする）により、lockしないスレッドから見ても順序が実質的に保証される、

でおk？

2025/08/04(月) 08:33:59.43

訂正orz、
Q2のケースでは保証されない
現在人類が手にしているクリティカルセクションの実装（lock期間に入るときと出るときそれぞれで
いかなるreadもwriteも無差別にバリアする）のが真実だとしても、
それはm_ulAbortReasonBmpやm_ulBiasをwriteする側のスレッドがwrite順を守るというだけで、
m_ulAbortReasonBmpやm_ulBiasをreadする側のスレッドにはメモリバリアするコードが無いから
read順を好きに計画され、writeした順でreadされる保証が無い

2025/08/04(月) 08:41:31.47

>ちょっ
かわいい
…舐めてんの？

2025/08/04(月) 16:26:39.26

>>572
コードに無いreadの話が入ってくるのが意味がわからない
聞きたいことはwriteの順番が保証されるかではないのか？
writeの順番は保証される

2025/08/10(日) 21:35:26.79

男きたああああああああああ

2025/08/22(金) 07:16:07.15

初心者だけど、
Pythonみたいにreturnを複数ってできないの？
touple使うくらい？

2025/08/22(金) 07:35:30.89

複数の値を一つにまとめればいいだけ
返す型次第

2025/08/22(金) 08:55:40.38

複数返したいならタプルでいいんじゃない
引数に出力渡すのが多いと思うけど

2025/08/22(金) 10:34:20.59

Python でも返却値として複数の値を返すことは出来ない。
Python で return にカンマ区切りで複数の式を書くとタプルになってる。
受け取る側で複数の変数を書いておけばタプルが分配 (unpack) されたりはするけど……
関数が返却しているのはあくまでもひとつの値という理屈。

複数の値 (いわゆる多値) を関数が返せる言語はそれほど多くない。
LISP 系は多値のサポートがあることが多いけどそれ以外だと Go くらいじゃないかな？
(マイナー言語だとわからんけどよく知られている主要な言語にはほとんどないと思う。)

シンタクス的には C++ で return にカンマ区切りで複数の値を渡そうとしたとき、
つまり
return 1, 2, 3;
というように書いたときのカンマはカンマ演算子として解釈される。
カンマ演算子は左辺の結果を捨てる (評価はする) ので 3 だけが返却値になる。

C++ で複数の値をひとまとめにするには波括弧で囲む記法があって

std::tuple<int, int, int> foo(void) {
return {1, 2, 3};
}

というように書けるんだが……
この波括弧は初期化の記法であってタプルのリテラルというわけではないのでそこんところは注意。

2025/08/22(金) 10:49:05.94

>>579
受け取る方はどうやって受ければいいのですか？

私の頭だと構造体で返せばいいかな　なんつて

2025/08/22(金) 11:06:34.54

>>580
構造化束縛で取り出すのが楽
構造体を定義する手間が気にならないならそれでもいい

2025/08/22(金) 11:49:05.11

C++も昔に比べれば随分と楽になった

2025/08/22(金) 12:07:46.82

>>580
タプルは単にタプル型の値なので普通に受け取れる。

auto bar = foo();

といったように書ける。
タプルから要素を取り出すのは std::get<0>(bar); といった要領になる。
受け取るときに変数に分配するやり方もあって

atuo [r1, r2, r3] = foo();

というようにも書ける。
これを構造化束縛という。
おそらくこれが期待していたものなんじゃないか？

この記法はタプルに限らずタプルライクな型、配列型、データメンバが全て公開直接メンバであるような型などであれば使える。

2025/08/22(金) 12:23:44.06

もし使っているコンパイラが MSVC なら MSVC のデフォルトでは C++14 になってるはずだからそのままだと構造化束縛を使えないかも。
(構造化束縛は C++17 から。)
私は MSVC を利用していないから具体的なやり方は知らんけど必要なら適当に設定してね。

2025/08/22(金) 17:49:52.20

どもです。構造化束縛ね。なんか聞いた事あるかなという程度だった。
使うかなぁ・・・

2025/08/22(金) 21:41:35.66

構造体ほど強いまとまりではなく、返り値だけのゆるいまとまりなら構造化束縛の方が便利だけどねぇ

2025/08/22(金) 21:41:55.58

>>579
std::tuple<int, float, long> foo(void) { return {1, 2.1, 99}; }
atuo [r1, r2, r3] = foo();
って書いたら、
r1に1が、r2に2.1が入るの？
まあそれでもいいかな

PythonからC++に移植中で、ちょっと読みづらいと思ったので…

2025/08/22(金) 21:45:40.16

>>587
まあでも、なんで複数returnにしないのかね？
outの引数が多すぎだわ

2025/08/22(金) 22:11:20.77

Python でも複数return ってできないと思うけど？
カンマ演算子でタプルを作って返してるだけでしょ

2025/08/22(金) 23:03:10.61

そうやね。Pytnonのカンマは、言語仕様上は演算子とは一応区別されているみたいだけど、感覚的には演算子だよね。何で演算子ではないんだろうというのはちょっとした疑問だけど（1, みたいなのを後置演算子と呼ぶのはちょっと変とかそういうことかな？）