この場合、変換演算子は有効ですか？

Question

通常、書籍は通常、構造体をラップする際に変換演算子の使用を推奨しません。たとえば、Cのchar配列のラッパーであると考えられるC++文字列は、変換演算子を提供しません。代わりに、メソッドc_str()を与えます。

しかし、私は真剣に私のケースが例外かもしれないと思う。私はSDL_Surface.をラップしています。ここにクラス宣言があります。この場合

/** Wraps up SDL_Surface **/ 
class surface 
{ 
    SDL_Surface* _surf; 
public: 
    /** calls SDL_LockSurface(). 
    ** throws surface_lock_exception on failure. 
    **/ 
    void lock(); 

    /** calls SDL_UnlockSurface() **/ 
    void unlock(); 

    /** calls SDL_LoadBMP(). 
    ** throws image_load_exception on failure. 
    **/ 
    void load_bmp(const string&); 

    /** calls SDL_FreeSurface(). **/ 
    void free(); 

    /** destructor. Also free()s the internal SDL_Surface. **/ 
    ~surface(); 
}; 

、私は真剣に、私はSDL_Surface*を必要とする他のSDL機能と容易に互換性のためにSDL_Surface*に変換演算子を追加するべきだと思います。

あなたはどう思いますか：

1. 変換演算子が賢明だろうか？
2. またはc_str()のような方法を使用する必要がありますか？
3. もう1つ、より良い解決策がありますか？

Answer 1

新しい演算子のラッパークラスを既存のSDLライブラリ関数に渡すには、変換演算子を用意する必要がありますが、本当に必要かどうかを自問する必要があります。

c_str()が存在する理由は、C++プログラマがstd::stringを使用し、これまで聞いたことがない古いランタイムライブラリ関数をすべて呼び出せるようにするためです。 C++プログラムを初めから書いているのであれば、関数呼び出しのどれかがconst char*になるでしょうか？いいえ、おそらくconst std::string&になります。

SDLを素敵なライブラリにまとめている場合は、が基礎となるデータ構造を公開する必要があるかどうかを尋ねる必要があります。確かにあなたの図書館はいつもSurfaceと話したいと思っていますし、何が起こっているのか気にしませんか？

私の好ましい解決策は、それを隠して、下にあるSDLライブラリを扱うクラスをそうすることです。

Answer 2

理想的には、別の方法を提供する必要があります。
変換演算子の問題は、変換オペレータが使用したくない/期待していないシーンの暗黙のうちに呼び出される可能性があることです。特別な方法を提供することは、これに対してシーンの魔法を防ぎます。