C++相談室 part161

**デフォルトの名無しさん** · 2022/05/21(土) 21:23:29.59

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

**デフォルトの名無しさん** · 2022/10/14(金) 19:23:56.82

>>871
ハッシュテーブルのサイズ、という地雷的制約は好まないのですけれどもね

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/15(土) 03:19:05.65

std::map::operator[] は O(long(N)) のオーダーなんだが、
std::unorderd_map::operator[] のオーダーは平均で O(1) 、最悪で O(N) ということになってんよね。
意図的に最悪を引き当てる、つまり攻撃に晒されるような状況では unorderd_map のほうが不利になる可能性もある。

**デフォルトの名無しさん** · 2022/10/15(土) 18:57:25.60

C++の例外処理は、class SomeClass {}; と中身の無いクラスであっても、
throw SomeClass{}; をcatch(SomeClass) {・・・}
で受け取ることが出来るらあしいけど、
どういう仕組みでcatchは、例外の種類を識別してる？
"SomeClass"のようなclass名の文字列のポインタでも一緒に渡している
のだろうか？
typeid(x)は、RTTI(実行時型情報)が必要で、仮想関数が定義されて無いクラス
に対しては上手く働かないのではなかったっけ？

**デフォルトの名無しさん** · 2022/10/15(土) 21:57:03.29

まず基本を禿の本でも規格票でも読んで
C++例外処理ってそもそも何ってとこをわかってから
出直したら？　そんな有様じゃマトモなレス付かないよ

**デフォルトの名無しさん** · 2022/10/15(土) 23:57:29.06

>>874 typeid と同等の情報で照合すれば可能ではあるんだから、何を不思議に思うことがあるのか。
「上手く働かないのでは」なんて言うぐらいならコード書いて確かめればいいだろうし。

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/16(日) 01:59:22.59

>>874
例外を送出してスタックの巻き戻しをするのは例外を送出する側 (受け取る側ではなく) なんだよ。
つまり送出される例外オブジェクトの型はわかっている。
むしろどこまで巻き戻せばよいか (送出されるオブジェクトの型に対応する catch はどこにあるか) の情報が動的なものだ。

**デフォルトの名無しさん** · 2022/10/16(日) 14:48:55.82

メンバ変数をまったく使っていないメンバ関数を見つける方法ってなんかある？
CppCheckとかでできるんだっけ

**デフォルトの名無しさん** · 2022/10/16(日) 15:16:25.24

まあ普通の静的解析はチェックしてくれるのでは

**デフォルトの名無しさん** · 2022/10/16(日) 17:18:37.82

>>876
typeidは仮想関数を持っているクラスにしか働かないと思っていたが、
働くのか。

**デフォルトの名無しさん** · 2022/10/16(日) 17:21:15.08

typeid(x)の返すオブジェクトは完全にtype_info型なのか、
それとも、type_infoを継承したクラスなのか、どっち？

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/16(日) 22:40:17.52

>>881
std::type_info から派生したクラスであることはあり得る。
https://timsong-cpp.github.io/cppwp/n3337/expr.typeid#1

**デフォルトの名無しさん** · 2022/10/17(月) 05:46:15.36

それこそtypeidに聞いてみりゃいい
cout << typeid(typeid(some_one)).name();

**デフォルトの名無しさん** · 2022/10/17(月) 22:30:57.72

T x;
T y;
に対して
x=move(y); //(1)
とした場合、時系列的に
1. move代入演算子 T::operator=(T &&a);がyの中身をxに入れる。但しこれは、2とも
　関連しているがswap(x,y)とされることもある。
　swap(x,y)を使わない場合には、xにyの中身を入れる前に元々の xの中身が削除される。
2. swapを使って無い場合には、続いてmove代入演算子 T::operator=(T &&a);が
　y のポインタメンバなどに null 値を書き込む。
3. (1)の式の最後で、右辺のオブジェクト y に対してデストラクタが呼び出される。
4. デストラクタは、y ポインタメンバが null だと何も行なわない。
　yの中身がxに交換されていた場合は、もともとxの中身だったものを削除する。

というような流れになるという理解で合ってる？

**デフォルトの名無しさん** · 2022/10/17(月) 23:38:12.11

実装依存では

**デフォルトの名無しさん** · 2022/10/17(月) 23:46:42.02

>>885
特に確認したいのは、
>3. (1)の式の最後で、右辺のオブジェクト y に対してデストラクタが呼び出される。
の部分。
stroustrup氏によれば、yに対するデストラクタが必ず呼び出される、ということ
らしいが、それは常に正しいのかな？

**デフォルトの名無しさん** · 2022/10/18(火) 00:25:45.29

>>886
> stroustrup氏によれば、yに対するデストラクタが必ず呼び出される、ということ
> らしいが、それは常に正しいのかな？
そういう型を作ることはできるけど、そんな動作をしたらスコープアウトで走るデストラクタを
止めないといけなくなって非常に使いづらくなる。正しくなさそう。
あなたが何か読み間違えてるものと思われる。

**デフォルトの名無しさん** · 2022/10/18(火) 00:27:10.46

>>887
move代入の右辺のオブジェクトは、事後にデストラクタが呼び出される、
と書いてあったと思うが。

**デフォルトの名無しさん** · 2022/10/18(火) 03:36:36.81

xの元の中身も適切に破棄されますよっていう話を歪んだ理解してそう

**デフォルトの名無しさん** · 2022/10/18(火) 08:32:29.82

>>888
[訂正]
正しくは、
・move代入演算子 T::operator=(T &&a) 自体はデストラクタを呼び出さない。
・x=move(y) と書いたとき、コンパイラが右辺の y に対してデストラクタを呼び出す。

2つのパターンが有る。パターン1:swapを使う。パターン2:swapを使わない。
いずれにせよ、コンパイラによって y.~T() が呼び出される。

擬似等価コード:
x.operator=(rvalue(y));
y.~T();

パターン1:
T &T::operator=(T &&a) {swap(*this,a); return *this:}

パターン2:
T &T::operator=(T &&a) {thisの中身を削除; aの中身をthisにコピー; aにnull値を書き込む; return *this;}

**デフォルトの名無しさん** · 2022/10/18(火) 08:42:53.23

>>888 あなたの読み間違いではないと主張したいなら出典を挙げられるのがよいかと。

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/18(火) 12:16:32.80

>>888
右辺と右辺値を混同しているとかじゃない？右辺値と右辺値参照も違う概念。

右辺値 (というか prvalue) が完結式の終わりで解体されるのは保証された動作だけど、
std::move でキャストした結果はあくまでも参照を右辺値参照として返すってだけで
元のオブジェクト (この場合は y) は依然として左辺値だよ。
y のデストラクタが呼ばれるのは y のスコープの終わりであることは保証される。

**デフォルトの名無しさん** · 2022/10/19(水) 01:49:23.30

>>892
>y のデストラクタが呼ばれるのは y のスコープの終わりであることは保証される。
なるほど。
でも結局、
T x;
T y;
x=move(y); //(1)
と書くと、(1) の部分で、
x.operator=(yを右辺値化したもの); //(2)
が行なわれて、
yの生存期間が終わる地点で、yのデストラクタであるところの y.~T() が呼び出される、
ということになることは間違いなのですね。
つまり、(2)が行なわれたら yはもはやmove後なのだから、yのデストラクタ呼び出しが
省略されるということではなく、yのデストラクタは絶対に必ず呼び出されるわけですね。
だから、T::operator=(T &&a) は、T::operator=(T &&a)の処理が終わった後に、
コンパイラによって yのデストラクタが呼び出されることを前提に処理しなければならない、
ということになる。

**デフォルトの名無しさん** · 2022/10/19(水) 02:44:50.18

>>893
誤字訂正です:
誤: ということになることは間違いなのですね。
正: ということになることは間違いないのですね。

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/19(水) 04:13:29.85

>>893
そう。 move assignment operator と呼ばれてはいるが
右辺値であるということがわかる以上の違いはない。

ムーブは寿命を左右せず、内容の状態がどうなるかは実装次第。
具体例で言えば std::unique_ptr はムーブ後には空になる (メンバ関数 get は空ポインタを返す) ことが保証されるが、
std::string は (新たな内容が与えられるまでは) 未規定の値になる。

右辺値参照が導入されたのは C++11 からで、
デストラクタのタイミングが変わってしまうような変更を入れられるわけがない。

**デフォルトの名無しさん** · 2022/10/19(水) 23:39:12.93

C＋＋で15年ぶりにプログラミングをすることになったんだけど、
C++11以降のことは何も知らないのでまずは復習もかねて勉強することにした
今でもbjarneの本が初心者にとって一番のテキストなの？
それとももっとシンプルで分かりやすい本が出てるのでしょうか？

**デフォルトの名無しさん** · 2022/10/19(水) 23:45:19.38

>>895
今考えてみれば、条件分岐の中だけでmove代入される場合も有るからかも知れませんね。

**デフォルトの名無しさん** · 2022/10/20(木) 03:01:20.64

昔のC++知ってるならとりあえずEffective Modern C++.でいいんじゃないの

**デフォルトの名無しさん** · 2022/10/20(木) 06:31:14.16

>>896
本は読者との相性があるから一概には言えないが
俺的にはやっぱ禿の本だな
変に手加減してこないところに安心感がある

ただし「プログラミング言語C++第4版」は
あくまでC++11で、C++14以後には触れていないので
構造化バインディングやコンセプトは学べない
俺はこのあたりはここやQiitaできっかけだけ拾って
あとは規格票やhttps://cpprefjp.github.io/で憶えてる

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/20(木) 13:52:31.60

>>896
C++ はごちゃごちゃした歴史的事情を継ぎ接ぎして出来ているので
説明を整理しようとするとかえって事情がよくわからなくなる。
どう頑張ったってそんなに簡潔にはならんよ。

場当たり的に追加された変則的なルールでも
実際に挙動に絡んでくるのなら知っておくしかしょうがないし、
きちんとした説明はそれなりの分量にもなる。
おそらく >>899 が述べる「変に手加減してこない」というのはそういう意味だと思う。

**デフォルトの名無しさん** · 2022/10/20(木) 17:53:11.99

ビャーネの本、章の構成がよく分からんのだけど何がどうしてああなったん

**デフォルトの名無しさん** · 2022/10/20(木) 18:26:02.35

昔は、ロベールが鉄板だった

**デフォルトの名無しさん** · 2022/10/20(木) 18:47:34.03

bj氏の本のダブルディスパッチの部分と、次のVisitorの部分、
どっちもよく分からなかった。
まず、前者のShape&の引数が何のためにあって、どういう役割を果たしているか
誰か教えて。

**デフォルトの名無しさん** · 2022/10/20(木) 18:49:51.30

>>903
プログラミング言語C++第四版日本語版の
p.653, 22.3.1 ダブルディスパッチの辺りから。
bool intersect(const Shape&);
関数が無くてもこの例だと動作すると思うんだけど、
なんなん？

**デフォルトの名無しさん** · 2022/10/20(木) 19:41:09.72

ダブルディスパッチは勘違いしやすいよね

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/20(木) 23:26:04.47

今でも「ロベールの C++ 入門講座」で学ぼうとしているらしいやつを Teratail や Qiita でたまに見るぞ。

C++03 と C++11 でほとんど互換性は維持されてはいるはずなんだがちょっとは非互換もあるし、
残されている機能でも今となってはあまりお勧めできないということもあるから
なるべくなら新しい本のほうがよいとは思うんだが、
俺自身が読んだことがある本が古すぎていまどきの良い本が全然わからん。

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/20(木) 23:52:16.92

>>904
メンバーアクセス演算子によるメンバの選択は抽象クラスなら動的 (仮想関数テーブルを辿る) だが、
引数を元にしたオーバーロード解決は静的型 (static type) の情報が元になる。

静的型はあくまでも Shape だから一旦は Shape& で受けて
オブジェクトと引数を入れ替えてもういちど intersect を呼び出すことで両方とも動的な型でディスパッチすることになるんだよ。

普通はメンバアクセスの側だけが動的ディスパッチだから二つのオブジェクトについて動的ディスパッチをするには
こういうトリックが必要になる。ふたつの動的ディスパッチをするからダブルディスパッチなの。

**デフォルトの名無しさん** · 2022/10/21(金) 03:42:31.85

>>907
なるほど。
Shape x, y;
x.intersect(y);
とした場合、x の方は仮想関数で振り分けられるけど、yの方はそんな機能が無いから
ということのようですね。

**デフォルトの名無しさん** · 2022/10/21(金) 19:14:57.19

>>980
これは分かりにくかったかも知れません。
void func(Shape &a, Shape &b)
{
　x.intersect(y);　//(1)
}

Circle c{xxx};
Box b{xxx};
func(c, b);
のような場合に、(1)において、x の部分は仮想関数によってC++のもともとの機能で
実行時の型によって動的に振り分けできるが、y については、仮想関数では
そのような意味では振り分けできないから特殊な方法が必要になる、ということですね。

**デフォルトの名無しさん** · 2022/10/22(土) 00:28:36.65

>>909
訂正:
誤: void func(Shape &a, Shape &b)
正: void func(Shape &x, Shape &y)

**デフォルトの名無しさん** · 2022/10/22(土) 21:57:41.88

モジュールはヘッダファイル・ソースファイルに代わるものと聞きました
これからは今までインクルードしていたものは全てモジュールにすればよいのでしょうか
また、グローバル変数のみのヘッダファイルや、定数のみのヘッダファイルも
モジュールにした方がよいのでしょうか
ビルド時間が速くなるそうなので気になっています

**デフォルトの名無しさん** · 2022/10/22(土) 22:33:36.63

>>909
ideone に動くソースを貼ってください、全然意味がわかりません

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/22(土) 22:47:49.35

>>911
時期尚早だと思う。
現状の gcc ではオプションに -std=c++20 を付けるだけではモジュールは有効にならず、
明示的に -fmodules-ts を付ける必要があるようにしてあるので、普段使いするにはまだ早いという意図を感じる。
ドキュメントにはまだ完璧じゃないと書いてあるし。
(他のコンパイラの状況は知らんけど。)

それに C++20 の段階ではモジュールの基礎の基礎が決まっただけで
標準ライブラリすらモジュールとして再編できていない。一応は C++23 でやることになってるけど
現在の C++ の規格は三年ごとに話がまとまった分を入れる、
つまり出来てない分を完成させるために期限を延長したりはせず三年後に先送りするという運用なので
C++23 がどこまで出来るものなのか全然わからん。
標準ライブラリを再編していく内にモジュール機能の問題点が発見されたりするかもしれん。

個人的に遊ぶ分には色々とやってみてわかったことはどんどん発信してほしいけど、
製品レベルのプロジェクトではやめておいたほうがいい。

**デフォルトの名無しさん** · 2022/10/23(日) 00:24:14.37

>>913
msvc2022なら、と思いましたがこちらもモジュールはオプションで試験段階のようでした
もう少しvcの更新を経てから新規の小さいプロジェクトで試してみようと思います

**デフォルトの名無しさん** · 2022/10/23(日) 06:09:10.65

MSは怪しい機能は/std:c++latestにしてるよな

**デフォルトの名無しさん** · 2022/10/23(日) 08:32:09.89

C++17のfilesystemもそうだったけど
練りきれてない未完成品を無理に入れるのやめて欲しい

バグ出ししたいんなら拡張規格かoptionalとして出してみて
標準のmandatoryにするのはしっかり固まってからにしろやって

つーかSTLもboost由来のもISO以外のところでそこそこユーザに揉まれてから来たものだろ
開拓は標準規格の役目じゃねえよ

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/23(日) 10:56:19.39

完璧になるまで練ってたらいつまでも進まんから三年ごとに出来た分を規格に入れるという方針に変更されたんじゃないか。
不格好でも不完全でも今使えることが大事だというのは元々の理念だし。

未完成はともかく欠陥報告を乱発するのは良くはないけどさ。

**デフォルトの名無しさん** · 2022/10/23(日) 11:55:48.92

使ってる所だけ直せばいいライブラリと違って（だからって良いわけじゃないけど）
モジュール作り込んでからやっぱdefectでしたって言われたら困るからなあ

**デフォルトの名無しさん** · 2022/10/23(日) 12:11:50.11

ライブラリとモジュールの違いって何ですか？

**デフォルトの名無しさん** · 2022/10/23(日) 12:51:46.87

使うだけの標準ライブラリと、モジュール自作する時の仕様のつもりだった

**デフォルトの名無しさん** · 2022/10/23(日) 13:12:57.82

filesystemって未完成なん?

**デフォルトの名無しさん** · 2022/10/23(日) 13:25:59.97

C++17の時点ではfile_clockがなかった

**デフォルトの名無しさん** · 2022/10/23(日) 14:32:45.34

file_time_type があったと思うが

**デフォルトの名無しさん** · 2022/10/23(日) 14:45:23.56

あったけど使いものにならんかった

**デフォルトの名無しさん** · 2022/10/23(日) 14:59:53.65

その昔、iostreamというのがあってだな
皆阿鼻叫喚の断末魔の雄叫びを上げたもんじゃった

**デフォルトの名無しさん** · 2022/10/23(日) 16:01:34.86

printfやscanfに毒舌三昧してる人に対して持っていた、お暇な方ですねという思いが蘇る

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/23(日) 17:49:58.24

ファイルシステムやらスレッドやらはシステム (OS) 側の都合があるからなぁ。
細かいことは環境依存の機能を使えという前提で
標準ライブラリを最小限にとどめるのは C の時代からの基本的な姿勢だっただろう。

環境依存だからこそ標準で吸収しておいてくれという気持ちもあるし、
現状が良いとも思わんけど…… なんというか……
C++ ってそういうもんだろと思って納得してるから不満には感じないな。

**デフォルトの名無しさん** · 2022/10/23(日) 20:20:25.05

iosteamはいかにもC++初心者がやりそうな「オペレータをオーバーロードできるから
見た目イカすちょっとシャレた表記法にしようぜ！！」っていう厨二スピリット全開だったからな
でてきた時点で「あ、これはクソなやつだ」ってわかったよ

**デフォルトの名無しさん** · 2022/10/23(日) 20:43:19.02

C with classesを始めようとして
たとえばと始めたことをずいぶん後になって
鬼の首を取ったようにキリッ

**デフォルトの名無しさん** · 2022/10/23(日) 22:04:42.81

演算子チェーン自体は別に悪いもんじゃない
iostreamがクソなのはそこじゃない

**デフォルトの名無しさん** · 2022/10/23(日) 22:42:38.11

でも競プロで何も考えずにcin >> N >> M;とかできるでしょ

**デフォルトの名無しさん** · 2022/10/23(日) 23:18:01.98

なにかとiostream叩かれやすいけど
よく聞いてみると大した批判ではないよね常に
聞くに値するiostream批判ってお目にかからないね

**デフォルトの名無しさん** · 2022/10/23(日) 23:21:04.29

iostreamが本当にクソならイカした再実装はあるだろう?
まさかcstdioとか言わんでくれよ

**デフォルトの名無しさん** · 2022/10/23(日) 23:23:02.52

まあstd::cout << foo << bar;がつい最近まで規格上未定義動作だったのは擁護のしようがないけどな

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/23(日) 23:33:00.12

iostream が設計された当時は I/O のための専用の言語機能が
必要という論調があって、 Bjarne Stroustrup 氏はそれに抵抗して
当時の C++ の範疇でライブラリを作ったという経緯がある。

ここで抵抗しなければ入出力用の文法が (ライブラリとしてではなく)
言語機能として導入することになっていたかもしれないと思うと
iostream にある粗くらいは許せてしまうなぁ。

少なくとも printf みたいな型チェックがガバガバなのは C++ 的に
放置できなかったし、バッファリングと書式化をまとめつつ拡張やカスタマイズが可能で
I/O 以外も含めてストリームというインターフェイスを一般化するというのは
当時としてはこれ以上考えられない素晴らしいデザインだと思う。

ひとつこれは (iostream 設計当時でも) どうにかできただろうと思うのは
書式の変更 (マニピュレータを使うなど) をしたら陽に戻すまではそのままというのが良くなかった。
スコープを抜けたらリセットできるような方法が標準で欲しかった。
(boost にあったような気がするが名前を忘れてしまった……。)

**デフォルトの名無しさん** · 2022/10/23(日) 23:47:22.83

ステートはクソで出来るだけ無くすべきっていう現代の常識が当時はなかったからな
書式をストリームのステートにしてしまったのは今思えば大失敗だがあの時代は自然な設計だったんだろうな

**デフォルトの名無しさん** · 2022/10/23(日) 23:48:05.17

>>934 foo, bar がどのように定義されていたらその式が未定義動作になるの？

**デフォルトの名無しさん** · 2022/10/23(日) 23:48:47.26

批判する者にその資格が無いってパティーン多々あるよな
iostream批判するやつだって
じゃあどんな素晴らしい入出力ライブラリを用意したの？
実装したの？どこの誰がどれだけ使ってるの？っていう
タダ飯喰らいがかーちゃんのご飯批判してるようなこと

**デフォルトの名無しさん** · 2022/10/23(日) 23:55:56.29

未定義じゃなくて、引数の評価順が未規定だったって話では？

**デフォルトの名無しさん** · 2022/10/23(日) 23:56:39.14

>>937
何だろうと未定義(C++17以前)。なぜなら一つの式の中でstd::coutを2回変更してるから
(a+=1)+=1とか++(++a)とかも同じ
この大欠陥が見つかったせいで、式の中の評価順は基本コンパイラの好き勝手にしていいというCからの伝統を一部諦める羽目になった

**デフォルトの名無しさん** · 2022/10/24(月) 00:00:00.66

>>940
foo, bar の評価順が未規定だった件を未定義動作と勘違いしてるのか。
https://cpprefjp.github.io/lang/cpp17/expression_evaluation_order.html

cout に対する操作は関数呼び出しの内外の順序付けが入るから未定義動作にはならないよ。

**デフォルトの名無しさん** · 2022/10/24(月) 00:02:05.10

>>940 (a+=1)+=1 も ++(++a) も未定義動作にはならないよ。必ず a が 2 増えて、 a への参照が得られる。

**デフォルトの名無しさん** · 2022/10/24(月) 00:24:37.42

>>940
<<は左から評価じゃね？

**デフォルトの名無しさん** · 2022/10/24(月) 00:26:04.46

もっというと同じ2項演算子が複数でてきたら左から評価では？
数学と同じ

**デフォルトの名無しさん** · 2022/10/24(月) 00:43:11.90

cout<<a<<b;
の場合、左結合なので、評価順序は、
(cout<<a)<<b;
となるが、aとbの中に関数や演算子が書いてあるような場合、
それがいつ評価されるのは実装依存だったような気がする。つまり、
operator<<(operator<<(cout,a),b);
みたいに評価はされることは決まっているが、aとbの評価が、aが先かbが先かは
決まってない、というような話。もっと言えば、cout自体の部分が式や関数になって
いる場合も、cout,a,bの評価順序が決まって無いかも。

**デフォルトの名無しさん** · 2022/10/24(月) 00:45:03.87

>>945
もっというと、
x+y;
の場合、xとyのどちらが先に評価されるかも決まってない。

**デフォルトの名無しさん** · 2022/10/24(月) 00:54:22.51

未規定の動作(unspecified behavior)と未定義動作(undefined behavior)は違うよ

**デフォルトの名無しさん** · 2022/10/24(月) 01:00:58.84

>>945,946
なるほど言わんとしてることは分かったが
左から順に評価するのが当たり前なのでは？
つまりcout, a, bの順

**デフォルトの名無しさん** · 2022/10/24(月) 01:15:48.16

>>948
実は、x86などでは、スタックが、メモリーアドレスの大きい方からから小さい方
に成長するようになっているので、引数は右側から左側に評価した方が効率が良い。
そのため、逆さまに評価する処理系があっても不思議ではない。

**デフォルトの名無しさん** · 2022/10/24(月) 01:33:32.70

ちょっと前までの規格では単一式(≒セミコロンとセミコロンの間)の中の評価順は基本的にコンパイラが好き勝手に弄る事が許されてた
例えばa[++b]=cとかはヒトの常識的にはbをインクリメントしてからa[b+1]にcを代入するけど、別にa[b+1]にcを代入してからbを増やしたって構わない(この前のどっかでa[b+1]を参照してればその方が最適化したら効率的かもしれない)
そんな感じで最適化に都合がいいように評価順には寛容すぎるほど寛容だったんだが、カオスを防ぐためのルールがあって、それが「単一式で同じオブジェクトを2回変更したら未定義」というもの
例えば(a+=1)+=1はどっちの1を先にaに足してもいいが、そういう自由度がある時点で未定義というルールになっていた
もっと分かりやすい例だと(a+=2)*=3は最初のaが1なら常識的には9になると思うけど、評価順ルール的には3を先に掛けてから2を足して5にしたっていい
9か5の二択で済むこれはマシな方で、ポインタが絡むと収拾がつかなくなるから、同じもん2回以上書き換えたらもう知らん未定義じゃってのがCとちょい前までのc++の規格の趣旨だった

で、この話をさっきのiostreamに持ち込むと、operator <<はconstメンバー関数じゃないので、cout << foo << barはcout << fooと、(cout<<fooの戻り値==coutの参照) << barの2回のcoutへの変更を順序は不確定な単一式でやってることになる。つまりさっきのaと同じように未定義動作って事
(cout <<fooを先に実行しないと戻り値確定しないからこっちが先に決まってるのでは？と思うだろうけど、規格の文言上はcout <<fooの戻り値を「予測」して<<barの適用を先にやったって構わないのである。そんな病的なコンパイラがたまたま実在しなかったから今まで問題にならなかったんだろうけどね)

という話がrangesのパイプでoperator|のチェーンの検討をしてるときに発覚してみんな真っ青になって慌てて評価順のルールが見直されたっていう、まあアホ臭い話でした
幸い病的な最適化コンパイラが生まれる前だったから規格文言だけの話で実害はない

**デフォルトの名無しさん** · 2022/10/24(月) 01:59:23.78

aが1のとき(a+=2)*=3が5に成り得たと書いているがほんまかいな?

**デフォルトの名無しさん** · 2022/10/24(月) 02:10:09.65

9か5かってのは説明上の話で、実際は未定義で鼻から悪魔だから9でも5でも0でも-1でも42でも4394967295でもどんな可能性もあった
今の規格では必ず9になった

**デフォルトの名無しさん** · 2022/10/24(月) 02:11:12.04

https://ja.cppreference.com/w/cpp/language/eval_order
スカラーオブジェクトに対する変更にしかUB関係なくね？

**デフォルトの名無しさん** · 2022/10/24(月) 02:19:24.78

operator<<が触ってるcoutのメンバ変数やグローバル変数にスカラーオブジェクトが一切含まれてなければ関係ないけど普通はそんなはずは無い

**デフォルトの名無しさん** · 2022/10/24(月) 07:45:35.99

テキストがバラけたり変数の並び順を変えられなくてi18n対応が困難になるのがiostreamの一番の問題かな

**デフォルトの名無しさん** · 2022/10/24(月) 08:12:37.76

>>950
実際どっちが正しいかは知らんが説明がよくわからん。
cout << foo << bar の例えに (a+=2)*=3 を持ってくるのは正しいのか？

**デフォルトの名無しさん** · 2022/10/24(月) 09:31:36.65

>>950
> それが「単一式で同じオブジェクトを2回変更したら未定義」というもの

C++11 より前のシーケンスポイント（副作用完了点よるルールの話だとしても関数呼び出しの前後には
シーケンスポイントが入るので cout の operator<< で未定義動作が起こるような話にはならない。

**デフォルトの名無しさん** · 2022/10/24(月) 09:49:55.97

>>950
「rangesのパイプでoperator|のチェーンの検討をしてるとき」とか言ってるから
本気で C++17 改定前の話をしてるっぽいなぁ。

> それが「単一式で同じオブジェクトを2回変更したら未定義」というもの
ここから間違い。 C++11 以降は "sequenced before" の順序関係に基づくルールになっていて、
そんな大雑把なルールではない。

> 例えば(a+=1)+=1はどっちの1を先にaに足してもいいが、そういう自由度がある時点で未定義というルールになっていた
C++11 時点で代入式の値取得は代入より後になると規定されているよ。
https://timsong-cpp.github.io/cppwp/n3337/expr.ass#1
> In all cases, the assignment is sequenced after the value computation of
> the right and left operands, and before the value computation of the assignment expression.

関数呼び出し前後に順序関係もある。
https://timsong-cpp.github.io/cppwp/n3337/intro.execution#15
> When calling a function (whether or not the function is inline), every value
> computation and side effect associated with any argument expression,
> or with the postfix expression designating the called function, is sequenced before
> execution of every expression or statement in the body of the called function.

**デフォルトの名無しさん** · 2022/10/24(月) 23:16:53.41

どなたか、clangコンパイラのソースコードで、main()関数がどのソースファイル
にあるか分かりませんか？

**デフォルトの名無しさん** · 2022/10/24(月) 23:38:51.20

grepで始めよう
新しい検索を

**デフォルトの名無しさん** · 2022/10/24(月) 23:50:22.01

>>960
もちろんgrepはしていますが、
test用のソースコードなどに大量に出てきてしまうのでどれか分からないのです。
探しているのですが、むしろ、clangコンパイラ自体のmain関数は存在して
無いのではないかと思えてしまいます。

**デフォルトの名無しさん** · 2022/10/25(火) 00:20:05.85

>>961
grepでtestっぽいのを除外していけば見つけられると思うけど、
スマホでgithub見た感じdriver/tools/driver.hppじゃね

**デフォルトの名無しさん** · 2022/10/25(火) 00:20:30.61

まちがえたdriver.cppね

**デフォルトの名無しさん** · 2022/10/25(火) 15:32:20.93

このコードでfunc(a)だけがコンパイル通らないんだけどどう対策すれば綺麗な感じになる？
ユニバーサル参照の受け取りのとこでT=int&がstd::integralを満たさないのが原因なんだけど

integral_or_lrefコンセプト作るしかない？

#include<utility>
#include<concepts>
template<std::integral T>
void func(T&&);

int main(){
int a=0;
func(0);
//func(a);
func(std::move(a));
}

**デフォルトの名無しさん** · 2022/10/25(火) 15:33:30.00

超初心者＋わかりにくい文章で、ごめんなさい。
今までは、.NetFramewor4.72でWinFormを使って実装していました。

今、.Net6.0 の WinFormで実装する必要が出てきたので

.Net6.0 で実装しています。
.NetFramewor4.72 でWindowsBaseの参照の追加で使えていた
System.Windows.Threading.Dispatcher が

.Net6.0 では、「依存関係」の「COM」で設定しようとしても、
WindowsBaseが表示されず、WindowsBaseを設定できなくて
System.Windows.Threading.Dispatcherが使えなくて、困っています。
同じような課題を諸先輩方は
どのように解決されましたか？

**デフォルトの名無しさん** · 2022/10/25(火) 15:37:45.19

>>965
C#はこっちで
https://mevius.5ch.net/test/read.cgi/tech/1639965805/

**デフォルトの名無しさん** · 2022/10/25(火) 15:39:23.68

CLIはこっちか？

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/25(火) 15:54:18.45

>>964
参照を剥がすのを入れるのが常道じゃないかな？

template<class T>

requires std::integral<std::remove_reference_t<T>>

void func(T&&);

**デフォルトの名無しさん** · 2022/10/25(火) 16:15:10.24

>>966
大変失礼しました。
アドバイスありがとうございます。

**デフォルトの名無しさん** · 2022/10/25(火) 18:06:59.76

そういうとき脳死でstd::decay使っちゃうけどあんま行儀良くないかな

**デフォルトの名無しさん** · 2022/10/25(火) 18:13:31.96

>>962
ありがとう。関数名が main() ではなく、
clang_main()
なんですね。
cmakeすると、これがすぐ呼び出されるような main() 関数が
作られるようです。
cmakeがどういう仕組みでそうやっているのかは分かりませんが。

**デフォルトの名無しさん** · 2022/10/25(火) 18:15:07.22

>>962
古いWzEditorのgrepを使ってるんですけど、除外フォルダが指定できないんです。
何かいい方法は有りますかね。