C++相談室 part161

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

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

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/21(土) 21:24:45.56

>>1
乙

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

C（ちんちん）+（ぷら）+（ぷら）

**デフォルトの名無しさん** · 2022/05/22(日) 00:57:58.97

おいおいまだ続けんのかよ！

**デフォルトの名無しさん** · 2022/05/22(日) 03:20:20.13

ODRってC++処理系の仕様？
処理系はODRの記述を含まない仕様だけあればその通り作ったら
合理的な手間で検知可能な範囲のODR違反コードをエラーにする
ふるまいになるというのが当然で、つまりODRは仕様の結果であってODRを仕様に含めるのは論理的に冗長という印象

どっちかというとODRは正しく動くためにプログラマーが従わねばならないルール、という認識やったわ、
この観点ではinlineがODRの例外というのは例外も糞もなくてそんなプログラムは書いたらあかんからODR違反
コンパイラが合理的な手間でそれを検出できなかったり、それがあってもコードの動きに破綻が無いこととは関係無い
的な、

**デフォルトの名無しさん** · 2022/05/22(日) 09:08:20.74

ちんちん！シュッ！シュッ！シュッ！

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/22(日) 09:12:58.50

>>5
One definition rule は仕様に項目がある。
https://timsong-cpp.github.io/cppwp/n3337/basic.def.odr

インライン関数は同じアドレスを持つ (事実上統合することの要求) というのも仕様にある動作。
https://timsong-cpp.github.io/cppwp/n3337/dcl.fct.spec

no diagnostic と書いてある部分については (可能であれば処理系も検出するけど) どちらかというとユーザに対する要求というニュアンスはあるかも。

**デフォルトの名無しさん** · 2022/05/22(日) 19:47:14.24

有料無料関係なしで最高のIDEってなに？

**ハノン** ◆QZaw55cn4c · 2022/05/22(日) 19:52:14.59

>>7
＞インライン関数は同じアドレスを持つ (事実上統合することの要求)

それはもうインラインではないですね…
そうではなくて、extern なインライン関数をリンクする際には、同一のアドレスであるべき、という意味でしかないでしょう、つまり私の実装案

https://mevius.5ch.net/test/read.cgi/tech/1649979572/996
＞実装的には inline のついた関数定義が外部にリンクされる可能性があれば、すなわち extern な iniline 関数があれば、リンクのためのコード体を、各所に inline に展開されるコード体とは別に（こっそり）用意しておく、見たいな感じで十分に実装可能ですね

を支持する内容であり、extern な　inline 関数において定義を持たないコンパイル単位にでは inline の指示があっても inline しなくてもいいといっているに等しいですね‥‥

7.1.2.4
(略）外部リンクをもつインライン関数は、すべての翻訳単位で同じアドレスを持たなければならない。
外部インライン関数内の静的ローカル変数は、常に同じオブジェクトを参照する。
externインライン関数の本体内の文字列リテラルは、異なる翻訳単位で同じオブジェクトを指す。

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/22(日) 20:04:27.44

>>9
見かけ上は同一に見える (アドレスを取らずに呼び出すときに限ってインライン化できる) ことを保証するという意味だよ。
インライン化できる条件を整えておきたいということと矛盾しない。