重載全局類型轉換運算符

Question

為了測試和顯示我的庫的某些功能的結果，我正在創建一組方便的功能。

我有一個execute函數，看起來像：

template <typename R, typename I>
std::string execute( const std::string& func_name, R(*func_ptr)( const I& ), const I& func_input );

它調用該函數，並在格式化的字符串中顯示結果和參數，我可以將其發送到std::cout 。

問題是我的一些函數沒有返回convertible-to-string結果。 我以為我可以簡單地重載global ::operator std::string ，例如：

template <typename T>
operator std::string( const std::vector<T>& v );

但海灣合作委員會抱怨說：

error: 'operator std::string(const std::vector<T, std::allocator<_CharT> >&)' must be a nonstatic member function

好吧，問題當然是我不能將成員運算符添加到std::vector ，甚至對於我的類，我也不想用“for testing”轉換運算符來污染它們。

我想我可以添加一個間接層並使用函數而不是轉換運算符，但這不是更美觀的解決方案。 我也可以重載::operator << for std::ostream並使用std::ostringstream ，但這也不是最干凈的解決方案。

我想知道全局轉換運算符是否真的不能超載，如果是，為什么呢。

Answer 1

轉換運算符（強制轉換運算符）必須是生成轉換類型的可轉換類的成員。 作為賦值運算符，它們必須是成員函數，正如編譯器告訴您的那樣。

根據您希望將多少工作量放入調試部分，您可以嘗試使用元編程將執行方法轉發到不同的實際實現，為將打印內容的容器提供特定的實現方法。

為什么你不想為你的類型提供operator<< ？ 我認為這實際上是慣用的解決方案。 與使用轉換為字符串以產生可打印結果的方法的其他語言不同，在C ++中，慣用方法是提供operator<<然后使用stringstreams （或boost::lexical_cast或類似的解決方案）來轉換為基於operator<<字符串operator<<實施。 這里有一個簡單的實用程序類，用於從覆蓋operator<<元素創建一個string ，如果你想將它用作起點。

Answer 2

我想知道全局轉換運算符是否真的不能超載，如果是，為什么呢。

不，沒有這樣的事情。 轉換函數必須是類的成員。 如果不是這樣，那么通過引入歧義會使重載決策成為編譯器特別棘手的問題。

Answer 3

沒有用戶定義的全局轉換運算符。 您必須控制目標類型（在這種情況下，非顯式的一個參數構造函數是轉換運算符）或源類型（在這種情況下，您必須重載成員運算符target（））。

Answer 4

不幸的是，沒有全球鑄造運營商這樣的東西。 出奇。 但模板是你的朋友。

有時您不希望將轉換暴露給接口，而是希望僅針對特定實現保持匿名。 我通常在類中添加一個模板as（）方法，它也可以在強制轉換等中進行類型檢查，並讓你處理你想要實現強制轉換的方式（例如dynamic，shared，ref等）。

像這樣的東西：

    template< class EvtT >const EvtT& as() const throw( std::exception )
    {
        const EvtT* userData = static_cast<const EvtT*>( m_UserData );
        ASSERT( userData, "Fatal error! No platform specific user data in input event!" );
        return *userData;
    }

m_UserData是一個匿名類型，只有實現知道。 雖然這是嚴格的非類型轉換（我不在這里使用類型cecks），但可以用dynamic_cast和正確的轉換異常代替。

實現只是這樣做：

    unsigned char GetRawKey( const InputEvent& ie )
    {
        const UserEvent& ue = ie.as<const UserEvent>();
        ...

Answer 5

轉換函數必須是成員函數。 該函數可能未指定返回類型，參數列表必須為空。 它們應該謹慎使用，並且應該有一種從一種類型到另一種類型的明確轉換路徑。 否則他們可能會導致意想不到的結果和神秘的錯誤。