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/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#的にゆるくなるだけだな…

2025/09/24(水) 08:23:07.29

>>650
ゆるいというのがどういう意味で言ってるのかわからないからなんとも言えない。
特に有用なのはテンプレート内で、たとえば

template<class T>
void foo(T x) {
auto bar = baz(x); // baz は関数テンプレートだとする
// ここでなんやかんや
}

みたいなのがあるとき auto を使わずに型を合わせて書こうとすると

template<class T>
void foo(T x) {
decltype(baz(x)) bar = baz(x); // baz は関数テンプレートだとする
// ここでなんやかんや
}

みたいになってわずらわしい。
初期化子の型をそのまま持ってくれば良いときに型を明示しても可読性に貢献しないし、簡便な記法があると楽。

**デフォルトの名無しさん** (JP 0Hc6-xemb) · 2025/09/24(水) 12:48:43.78

std::make_sharedとか使うと行が長くなりがちだからauto便利

2025/09/24(水) 23:18:51.30

autoでしか出来ないこともあるから奥が深い

2025/09/24(水) 23:47:45.55

罠仕様が仕込まれてるってだけでは

2025/09/25(木) 06:56:54.48

Rust派に言わせれば、C++が罠らしいぞｗ

でもそのC++が、今の俺を生んだ

2025/09/25(木) 16:58:42.68

有用なときもあるけど、ライブラリ用のコードで乱発するとメンテナンスが大変
可読性メンテナンス性を考えるなら、冗長でない限りはちゃんと書いた方がいい

>>651
それもbaz(buz?)の戻り値の型はTから導出出来るんだから、よほどややこしくない限りはそれ(decltypeで手抜きせずに)を書いた方が可読性メンテナンス性の面では良い

2025/09/25(木) 17:00:57.66

>>656
お前テンプレートプログラミングの素人さんだよね

2025/09/25(木) 20:40:29.81

>>657
自己紹介乙w
Expression Template使って線形代数のライブラリ作った人間だが、ETで利用者がauto使うとどういう問題が起きるか答えてみ
まさか分かりませんとか言わないよな？
テンプレート使ったライブラリ(てか標準ライブラリ)を"利用する"しかしたことのない人間が調子に乗るな

2025/09/25(木) 20:43:04.50

なんか「その理論を作ったのは私ですが」みたいなものを感じる
技術発表の際の怖い質問とかなんとかのやつw

2025/09/25(木) 20:43:46.25

言葉ならなんとでも言えるわな

**650** (ﾜｯﾁｮｲ 8a02-CSnM) · 2025/09/25(木) 20:44:29.25

>>651
ふーん
便利だね

でも、templete自体が何だか好きじゃないわ…

**650** (ﾜｯﾁｮｲ 8a02-CSnM) · 2025/09/25(木) 20:46:08.51

>>656
ちゃんとっって、型を？

型が書いてないと、パット見でわからないよね…

2025/09/25(木) 20:54:22.86

>>662
そう&同感
ぱぱっと書いて何やってるかもすぐ分かるような場面(戻り値がイテレータとか)ではそりゃautoでいいと思うけどねぇ

2025/09/25(木) 21:36:33.99

今ならconceptを使うのが筋が良いんだろうな
他の言語みたいに型制約を書かずにジェネリクスを使えるけど、これは良くも悪くもだよね
楽と言えば楽だけど

2025/09/26(金) 01:34:47.37

>>658
リポジトリ晒して

まさか出せませんとか言わないよな？
テンプレート使ったライブラリ(てか標準ライブラリ)を"内製する"しかしたことのない人間が調子に乗るな

2025/09/26(金) 01:53:11.78

>>658
端的に言って

> それもbaz(buz?)の戻り値の型はTから導出出来るんだから、

ここだよ
関数テンプレートなんだから型が導出できるとは限らない
なぜお前は断言したのかな？
導出できない例にぶち当たったことがないからだよな

2025/09/26(金) 07:26:52.27

>>665 >>668
煽ればタダで教えてもらえると思ってるいつものアホか

>導出できない例
あるわけないだろどうやって実体化するんだよwwwwww

2025/09/26(金) 08:15:01.31

conceptはテンプレートだけじゃなく普通の変数制約にも使えればなぁ。
継承がほとんどいらなくなる。

2025/09/26(金) 10:28:59.69

>>647
判ります

2025/09/26(金) 11:12:51.14

手抜きというか情報を重複させないためにはautoが必要
苦労するのは型情報を追えないツールが悪い

2025/09/26(金) 11:53:52.65

>>648
ああ、おそろしいあの言語は
素人にはｻｻｯと組めて楽ﾁﾝだろうけど大掛かりなものは無理だろうな
想像しただけで脳が震えて耳から溶けて出てきそうだ

2025/09/26(金) 12:02:33.14

expression template を auto で受けるとまずいってのは Eigen みたいな設計の話かな。
あれはムーブがない時代の設計だから一時オブジェクトの参照を保持してしまう (先に一時オブジェクトが解体されて寿命管理が破綻する) のが問題なのであって、解決のための仕組みが与えられたにもかかわらずそれを使ってない設計が悪い。
expression template の仕組み上でどうしても解決できないというわけではないし auto のせいでもない。

ムーブのコストすら許容できないだとか、古い C++ (C++03 以前) もサポートしなきゃならないみたいな事情があるなら「すまんけどこのライブラリを使うときは注意して」というべき筋合いの話で、「auto なんか使っとるからじゃ！」みたいな態度はおかしいだろ。

2025/09/26(金) 12:09:27.62

>>672
>のが問題なのであって
違う。ETの場合、関数(演算子オーバーロード含む)が返すのは、式の構造を表すオブジェクトなのでそれをautoで受けると式の展開が行われず、計算処理の無いコードになってしまう
それを逆手に取ってauto経由で展開のタイミング遅らせることもできるけどね

あとETの利点はムーブどうこうで解決できる問題だけではないし、
誰も「ETを万人が使うべき」だなどと言っとらんよ、何が気に入らんかったの？

で、はちみつお前いつも「知ったかぶりしていい加減なことを言う奴」に怒ってる割に、自分も同じ事してるよな

2025/09/26(金) 12:11:01.51

あと
>「auto なんか使っとるからじゃ！」
一言も言ってないんだが。流れ読み直しておいで

2025/09/26(金) 12:54:00.88

>>672
> autoで受けると式の展開が行われず、計算処理の無いコードになってしまう

書いてなかったが評価タイミングは適当な関数で明示的にする前提を置いてた。
未定義を踏むのは他の何と比べても駄目だ。単に思ってた結果と違ったなんてのは重要じゃない。

> 誰も「ETを万人が使うべき」だなどと言っとらんよ、何が気に入らんかったの？

日常的には使わないケースだからこそだ。
それが auto の問題点のように挙げられてただろ？
ライブラリのほうが C++ の自然な習慣に合わせるのが筋なのにさ。

2025/09/26(金) 13:15:19.27

>>657-658

2025/09/26(金) 13:19:26.24

>>675
あと、ETで式の評価が発生するのは関数の呼び出し時ではない。どうでもいいけど
あと俺が作ったのは4次元まで(行列なら4x4まで。ゲーム用なので)だからヒープ使わんのでそもそもムーブどうこうは関係無いし、勝手によそのライブラリの未定義の話を持ってこられても困る

2025/09/26(金) 13:57:45.37

>>677
eigen は例として話題に出したつもりだったが余計だったな。
端的に主旨を言えば expression template の原理的には auto で受けれるように作ることは可能、かつその方が親切な作りだろうという話をしてる。

お前がどんな設計をしたのかなんてそれこそ俺には知ったことじゃないし、知りようもない。
お前のライブラリで auto で受けれないのはお前がそう設計しただけの話なので、それを根拠に auto がどうこう言ってもなんの足しにもならん。

2025/09/26(金) 14:04:20.28

>>657-658
ETの話はここで出した。

で、俺のautoの使い方に関する意見は>>656だ

自分が何をやってるか良く考えてからレス書き直せ

2025/09/26(金) 14:08:11.66

>>679
悪い設計のせいで利用者に不自然な書き方を強いるライブラリを作ったという話だということは理解してる。

2025/09/26(金) 14:13:42.65

あといちいち知ったかぶってるバカに教えてやるのも腹が立つが、普通数値演算でET使うときは代入演算子やコンストラクタに式を渡した場所で初めて式を展開するんだよ
(autoでわざと評価を遅延させることも可能だと書いただろアホ)
Eigenでも多分そう
もちろんboost::spiritとかの構文解析ならパース処理の関数に渡すまで展開しないだろうが

2025/09/26(金) 14:14:19.90

>>680
不自然なのはお前の、「スキルに見合わない自尊心」だと思うぞ

2025/09/26(金) 14:24:32.42

バカが屁理屈書いてきそうだから再三言うが、>>658は>>657を叩くために出した問いに過ぎない
「意図しないコードになる」という話

これだからお前には絡みたくないんだよマジ鬱陶しい

**デフォルトの名無しさん** · 2025/09/26(金) 17:03:47.95

お前ってのははちみつのこと言ってるのかね？
自分から絡んどいて何言ってんだろうコイツとしか思えんけど

2025/09/26(金) 17:53:41.26

>>684
で、>>666の導出出来ない例って何？www

2025/09/26(金) 19:18:42.84

>>685
ラムダの型導出できないだろ？
なんでこんなのも知らんのにえらそうにしてんの？
あと

https://wandbox.org/permlink/q5sTF1hp76f7jpnq

とかな
この例でfooでもif constexprを使えばautoはなくせるがそんなことやって可読性とかほざけない
他にもパターンあるぞ
謝罪してお前が作ったらしいヘボライブラリ公開したら教えてやってもいいぞ

2025/09/26(金) 19:32:01.31

屁理屈にも程がある
導出出来なきゃどうやって実体化するんだよ、Tしかテンプレートパラメータが無い状況でT以外に依存するものがあるのか？
まさか結果がTに依存するテンプレートになったら「導出出来てない」とかほざくの？
Tに依存するコンテナのイテレータと何も変わらんよそれ

2025/09/26(金) 20:12:50.41

てかその例でauto使わずに戻り値格納するのにif constexpr使うしかないと思ってるとかどんだけ経験不足なんだ・・・(はっきり処理分けする必要がある場合を除く)
そんなクソみたいな例ならさすがにdecltypeかauto使いたくなるが(そもそも使うなと言ってないんだが)、conditionalも知らんのかお前は
必死に探してきてご苦労さん

2025/09/26(金) 20:41:40.17

あの…そろそろ言っとくが

おもろいこと書いたヤツが優勝な?
２ちゃん５ちゃんの原則だぞ

2025/09/26(金) 20:46:36.85

>>665はおもろいと自分で思ってんの？w

2025/09/26(金) 20:59:48.54

>>687
おじいちゃん、ラムダの例で詰んでんのわかる？
わかんない？
わかんないかぁ

2025/09/27(土) 00:06:32.90

やっぱautoはゆるいね
C#とかPython的な感じ…

2025/09/27(土) 05:08:15.66

C++は自由なんだよ

変な風にも使えるし、傍で見てたらめちゃくちゃにもなる

2025/09/27(土) 05:36:45.87

自分が使った方がいいと思った時は使う。
しかないよ。後は規約や上司に従うぐらいか。

2025/09/27(土) 11:22:44.98

久々にC++スレらしくなってておっちゃん楽しいよ

2025/09/27(土) 17:37:01.17

>>681
コンストラクタや代入演算子で実際の計算を起動する方式も支持があるのは知ってるよ。
だからその代表例として有名どころの Eigen を話題に出したのだし、そこに齟齬はない。
その上で唯一の方式ではないし悪い設計だと言ってる。

私に反論するならどうしてそんな方式を取るのか利点 (悪い設計ではない理由) を説明すべきだった。
「数値計算で expression template を使うときは普通」なんて情報量ゼロのことを書かれても何の意味も感じられない。

コンストラクタや代入演算子をトリガーにするのは expression template を最適化として使う考え方だ。
つまり見かけ上は普通に式を書いてるだけなのに実は高速化しているというのがキモで、普通の式である「かのように」見える抽象化に意味がある。

実際の型を意識せざるを得なくなった段階で抽象化は破綻してる。
auto を使ったら何が起こるかを意識しなければならないのはライブラリ設計の失敗なんだよ。
隠れていたりいなかったりする半端な抽象化層を悪い設計と呼ぶのは間違ってるか？

> 再三言うが、>>658は>>657を叩くために出した問いに過ぎない
> 「意図しないコードになる」という話

そんなので意図しないコードになってしまうような作りのライブラリは出来が悪いという話なのはかわらん。
様々な事情に配慮してそうならざるを得ないということもあるというのならわかるが、
そうじゃなくて「それが普通なんだ」と思い込んだ狭い見識での判断なんだろ？

型を書くか auto にするかはスタイルの問題で、どちらを使うかで挙動が切り替わってしまうような設計のライブラリが本当にまともか？