Nagarei

> Narrowing Conversionsではないならexplicit外す SFINAE使えばできるのですが、VS2013が訳が分からないエラーを出すので現在原因調査中です。 現在試行錯誤中のコード ``` cpp template < typename Tp2_, enable_if_t = nullptr> operator point_c() const DXLE_NOEXCEPT_OR_NOTHROW { return{ static_cast(this->x), static_cast(this->y) }; } template < typename Tp2_, enable_if_t::value, std::nullptr_t>...

> VS2013 November CTP かなりの数のエラーが出ました...。分類が雑な状態ですが、とりあえず置いときます。 ``` 1>------ ビルド開始: プロジェクト:calc_coordinate, 構成:Debug Win32 ------ 1> calc_coordinate.cpp 1>c:\...\dxlibex\basic_types\arithmetic_t.hpp(15): error C2440: 'default argument' : cannot convert from 'nullptr' to 'enable_if::type' 1> 'enable_if::type' may be...

value_typeが同じpoint_cへの暗黙の変換を許可したほうが良いと思いますが、どう思いますか？

> 悪しきArgument Dependent Lookup 複雑で間違いを起こしやすいからというのがこういわれる要因のようですが...。 この場合はDxLib本家の方とほとんど変わらないインターフェースで呼び出せるという意味で、これで良いのではと思っています。 cfで紹介されている悪い例（曖昧さが生じる例）はジェネリックすぎるprint関数が問題なのであって、関係するクラスのみを引数にとるこの場合では問題は起こらないと思います。（反例があればすぐ撤回します） ユーザーには`DxLibEx::Graph2D::DrawGraph`とフルで指定したり、メンバ関数の方を使う方法も残されているわけですから、「使いたくない人は使わなくても良い」が通用する類のものだと思っています。 - まとめ：わざわざできなくする必要はないのでは？

> namespaceで包む必要 「異なるスコープに同じ名前があったとしてもnamespaceがあれば問題は起こらない」というのがnamespaceで包む理由なのですが、弱いでしょうか？ > 統一感がない 現状のコードは思い付きで作ったものなので統一感がないと言われても仕方がありませんね...。 しかし、統一感はnamespaceのあるなしよりもっと別のところに問題があるような気がします。 > moveと明示しなければコピーされる、というのがC++erの常識 このクラスをどうとらえるかによりますかね...。 グラフィックを表すクラスととらえた場合はそれが当然の動作ですが、 グラフィックハンドルを表すクラスととらえた場合はdeep copyは避けポインタのようなコピーのふるまいをするべきだと思います。 僕は後者のつもりで書いていました。 前者のふるまいと後者のふるまいどちらが適切なのでしょうか？

では、 グラフィックそのものを表す DxLibのインターフェースとは異なる(LoadGraph以外はメンバ関数のみの) クラスにする、で良いでしょうか？

わかりました。ちょっと作り直してみます。 ScreenクラスはTexcure2Dを継承ですか？

例えばDrawGraph関数は引数にMakeScreenで作ったハンドルが渡されても、LoagGraph等で作ったハンドルが渡されても同様にグラフィックハンドルが渡されたものとして動作します。 なのでScreenもTexcure2Dとみなすことができたほうが良いと思ったのですが...。 ちなみに実装もそちらのほうがしやすいのです。（別々にするとLoagGraphをTexcure2DとScreenの双方に書く必要があります） 継承（というよりそれに伴うvirtual関数）はサイズ的にはメンバ変数にintが一つ増えるくらい重くなります。誤差の範疇です。

> いっそScreenなくして そうすると今度はSetDrawScreenにLoagGraph等で作ったハンドルを渡せないという問題が発生しますが...。

えーと。ScreenクラスはMakeScreen関数で作った描画可能画像を表すクラスですよね？ そこに書き込むためにはSetDrawScreenを呼び出す必要があるわけですが、この引数はMakeScreen関数の戻り値のハンドルである必要があります。 つまり、LoagGraph関数の戻り値のハンドルを持っているかもしれないTexcure2Dクラスにdraw関数を付けることはできません。 > 現在のscreenを習得する方法 GetDrawScreenのことですか？