Nagarei

colorの方ではoperatorを使ってますが、統一したほうが良いと思います。 explicitはつけたほうが良いと思います。

クラスの宣言と関数の実装を別々のヘッダーに分けたほうが実装しやすいと思いますがどうでしょう？

> IntelliSenseがちゃんと認識してくれない 確認しましたが、operator*も認識されてないですね...。どうして``になるんだろう。 > 二項演算子+=と-=なんですが、左右の内部型が違う場合ってどうしましょう。 戻り値を左辺に合わせるで良いと思います。

暗黙の型変換のみで良いと思います。 ~~decltypeを使ってSFINAEではじくのが良いと思います。~~ SFINAEではじくのと、はじかずにエラーになるのとどっちがわかりやすいんでしょうか？ 前者はIntelliSenseでエラーがでるもののエラーメッセージが長くなる。 後者はエラーメッセージは短いものの、IntelliSenseでエラーが出ない上、エラー個所がライブラリの中になる。

> SFINAEではじく こんな感じです。 ``` cpp template struct ignore : std::true_type{}; template //戻り値intの関数 auto add(int a, T b)->std::enable_if_t { return a + b; } int main() { add(0, 0);//OK add(0, nullptr);//エラー...

1. test commitの状態だとpointu8i系の+=が実質使用不可になってしまう。 2. ignore形式にしたらコンパイルが通った 3. なぜtest commitのだとだめなのかという疑問は残るけれども、とりあえずignore形式の物を使うで良いのではないか というわけでcommitしようと思ったのですが、作業データを消してしまったので、commitは後でにします。

試したらこれで行けました。 ``` cpp ->enable_if_t < std::is_same::value, point_c&> ``` ですが、これだとpointu8i系の+=が実質使用不可になってしまうのですが...。 ``` cpp void foo2() { dxle::pointu8i p3 = { 2, 5 }; dxle::pointu8i p4 = { 3, 5 }; p3 +=...

メタテンプレートを新しく書いてもIntelliSenseバグりが治る確証がないんですよね...。 ただ、+=に限って言えば、赤線が出なければIntelliSenseがおかしくても気にならないとは思いますが。

SFINAEがなくてもエラーになるのでSFINAEを外しても良いと思います。

> Narrowing Conversionsを禁止 IntelliSenseがちゃんと利いてますね。良かった。これで良いと思います。 > 挙動 ``` cpp std::uint8_t v1 =3; const auto v2 = v1 * 2;//int ``` これに違和感を覚えるかどうかの話になってきますね...。