在这种情况下转换运算符是否有效？答案

【问题标题】：Is a Conversion Operator Valid in this Case?在这种情况下转换运算符是否有效？
【发布时间】：2012-03-12 11:13:01
【问题描述】：

通常，书籍通常不鼓励在包装 c 结构时使用转换运算符。例如，c++ 字符串（被认为是）是 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_Surface* 的 SDL 函数兼容。

你怎么看：

转换操作员会谨慎吗？
还是应该使用c_str()之类的方法？
或者还有其他更好的解决方案吗？

【问题讨论】：

标签： c++ oop operator-keyword conversion-operator

【解决方案1】：

虽然需要提供一个转换运算符来将您的新包装类传递给现有的 SDL 库函数，但您必须问自己是否真的需要。

c_str() 之所以存在，是为了让我们 C++ 程序员可以使用std::string，然后调用所有那些从未听说过的过时的运行时库函数。如果您正在从头开始编写 C++ 程序，您的任何函数调用都会采用const char* 吗？不，他们可能会使用const std::string&。

因此，如果您将 SDL 封装在一个不错的库中，那么您必须询问您是否应该曾经公开底层数据结构。您的图书馆肯定会一直想与Surface 交谈，而不关心下面发生了什么？

所以我首选的解决方案是将其隐藏起来，让那些处理底层 SDL 库的类这样做。

【讨论】：

【解决方案2】：

理想情况下，您应该提供一个单独的方法。
转换运算符的问题在于，它可能会在您不希望/不希望使用它的幕后被隐式调用。提供一种特殊的方法可以保护您免受这种幕后魔法的侵害。

【讨论】：

C++11 中引入了显式类型转换，想必这抵消了不使用类型转换运算符的原因？
@hmjd：是的，但是 Q 没有标记为 c++11，所以我假设 OP 可以与 C++03 一起使用。
Als，我知道它没有被标记为 C++11。只是想确认我相信的愿望。干杯。
@hmjd：没问题。实际上，在实际项目中迁移到 c++11 需要一段时间，过渡不会很快。