C++相談室 part146

**デフォルトの名無しさん** · 2019/11/07(木) 11:35:36.76

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part145
http://mevius.5ch.net/test/read.cgi/tech/1568362404/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

**デフォルトの名無しさん** · 2019/12/12(木) 11:10:12.33

allに該当する要素の数が0なのを特別視する必要はなさそう

**デフォルトの名無しさん** · 2019/12/12(木) 11:21:14.68

非同期な操作やしその瞬間何も起きんなら単にスルーするだけ

**デフォルトの名無しさん** · 2019/12/12(木) 12:01:38.93

>>797
無い。

**デフォルトの名無しさん** · 2019/12/12(木) 12:26:43.11

>>797
Managed C++とかC++/CLIとか

**デフォルトの名無しさん** · 2019/12/12(木) 13:04:34.98

>>801
それだと余計に変になっているので、JS ---> TypeScript の関係とは違う。

**デフォルトの名無しさん** · 2019/12/12(木) 13:08:42.86

C++は型安全だからC++はC++

**デフォルトの名無しさん** · 2019/12/12(木) 14:17:55.83

型安全認定された！

**デフォルトの名無しさん** · 2019/12/12(木) 14:59:18.45

ていうかTypeScriptはJSが型があまりにもザルすぎて危険だよね、Javaやら
C/C++ほど堅くないにしてもある程度の型はいるよね？っていう発想ででてきた
ものだから C++ から寄せていくならむしろ型をユルくしてくパターンだな
そんなクソ言語には興味がないので具体的に何？ときかれても知らんがな

**デフォルトの名無しさん** · 2019/12/12(木) 16:27:22.69

JSが危険ってどういう事？

C/C++は型がない=危険だけど
JSなんかは型安全な言語だからちゃんと例外になって、
メモリ保護エラーとか起こすこと無いけど？

**デフォルトの名無しさん** · 2019/12/12(木) 16:39:21.91

Treeの節（Node）は部分木を表すRangeだと考えて差し支えないですかね？

**デフォルトの名無しさん** · 2019/12/12(木) 16:47:21.68

C++20のレンジってもしかしてDBのカーソルとかに応用できませんかね？

**デフォルトの名無しさん** · 2019/12/12(木) 18:38:14.77

毎回フルスキャンしたいならどうぞ

**デフォルトの名無しさん** · 2019/12/12(木) 18:59:14.59

ビューで制限できるし遅延評価を目的としたストリームを代弁できるんじゃないかなって思ったのですが。

**デフォルトの名無しさん** · 2019/12/12(木) 19:07:50.30

>>806
型も宣言も無い事が危険になることが多い。
例えば、関数を定義しても仮引数に型がないので、全く間違った実引数列
を指定してしまっても処理系がエラーを出してくれない。関数を修正して
仮引数列の真ん中あたりに新しい仮引数を一つ増やしたとする。
この場合、この関数を呼び出す側もちゃんと全て修正する必要がある。
Cだと型をチェックしてくれるので修正の仕方を間違うとエラーになって
くれることが多い。ところがJSだと間違っても全くエラーを出してくれない。

また、JSの場合、ローカル変数とグローバル変数を間違って使ってしまい、
グローバル変数にいれたつもりがローカル変数になってしまっていることがある。

また、変数を1文字間違えた場合も全くエラーにならず、新しいグローバル変数
が使用されたと解釈されてしまう。

どれも、C言語だとエラーになってくれるので安全だが、JSだと危険。

**デフォルトの名無しさん** · 2019/12/12(木) 19:25:03.70

>>811
お前が型安全の意味を間違ってるってことはよく分かった。

メモリ保護エラーなど言語で解決されないエラー
（OSがトラップするエラー）になってしまうことを
型安全じゃないっていうんだよ

言語で例外になるならそれは型安全

**デフォルトの名無しさん** · 2019/12/12(木) 19:44:50.53

ぬるぽ

**デフォルトの名無しさん** · 2019/12/12(木) 20:29:23.98

ﾂﾝｯ

**デフォルトの名無しさん** · 2019/12/12(木) 20:46:51.94

>>808
おそらくできると思う

**デフォルトの名無しさん** · 2019/12/12(木) 22:31:55.78

boost.property_treeはノードはコンテナだって書いてる。
アルゴリズムイントロダクションにはポインタ三つ組みのツリー表現が紹介されてるけど、これがノードがコンテナ的な感じだろか。

**デフォルトの名無しさん** · 2019/12/12(木) 22:36:00.00

>>812
？？？
>>811は型安全なんて一言も言ってないけど？

**デフォルトの名無しさん** · 2019/12/12(木) 22:37:04.02

仮に、ノードにSTLのリストやベクターを持たせて子ノードを格納すると、別の部分木のイテレータが互換性を持たなくなる。
これはちょっとまずい。
ある部分木の途中からある部分木の途中までを注目することはよくあるから。

**デフォルトの名無しさん** · 2019/12/12(木) 22:45:48.06

ノードの物理量が必ず同じであることを利用すれば、データ構造ヒープを木として使うのが良いんだろか。
これなら、メモリーの確保はSTLのベクターが使え、木全体でイテレータが互換性を持てる。

**デフォルトの名無しさん** · 2019/12/12(木) 22:52:26.39

考えれば考えるほど、ノードに子ノード格納用のSTLコンテナを持たせるのは現実味がなく思える。

**デフォルトの名無しさん** · 2019/12/12(木) 22:59:41.49

つまり、型安全はプログラムの健全性を担保するものではなく、C++は型安全とは言えないって事で良いのでは。

**デフォルトの名無しさん** · 2019/12/12(木) 23:02:50.75

jsてのは女子小学生の意味か?

**デフォルトの名無しさん** · 2019/12/12(木) 23:04:10.87

型が無いと僕たちには辛すぎるよね。
ミスを発見してくれないから。

**デフォルトの名無しさん** · 2019/12/12(木) 23:36:51.22

型はまあ重要だけど型ガーばっか言ってる奴は揃ってバカだよな。

**デフォルトの名無しさん** · 2019/12/13(金) 00:21:19.32

型が無いとinsertがinsert_from_intとかinsert_from_stringとか別々にしないといけなくなって、色々大変そう。
呼び出し側が責任を持つということになるのかも。

**デフォルトの名無しさん** · 2019/12/13(金) 00:22:24.50

型演算をコンパイラに任せることが出来なくなって、すべてプログラミングしないといけなくなるのかな。

**デフォルトの名無しさん** · 2019/12/13(金) 06:47:47.05

>>824
むしろ（静的）型なんて俺には不要だぜ、ベイビーって奴の方がアホっぽいけどなw

>>825-826
静的型付け動的型付け
あたりでググってこい

**デフォルトの名無しさん** · 2019/12/13(金) 07:17:35.68

機械語は変数に型がない。
命令で型を使い分ける。
その大変さを考えると型欲しいってなるのかも。

**デフォルトの名無しさん** · 2019/12/13(金) 07:24:37.08

まさにBがCに進化するときの考え方だね

**デフォルトの名無しさん** · 2019/12/13(金) 09:49:21.00

>>825
ただし、実引数の型が違うのに仮引数の違いだけの同じ関数名の関数を複数
用意して使うと言う発想はスクリプト言語的な発想。
そのようにした場合、コンパイラが厳密にどの関数を使うかが人間には
分からない事が多いので安全性を損なう場合が多い。
スクリプト言語は RAD言語なのため、できるだけ短い関数名で対処しようと
するが、それが思わぬ間違いを含みがち。
C言語が好かれているのは、どういう処理がされるかが人間が完全予測できる
ことで、「大体の動作」は好まれない。

**デフォルトの名無しさん** · 2019/12/13(金) 09:53:03.46

>>826
型の違いでコードを自動変化させるという思想は、C++の中でも非常に最近に
なって STL (template) で流行りだしたもの。
もともとC言語に型が導入されたのは、プログラマのミスをコンパイラが発見して
エラーを出してくれるようにするためだった。C言語には関数の多態性(overload)
がない。なお、override と overload は別の概念なので、知らない人は検索して
欲しい。

**デフォルトの名無しさん** · 2019/12/13(金) 09:53:50.44

イネーブラ使えば良いのでは。

**デフォルトの名無しさん** · 2019/12/13(金) 10:00:20.89

コンセプトコイコイって感じなのかな。

**デフォルトの名無しさん** · 2019/12/13(金) 11:27:07.79

#pragma omp parallel forで
自動分割され、各スレッドに割り当てられた
ループの開始点と終了点を取得することできませんか?

**デフォルトの名無しさん** · 2019/12/13(金) 18:09:24.89

>C言語には関数の多態性(overload)がない

さらりと嘘をつくやつがおるな

**デフォルトの名無しさん** · 2019/12/13(金) 18:27:30.70

今UE4と組み込み以外でc++の仕事あります？

**デフォルトの名無しさん** · 2019/12/13(金) 18:33:53.16

オーバーロードあるか？
ディスパッチの方法はいろいろあると思うが

**デフォルトの名無しさん** · 2019/12/13(金) 18:55:58.62

>>836
USのマイクロソフトに行け

**デフォルトの名無しさん** · 2019/12/13(金) 19:01:03.38

>>830
> ただし、実引数の型が違うのに仮引数の違いだけの同じ関数名の関数を複数
> 用意して使うと言う発想はスクリプト言語的な発想。

え？スクリプト言語で「同じ関数名の関数を複数用意」できる言語なんて無いでしょ？
「同じ関数名の関数を複数用意」できるのは静的型付け言語の特徴だよ

**デフォルトの名無しさん** · 2019/12/13(金) 19:52:22.32

>>839
> え？スクリプト言語で「同じ関数名の関数を複数用意」できる言語なんて無いでしょ？
関数は無理だがメソッドでいいならPowerShell

**デフォルトの名無しさん** · 2019/12/13(金) 20:00:57.46

PowrShell は型付言語ですからね。
それぐらいでしょ？

**はちみつ餃子** ◆8X2XSCHEME · 2019/12/13(金) 20:54:52.57

用語としてメソッドと言ってるものでよければ Common Lisp もそうじゃね？

**デフォルトの名無しさん** · 2019/12/13(金) 21:07:31.92

>>841
うん、1つあれば
> え？スクリプト言語で「同じ関数名の関数を複数用意」できる言語なんて無いでしょ？
の反例になるからね

**デフォルトの名無しさん** · 2019/12/13(金) 21:09:15.79

>>843
そしたら、一つぐらいしか無いって俺は意見を訂正するだけなんだが、

お前も同じ関数名の関数を複数用意できるのはスクリプト言語では
PowerShellだけだって訂正するって話でいいの？

**デフォルトの名無しさん** · 2019/12/13(金) 21:13:12.55

それでいいんじゃないの

**デフォルトの名無しさん** · 2019/12/13(金) 21:23:18.13

質問です
template <typename T>
constexpr inline T value;
template <typename T>
constexpr inline T value = (T)0;
こうやって変数テンプレートの宣言と初期化を分離すると
VC、clang(Xcode付属)ではエラーになるんですがwandboxで試すとエラーになりません
本来どっちの動作が正しいんでしょうか？

**デフォルトの名無しさん** · 2019/12/13(金) 21:37:57.11

>>844
別にそれでいいよ
> え？スクリプト言語で「同じ関数名の関数を複数用意」できる言語なんて無いでしょ？
が無知からの発言と認めてもらえればいいだけだしw

**デフォルトの名無しさん** · 2019/12/13(金) 22:26:34.23

>>846
これも通ってしまった。
#include <iostream>

template <typename T>
constexpr T value = 1;

template <typename T>
constexpr T value = 2;

template <typename T>
constexpr T value = 3;

template <typename T>
constexpr T value = 4;

template <typename T>
constexpr T value = 5;

template <typename T>
constexpr T value = 6;

int main()
{
std::cout << value<int> << std::endl;
}

**デフォルトの名無しさん** · 2019/12/13(金) 22:27:26.74

実行結果。

Start
6
0
Finish

最後の定義が有効になってるように見える。

**デフォルトの名無しさん** · 2019/12/13(金) 22:28:16.14

Wandbox
C++
gcc HEAD 10.0.0 2019

**デフォルトの名無しさん** · 2019/12/13(金) 22:54:36.18

ありがとうございます、その結果を見るとgccがおかしいぽいですね・・・
宣言時に初期化は必須と考えて書いていこうと思います、ありがとうございました

**デフォルトの名無しさん** · 2019/12/13(金) 22:57:06.09

僕もちょっとわからないんだけど。

**デフォルトの名無しさん** · 2019/12/14(土) 00:21:27.14

>>836
デスクトップアプリ

**デフォルトの名無しさん** · 2019/12/14(土) 07:31:10.87

>>846
診断メッセージをよく見ろよ
> error C2737: 'value': 'constexpr' オブジェクトは初期化する必要があります。

そもそも分離できないんだよ
いいか、constexprは翻訳時定数だぞ
それを翻訳段階9まで未解決のままにできると思うか？

**デフォルトの名無しさん** · 2019/12/14(土) 08:56:55.09

>>854
なんでできるようにしないの？
そっちの方がおかしくね？

**デフォルトの名無しさん** · 2019/12/14(土) 09:02:00.44

なんでという理由も述べたはずだが

**デフォルトの名無しさん** · 2019/12/14(土) 09:53:01.66

>>856
だからそれを可能にするようにしてくれ

**デフォルトの名無しさん** · 2019/12/14(土) 10:02:03.90

ん？　俺は江添じゃねえぞ
奴なら標準会員だから言ってみるのもいいが

**デフォルトの名無しさん** · 2019/12/14(土) 10:02:27.48

- 標準会員
+ 標準化委員

**デフォルトの名無しさん** · 2019/12/14(土) 10:08:29.00

江添本ダメ絶対

**デフォルトの名無しさん** · 2019/12/14(土) 10:30:50.58

江添でもできない

**846** · 2019/12/14(土) 10:35:10.86

>>854
＞診断メッセージをよく見ろよ
見た上で言ってます（つまりgccまたはVC, clangのバグではないかということ

＞いいか、constexprは翻訳時定数だぞ
それ以前にテンプレートなんですが

**デフォルトの名無しさん** · 2019/12/14(土) 12:26:05.30

ローマ法王は根競べで決めるらしいですよ奥さん。

**デフォルトの名無しさん** · 2019/12/14(土) 12:26:49.81

誰でも閲覧できる規格ドラフト見ればすぐにわかることをこんな掃きだめで聞いても

**デフォルトの名無しさん** · 2019/12/14(土) 12:35:13.30

>>862
なんかとんがってんな

コンパイラのバグとまで言う根拠は何だ？
相場では規格票の条文だが

テンプレートなのは見ればわかるさ
だから何なのか説明をやめないでくれ

**デフォルトの名無しさん** · 2019/12/14(土) 12:50:37.99

>相場では規格票の条文

通産省の癖の抜けない老人はご退場いただきたい

**デフォルトの名無しさん** · 2019/12/14(土) 12:58:43.25

これODRの緩和と関係あるんですかね？

**デフォルトの名無しさん** · 2019/12/14(土) 13:34:08.27

>>772
>x86系CPUで普通のメモリへの読み書きで順番が入れ替わる可能性があるのは write => read だけ
別に。
コアAの読み書きをコアA自身が見る分にはそうかもわからんが
コアAの読み書きを異なるコアBから見たらwrite同士やread同士でも順番が入れ替わり得る
（アウトオブオーダー実行の影響で

安全に動かすには適切にメモリバリアで順序化する必要がある

**デフォルトの名無しさん** · 2019/12/14(土) 13:37:18.74

>>868
read ==> read
read ==> write
は入れ替わらない

**デフォルトの名無しさん** · 2019/12/14(土) 13:37:51.96

といってもロックレス何ちゃらぐらいの制御であればInterlockedCompareExchange()で済むから
スレッド間の通信なら普通メモリバリアとか直接触る必要は無いが

**デフォルトの名無しさん** · 2019/12/14(土) 13:38:24.93

>>869
迷信

**デフォルトの名無しさん** · 2019/12/14(土) 13:39:11.91

ソースは？

**デフォルトの名無しさん** · 2019/12/14(土) 13:39:40.59

リードキューやコマンドキューにコマンドが入るのはアウトオブオーダープロセスの事後であるため
そのような保証は無い

**デフォルトの名無しさん** · 2019/12/14(土) 13:41:05.07

それのソース

**デフォルトの名無しさん** · 2019/12/14(土) 13:44:15.66

https://github.com/herumi/misc/blob/master/cpp/fence.md

**デフォルトの名無しさん** · 2019/12/14(土) 14:15:12.84

x86系は
シングルコアのマルチスレッドアプリ
の多くがそのまま動くように出来てる

シングルコア時代が長かったから

**デフォルトの名無しさん** · 2019/12/14(土) 14:55:10.15

>>865
＞テンプレートなのは見ればわかるさ
＞だから何なのか
普通に考えて、実体化がまだなのに定義（初期化）を強制される妥当な理由はない、ということ

**デフォルトの名無しさん** · 2019/12/14(土) 14:57:30.67

確かにリンク先のインテルのマニュアルの
>8.2.3.2 Neither Loads Nor Stores Are Reordered with Like Operations
>Example 8-2. Stores Are Not Reordered with Older Loads
に
>Initially x = y = 0r1 = 1 and r2 = 1 is not allowed
と書いてあって>>875と同じことが書いてあるが疑わしい
マニュアルが間違っているのではないか、

ちな
>8byteのデータはアドレスが8の倍数のときにアライメントされている。
から安全に読み書きできるというのはi486みたいな古いプロセッサーだとかえって危険らしい
>8.1.1 Guaranteed Atomic Operations
を見たらﾜｶﾙ、

**デフォルトの名無しさん** · 2019/12/14(土) 15:04:35.33

つか上のインテルのマニュアルには「投機的実行時中のメモリアクセスではメモリアクセス例外は発生しない」
旨が2箇所ぐらいに書かれているが、
ということはつまりアセンブリコード上A→BまたはA→Cというメモリアクセスが条件によってどちら片方だけ実行されることを意図したコードであっても
A→B→Cというメモリアクセス順に成り得ることを意味し、他コアからもそう見えてしまうはずだが、
これをメモリアクセス順がreorderされていないうちに入れてしまうのはどうなのか、、、
マニュアル執筆者の国語の再教育が必要なのではないか

**デフォルトの名無しさん** · 2019/12/14(土) 15:10:49.52

>>877
おまえさん、もしかして
テンプレートの宣言と定義と
オブジェクトの宣言と定義を
ごっちゃにしてないか？

int test;
int test = 5;
これは宣言と定義じゃなく定義の重複だぞ

**デフォルトの名無しさん** · 2019/12/14(土) 15:13:40.23

お前なぁ
x86のこと大して詳しくないのにしゃしゃり出てくるからそういう情けないこと言うはめになるんだよ
x86でstd::atomicのmemory_orderを変えてバリア付きがどういうインストラクションになるか見てみな
storeのseq_cst以外は素のmovだから(コンパイラ依存だから絶対ではない)

**デフォルトの名無しさん** · 2019/12/14(土) 15:20:09.00

そりゃー間違ったマニュアルにしたがって実装したら間違った実装になり得る（ｷﾘ

ていうかアウトオブオーダー実行の影響がマルチコアCPUにおいても透過的だと認めやっても良いが、
>>879の投機的実行の件はどうなんじゃ？
あるコアが投機的実行中に他のコアをストップさせるのでは何のための投機的実行かわからん…

**デフォルトの名無しさん** · 2019/12/14(土) 15:21:14.95

>>877
× 普通に考えて
〇俺の頭の中で

× 妥当な理由はない
〇妥当な理由は思い当たらない

テンプレートなら初期化は不要という主張なら、
constexpr 変数の宣言と定義を分離できないことは納得してるのかな？
そうだとして、それをテンプレートの時だけ可能とすることに意義があると思うの？

特別ルールを設ければコンパイラ実装やプログラムの読み取りにコストがかかるから、
明確が意義がなければ特別ルールは無いのが妥当だと思うよ。

**デフォルトの名無しさん** · 2019/12/14(土) 15:24:42.79

>>880, >>883
マウント取るのが最優先でまともな回答できない（するつもりも無い）んなら黙っててくれ

＞これは宣言と定義じゃなく定義の重複だぞ
externつけたら？

＞それをテンプレートの時だけ可能とすることに意義があると思うの？
テンプレート実引数に使われる型が不完全型であっても、実体化まで評価を遅らせられる

さて、
＞× 普通に考えて
＞〇俺の頭の中で

＞× 妥当な理由はない
＞〇妥当な理由は思い当たらない
こんなゴミみたいな煽り入れてきたからには逃げるなよ

**デフォルトの名無しさん** · 2019/12/14(土) 15:32:39.86

>>884
おまえさんの元の質問はこうだったな
template <typename T> constexpr inline T value;
template <typename T> constexpr inline T value = (T)0;

どこにexternなんて書いてある？
マウントがどうたら気にするあまり後出しなんかしてるのはそっちだぞ
こっちはそんなこと微塵も考えちゃいねえよ失敬な
最初の口調に戻れよ

**デフォルトの名無しさん** · 2019/12/14(土) 15:36:57.55

間違えた
Ｘテンプレート実引数に使われる型が不完全型であっても、実体化まで評価を遅らせられる
○初期化に使われる定数式の評価を遅らせられる

言い換えれば、宣言と定義を分離できないならconstな変数テンプレートの宣言時には
それに使う定数式内のすべての型が完全型であることを強制されてしまう
＝std::is_integral_v = std::is_integral<T>::valueでいえば
is_integral構造体の方が取り回しがいい、ということ
なんのために変数テンプレートが導入されたのか・・・・

**デフォルトの名無しさん** · 2019/12/14(土) 15:37:56.58

>>885
自分が失敬だからこうなってるとは考えられないんだな
何様だよ、そもそも質問に答えてないだろうが

**デフォルトの名無しさん** · 2019/12/14(土) 15:43:43.09

>>887
template <typename T> constexpr inline T value;
template <typename T> constexpr inline T value = (T)0;
を例示しての質問に対して
int test;
int test = 5;
という答えをしているぞ
valueがtestになったのは悪かったが
余計な飾りをとって問題の核心を指摘したんだよ

**デフォルトの名無しさん** · 2019/12/14(土) 15:48:43.77

家事があるんでしばらく離席する

**デフォルトの名無しさん** · 2019/12/14(土) 15:58:10.05

規格でそうなってる（テンプレートゆえの特例は無い）のが”わかってるなら”
最初からそう言ってくれれば済むんじゃないの？
>>854を読み直せよ、テンプレートのことが完全にすっぽぬけた上に失礼な回答だろ

＞コンパイラのバグとまで言う根拠は何だ？
とまで、って・・・・普通にありえるだろ、動作が違うんだから（未定義とかいう屁理屈は無しで）

で、>>883は逃げたの？

**デフォルトの名無しさん** · 2019/12/14(土) 16:55:24.17

>>886
やっぱり constexpr 変数の宣言と定義を分離して何がしたいのか、
何ができるようになるのか、が見えてこない。ごめんね。

宣言だけ見える constexpr 変数への参照やポインタだけはとれるようになるけど、
それだともう constexpr である必要なくて const 変数でよさそうで、それならふつうに
宣言と定義は分けられるし。

ちなみにテンプレート実体化までテンプレート引数依存箇所の評価はされないから、
宣言と定義を分ける話を「評価を遅らせられる」と言い表しているのも何か間違ってそう。
「記述を遅らせられる」の間違い？

**デフォルトの名無しさん** · 2019/12/14(土) 17:16:54.80

だめだこいつ
絶望的に人に者を尋ねる態度がわかってない
「言ってくれれば済む」とか図々しすぎ
技術的な議論がしたいがこいつ相手では
不必要にイラついちまって無理だわ
俺そんなに人間できてない

**デフォルトの名無しさん** · 2019/12/14(土) 17:24:00.92

>>891
すまん、
＞テンプレート実体化までテンプレート引数依存箇所の評価はされない
これ検証してみたらたしかにそうだった
手元のコードで完全型を要求されたから、初期化時に不完全型を使えないと思い込んでた
（おそらくconstexprな変数テンプレートの実体化が、必要な型の実体化より先に来てたっぽい
多分構造体か何かでワンクッション置けば解決できると思う）
これなら確かに分けられなくて問題無いね

>>892
＞いいか、constexprは翻訳時定数だぞ
＞それを翻訳段階9まで未解決のままにできると思うか？
＞なんかとんがってんな
＞後出しなんかしてるのはそっちだ
＞余計な飾りをとって問題の核心を指摘したんだよ
さらには
＞最初の口調に戻れよ
の上で
＞技術的な議論がしたいがこいつ相手では
＞不必要にイラついちまって無理だわ
よくそんなセリフが言えたもんだ
自己評価高すぎじゃない？ｗｗｗｗ

**デフォルトの名無しさん** · 2019/12/14(土) 17:52:18.36

意見が合うとか合わないとか以前の問題
根底的なメンタリティに欠陥がある相手とは話にならない

**デフォルトの名無しさん** · 2019/12/14(土) 17:58:45.99

FYI

>>846
Bug 68012: g++ incorrectly accepts forward declaration of constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68012

>>848
One definition rule
https://timsong-cpp.github.io/cppwp/n4659/basic.def.odr#1
> No translation unit shall contain more than one definition of any variable, function, class type, enumeration type, or template.

**デフォルトの名無しさん** · 2019/12/14(土) 18:08:23.02

>>895
わざわざありがとう、やっぱgccのバグだったのね

**デフォルトの名無しさん** · 2019/12/14(土) 19:50:50.54

GCCに踊らされてスレを浪費した

**デフォルトの名無しさん** · 2019/12/14(土) 20:04:04.94

>>837
オーバーロード=多態性じゃないんで…
オーバーライドのことなら当然cで実現できる