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/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, みたいなのを後置演算子と呼ぶのはちょっと変とかそういうことかな？）

2025/08/23(土) 01:30:59.35

//こんな感じ？
#include <iostream>
#include <tuple>
using namespace std;
tuple<int, float, long> foo() {
return {1, 2.1, 99};
}
int main(){
auto [r1, r2, r3] = foo();
cout<<r1<<endl;
cout<<r2<<endl;
cout<<r3<<endl;
return 0;
}

2025/08/23(土) 01:57:32.43

構造化束縛を調べてみたら
fooの返り値はtupleでなくてもpairで返しても良さそうなんだけど
どういうルールなの? キモい

2025/08/23(土) 02:11:02.56

>>592
それがタプルライクの概念。
std::tuple_size の特殊化など、いくつかのインターフェイスを実装すればタプルと同じように扱ってくれる仕組み。

それとは別に配列の場合とか、全てのデータメンバが公開直接メンバなクラスもありということになってるのは単純に箇条書きで数種類のパターンを示す形になってる。
それほどパターンが多くはないがひとつの原則で表せるわけでもない。

2025/08/23(土) 02:22:04.99

>>593
>それほどパターンが多くはないがひとつの原則で表せるわけでもない。
キメぇよw

2025/08/23(土) 09:17:36.36

構造的部分型とか静的ダックタイピングって呼ばれるやつ？

2025/08/23(土) 13:12:32.34

>>591
int r1;
float r2;
long r3

r1, r2, r3 = foo();

って書きたいですね。Pythonみたく

2025/08/23(土) 13:15:39.41

代入のときは tie を使う。

2025/08/23(土) 15:01:16.09

テンプレートの黒魔術で脳汁出てからが本番

2025/08/23(土) 15:37:03.06

>>596
別の言語っぽくって考えは捨てた方が身のため

2025/08/23(土) 19:08:06.22

６６６！

**デフォルトの名無しさん** (ｽﾌｯ Sdb3-im2P) · 2025/08/23(土) 19:56:19.30

struct {
int r1,
float r2,
long r3
} t;
t = foo();
って描きたい
struct に tuple からのコンストラクタを実装すれば良いのかな

2025/08/23(土) 20:18:30.70

>>601
最初から foo がその型で返せばいいんでないの？

2025/08/24(日) 12:07:46.50

C言語から続くカンマ演算子が分かってないんでは？

2025/08/24(日) 12:09:48.21

Pythonあがりだから型を定義する意味がわかってないんだと思う

2025/08/25(月) 07:55:54.04

a=10
a＝’hello'
翻訳しながらだからできるんだろうけどね。

2025/08/25(月) 08:19:19.75

>590
左辺にも現れるからじゃね？

**初心者プログラマー** (ﾜｯﾁｮｲ d5ce-rKTE) · 2025/08/28(木) 17:50:07.17

cppでbazelでmediapipeのビルド方法を教えてくれる方はいませんか？

自分の環境

Visual Studio Community 2022
Windows11 　64 ビット
scoopでbazel 5.3.0
Python 3.10.0

**青木康善** (ｱｳｱｳｳｰ Sa47-Rd44) · 2025/09/07(日) 03:16:03.97

なんか、javaより簡単に思えてきました。

2025/09/07(日) 06:54:14.37

そうか。

2025/09/07(日) 07:39:38.11

obj1=obj2;
の後obj2を変更すると、obj1が書き換わってまってびっくりして
その後、Javaが怖い親父です。

2025/09/07(日) 13:56:14.79

C/C++もポインタを代入するとそうなるよ

2025/09/07(日) 15:17:34.87

この親父他の言語ほぼ使えんだろ

2025/09/07(日) 15:34:33.99

普通 https://ideone.com/wGzMHW
p=[3,1,2]
q=p
p[1]=0
print(q)

2025/09/07(日) 16:53:15.89

>>610 >>613
それはオブジェクトへの参照の競合が起きてる
それぞれで書き換え更新または読み取り中の書き換えをすることでスパゲッティなコードを招いてしまう
その競合をコンパイルエラーにして防いでくれるのはRustだけだと思う

2025/09/07(日) 17:20:59.28

>>614
c/c++なら、ポインタなのか参照なのか見ればわかるし、
まずコンパイラが型をチェックしますんで。はい

2025/09/07(日) 17:34:06.57

参照メインの言語で書き換えを頻繁に行うとそりゃ事故るよ、注意力にも限界がある
値の書き換えをするならC++のように変数が直接値を持つ言語がいいし
参照をメインにするなら関数型言語のようにimmutableを基本にするべきだ

2025/09/07(日) 18:17:46.03

ないしは、q=p; ってしたときに、pがダメになってくれるか

2025/09/07(日) 22:03:02.60

>>615
C++では参照の競合があってもエラーとならず安全性は保証されないよ
例えば以下の挙動

std::vector<int> v{0, 1, 2, 3, 4, 5, 6, 7};
int& fifth = v[5];
v.push_back(100);
std::vector<int> w{8, 8, 8, 8, 8, 8, 8, 8};
fifth = 555;
std::cout << "v[5] = " << v[5] << std::endl;
std::cout << "w[5] = " << w[5] << std::endl;

2025/09/08(月) 07:59:15.17

>>618
これわ別問題じゃないのですか。
にしても、おとろしい
push_backされた時点で再構築されて、新規作成のオブジェクトの要素を保持してしまったで合ってますか？

2025/09/08(月) 10:27:54.64

状況を一から説明すると……
これは fifth が古い無効になった場所を参照する可能性があることが問題。

std::vector の各要素は連続した空間に配置されることが保証されている。
要素の増減でその場所の都合が悪くなれば再配置される可能性があり、
再配置が起こったときは要素を指していたイテレータや参照は無効になるというルール。
無効なイテレータや参照を通じてアクセスしたら何が起こるかわからない。

再配置が起こる可能性がある操作については個々に仕様に書かれているけれど、
キャパシティを変更する (可能性がある) ような操作はどれも再配置が起こりえると覚えておけばいい。

そんでもってこれのややこしいところは「可能性がある」ってところで、
キャパシティをどれくらい拡大するか実装によって差があるし、
状況によっては場所を移動せずに大きさを伸ばせるかもしれない。
つまり問題が顕在化しないかもしれない。

一般論として倍々に延ばす実装がよく知られているからこの例では最初に要素を 8 個にして
顕在化しやすいようにしたんだろう。

2025/09/08(月) 10:47:28.92

>>620
どもです。要素数８ってのもさすがって感じでした。

2025/09/08(月) 22:24:25.56

>>620
今回の問題に限ればその通り
ただし問題の本質は二つの参照(変数fifthとpush_back呼び出し時の参照)を使ったこと
今回はダングリング参照で問題を分かりやすく示したがメモリ問題もvectorも本質ではなく任意のデータに対する参照で問題が起きる

既に参照fifthを持つ状況で同じデータを指す別の参照を関数push_backに渡してデータが書き換えられた
参照fifthが指す値は当初から値が変更されてしまったりダングリングで無効な値になる可能性がある
これが二つの参照の競合による問題で値がいつの間にか書き換わってしまっていることでバグも誘発する
両方の参照が書き換えを伴わないreadonlyの時のみ安全になる
片方もしくは両方の参照が書き換えを伴うと安全でなくなる

2025/09/08(月) 23:06:53.70

再配置が行われるものに参照使って、その生存期間を超えてアクセスするのは未定義動作になるわな。C++に慣れてればそんなコードは書かないが、初級者向けではない。readonly より、lifetime の問題でしょう

2025/09/09(火) 00:29:11.16

参照が無効になる条件は規定されてるし、先にcapacity設定するとか避ける方法も用意されてる
「問題の本質」とやらはただのライブラリ仕様の無理解だろ
分かりにくいとか間違えやすいとかの批判なら分かるけど

2025/09/09(火) 07:24:41.95

>>623 >>624
申し訳ないがcapacityや再配置の話はしていない
lifetimeや参照が無効になる話もしていない
まずそれらを頭の中から消し去って考えよう
元々の話である同一データに対して参照が二つ持った時の話のみをしている
もちろんvectorは登場してもしなくてもいい

2025/09/09(火) 07:29:27.85

元々の話とは>>610や>>613でこれらが参照の競合の最も単純な例
様々な言語で発生してもちろんC++でも生じる
同一データに対して複数の参照を持つと他の参照によっていつの間にか指していたデータの値が書き換わってしまう
これがバグやコードのスパゲッティ化を引き起こす最も大きな原因の一つ
そのためreadonlyでない限り複数の参照を避けるのが好ましい
そのため競合する参照を禁止している言語もある

**デフォルトの名無しさん** (ｽﾌｯ Sdba-bj1o) · 2025/09/09(火) 10:47:02.21

readonlyでない競合する参照を禁止している言語もある

2025/09/09(火) 12:16:08.28

はいはい線型論理言いたいだけ

2025/09/10(水) 00:51:51.50

>>618
これはvにpush_backしたところでキャパ超えて別の場所にリアロックされ、ともない元のvの領域が空になって、即座にwがスポンとそのvが元あった場所に配置されたってことなのですか?

2025/09/10(水) 02:12:52.51

そうだよ。
規格上は何の保証もないから、処理系とかによっては全然違う結果になるかもしれないけど。

**629** (ｱｳｱｳｳｰ Sa47-Rd44) · 2025/09/10(水) 10:07:49.21

>>630
どうもありがとう

2025/09/10(水) 10:13:08.62

>再構築されて新規の要素を保持してしまったで合ってますか
こう聴かれると｢違う｣と返事したくなる

2025/09/10(水) 18:40:20.64

未定義動作だからな
たまたま鼻から悪魔が出る代わりにそうなっただけだ

2025/09/10(水) 22:18:27.54

参照の競合という用語に違和感。並行性に関わる競合状態 (race condition) の話をしようとしているのか？

2025/09/10(水) 22:31:03.50

してない

2025/09/22(月) 23:24:45.15

でわ　簡単？な話題を。
int data{}; ってやります？ int data{0}; ってやります？

2025/09/23(火) 06:55:15.77

int data = 0; ってやる

2025/09/23(火) 10:47:53.44

auto data = 0;
とか、型が明示的なのが好みなら
auto data = int();
といった選択肢もある。

私は
int data = 0;
派だけど。

2025/09/23(火) 10:57:08.68

>>638

autoを使う理由は？

2025/09/23(火) 11:12:21.28

>>639
暗黙的であれ明示的であれ初期化子に型があるのだからそれとは別にもう一度型を書くのは二度手間と言える場合がある。
どういう考え方をとるべきなのかは場合による。

2025/09/23(火) 11:17:00.61

>>640
autoは曖昧だから、ゆるいプログラム用だね
シビアなプログラムは無理

2025/09/23(火) 12:32:51.63

>>638
イテレータの返しを受けるオブジェクトはauto使うと便利みたいな

2025/09/23(火) 14:23:55.04

>>641
テンプレート作るときには必須になる場合もある
ゆるいって理解は雑

2025/09/23(火) 14:48:06.92

前提条件を変えると何でも言えてしまう。
とりあえずここでは発端は >>636 なのだから変数 data の型が int であり (多相にはしない) 内容はゼロで初期化するという狭い仮定を置いたほうがよかろう。
auto を持ち出したのは変に話題を曲げてしまったな。すまぬ。

2025/09/23(火) 20:34:08.12

今北

いまさら人に聞けない
auto って、右辺の型もそのまま左辺にコピーしてきてよ、って感じで使ってるんだけど
その認識で間違ってない? 落とし穴とかある?

2025/09/23(火) 20:39:56.49

右辺が式の場合もあるし
その時自分が思ってた型とautoの型が一致するとは限らないところとか

2025/09/23(火) 21:26:37.10

autoで手抜きしすぎるとあとでｿｰｽ追うときにｴﾗｲ苦労することあるから気を付けろよ

2025/09/23(火) 21:34:42.79

>>647
Pythonとか、
型が書かれてないから追いづらいよね

2025/09/24(水) 02:24:38.07

>>645
その認識でおおよそ正しいが変則的な部分もある。
auto foo = { 1, 2, 3 };
みたいに書くと initializer_list に推論されたりするのは知らないとちょっとびっくりするかもしれない。

それと修飾子などを組み合わせで使うことも出来る。
const auto* bar = &baz;
みたいに。

2025/09/24(水) 07:20:39.19

>>649
何の目的であるの？
C#的にゆるくなるだけだな…