這應該不明確嗎？（隱式強制轉換）

struct A 
{ 
    A(const A& src); 
    A(const char* src); 
}; 
struct B 
{ 
    operator A(); 
    operator char*(); 
}; 
void test() 
{ 
    B v; 
    A s(v); 
}

EDG/Comeau和MSVC允許代碼，而GCC 4.4.4，CLANG和BCC 將它拒絕爲不明確。這應該不明確嗎？（隱式強制轉換）

A C++委員會成員回答說與此（最初）：

它不是不明確; A（const A &）構造函數優於A（const char *）構造函數。 const的甲& 參數直接結合的結果轉換函數的，所以轉換序列被認爲是是一個用戶定義的轉換由一個標識轉換（13.3.3.1.4p1），接着。 const char * 參數是用戶定義的轉換，後面是限定條件轉換，所以更糟糕。

然後，他跟着這個。

其實我錯了。雖然事實，在一個用戶定義的轉換序列中的第二轉換序列是決勝局，在13.3.3.2p3尋找更多緊密結合，在未來到最後一顆子彈，表明這決勝局只適用於當兩個序列包含相同的用戶定義的轉換序列，而在本例中不是這種情況。由於一個構造的轉換序列使用B ::操作員A（）和其他用途B ::操作者的char *（），有兩個用戶定義的轉換序列和它們是模棱兩可之間沒有決勝局。

我的問題是這樣的。

13.3.3.2 P3指出，的相同的形式

兩個隱式轉換的序列是無法區分的轉換序列除非的以下規則中的一個應用。

從我的理解，這些關鍵字是「以下規則之一」。這並不意味着聲明「相同轉換序列」的項目符號覆蓋了上述所有項目。我會認爲「S1的排名比S2的排名更好」可以用來代替嗎？

來源

2010-11-24 Zach Saw

+12

很好的證明，C++得到它有點太複雜了...... – Hexagon 2010-11-24 05:45:12

既然你有一個C++社區成員聯繫，你不應該只是要求他提出問題嗎？（或檢查是否在http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html提交） – 2010-11-24 06:13:09

我沒有說有問題，我實際上試圖瞭解標準。 – 2010-11-24 06:25:12

是的，預期的結果是模糊到最好的我喜歡的類型「B」的第13.3.3.2

匹配的參數「V」的解釋任的「A」重載構造函數的參數要求用戶定義的轉換。這兩個序列都是CONVERSION等級。

我的解釋是，從$ 13.3.3.2以下報價適用

[...]用戶自定義轉換序列 U1是一個更好的轉換序列比另一種用戶自定義轉換序列U2 如果它們包含相同的用戶定義的轉換函數或構造和如果U1的第二標準轉換序列比所述第二標準的轉換更好 U2的序列。

這兩個都會調用類「B」中的不同轉換函數。因此，我認爲第一個條件本身並不滿足，因此預期的結果是模糊性，因爲任何一個轉換序列都比另一個更好。

來源

2010-11-24 10:18:38 Chubsdad

~~免責聲明：標準對這些部分來說確實很複雜，所以我的理解可能完全錯誤。~~

標準清晰度最佳可行功能（13.3。3）：

根據這些定義，一個可行的功能F1被定義爲比另一種可行的功能 F2更好功能，如果對所有的參數我，ICSI（F1）是並不比更糟糕的轉換序列 ICSI（F2），然後

[...]

上下文是由用戶定義的轉換的初始化（見第8.5節， 13.3.1.5和13.3.1.6）和F1 的到目的地類型（即，實體的類型被初始化的返回類型的標準轉換序列）比標準更好轉換序列從返回類型的F2到目標類型的轉換序列。

~~如果我理解正確的話，被構造的對象的類型這裏有它的重要性，這將使 A::A(const A &)更好的人選。~~

參考約翰內斯評價明白爲什麼這個答案是不正確：這確實是曖昧的原因中指出Chubsdad。

來源

2010-11-24 08:28:46 icecrime

這應該不明確嗎？ （隱式強制轉換）

回答

相關問題

這應該不明確嗎？（隱式強制轉換）