struct S {};

struct Testable
{
  template <class T>
  operator T() /* = delete */;       //a)

  operator bool() {return true;}     //b)
};

int main()
{
  Testable t;
  bool b = t;  //1)
  int i = t;   //2)
  S s = t;     //3)
};

Meine Erwartung wäre folgende:

1. ruft b)
2. ruft a)<int>, -> Fehler (Linker bzw. deleted)
3. ruft a)<S>, -> Fehler (Linker bzw. deleted)

Verhalten MSVC: wie erwartet.
Verhalten gcc-4.5.1 (ideone.com): 2) ruft b), kein Fehler!

Welches ist richtig?

Der Fall für Fortgeschrittene:

#include <type_traits>  

struct S {};

struct Testable
{
  template <class T>
  operator typename std::enable_if<std::is_convertible<bool, T>::value, T>::type () /* = delete */;       //a)

  operator bool() {return true;} //b)
};

int main()
{
  Testable t;
  bool b = t; //1)
  int i = t;  //2)
  S s = t;    //3)
};

Meine Erwartung:

1. ruft b)
2. ruft a) -> Fehler (Linker/deleted)
3. Compilerfehler, keine Konvertierung gefunden.

Verhalten MSVC und gcc-4.5.1 (ideone.com): 2) ruft b), kein Fehler!

Tach zusammen. Folgender Code:

struct S {};
 
struct Testable
{
  template <class T>
  operator T() /* = delete */;       //a)
 
  operator bool() {return true;}     //b)
};
 
int main()
{
  Testable t;
  bool b = t;  //1)
  int i = t;   //2)
  S s = t;     //3)
};

Meine Erwartung wäre folgende:

1. ruft b)
2. ruft a)<int>, -> Fehler (Linker bzw. deleted)
3. ruft a)<S>, -> Fehler (Linker bzw. deleted)

Verhalten MSVC: wie erwartet.
Verhalten gcc-4.5.1 (ideone.com): 2) ruft b), kein Fehler!

Welches ist richtig?

Ich würde auch das Ergebnis von msvc erwarten, Online-Comeau stimmt allerdings mit g++ überein (für den Online-Comeau habe ich { return 0/(sizeof(T)==0); } für operator T() verwendet, ein paar zusätzliche Warnungen entstehen dabei natürlich). Eine implite Konvertierungssequenz mit nutzerdefiniertem Konvertierungsoperator ist besser als eine andere solche Sequenz, wenn die anschließende Standardkonvertierungssequenz einen besseren Rang hat.
In

int i = t;

ist diese zweite Konvertierungssequenz ein "exact match" für operator T mit T=int, und "promotion" für operator bool, letzteres ist schlechter (13.3.3.1.2). Ich habe also keine Erklärung für das Verhalten von g++.

pumuckl schrieb:

Der Fall für Fortgeschrittene:

#include <type_traits>  

struct S {};
 
struct Testable
{
  template <class T>
  operator typename std::enable_if<std::is_convertible<bool, T>::value, T>::type () /* = delete */;       //a)
 
  operator bool() {return true;} //b)
};
 
int main()
{
  Testable t;
  bool b = t; //1)
  int i = t;  //2)
  S s = t;    //3)
};

Meine Erwartung:

1. ruft b)
2. ruft a) -> Fehler (Linker/deleted)
3. Compilerfehler, keine Konvertierung gefunden.

Verhalten MSVC und gcc-4.5.1 (ideone.com): 2) ruft b), kein Fehler!

Der Fall ist einfach.

typename std::enable_if<std::is_convertible<bool, T>::value, T>::type

ist kein deduzierbarer Kontext, also kann kein T deduziert werden, folglich wird auch keine Spezialiserung dieses Templates teil des Überladungssets. Das macht sich unter anderem auch dadruch bemerkbar, dass die Fehlermeldung für 3) diesmal etwas anders aussieht.

#include <type_traits>  
#include <iostream>

struct S {};

struct Testable
{
  template <class T, class = typename std::enable_if<std::is_convertible<bool, T>::value, T>::type>
  operator T() /* = delete */;       //a)

  operator bool() {std::cout << "!\n"; return true;} //b)
};

int main()
{
  Testable t;
  bool b = t; //1)
  int i = t;  //2)
  //S s = t;    //3)
};

Was nach C++0x-Standard zwar das gewünschte Verhalten erzeugen sollte, allerdings daran scheitert, dass GCC hier wieder die Overload resolution verhaut und MSVC noch keine default-Template-Argumente für Funktionstemplates implementiert hat. Gnarf.

Spricht etwas dagegen, das Template für bool explizit zu spezialisieren?

Erstens, dass ich Spezialisierungen von Funktionstemplates nicht so prall finde (ok, schwacher Grund).
Zweitens, dass die ganze enable-if-Geschichte dazu dienen soll, eventuelle andere Konvertierungen mit folgender automatischer Konvertierung zu erlauben, Beispiel:

struct Testable
{
  /* bool, T wie gehabt, oder eben als Spezialisierung */
  operator float() { return 1.0; }
};

/* ... */ 
Testable t;
double d = t; //knallt, wenn das template nicht enable_if'd ist, weil dann t<double> zieht, nicht op float -> promotion
bool b = t; //macht im GCC Probleme, wenn das Template nicht an der Overload resolution teilnimmt. Meh.

Das würde natürlich das enable_if noch mit einem !is_floating_point odr sowas aufblähen, aber ich denke man merkt was ich meine.

Drittens: Autsch: Wie sähe die Spezialisierung für das Template aus?? Ich habs nicht hinbekommen...

struct Testable
{
  template <class T, typename std::enable_if<std::is_convertible<bool, T>::value, bool>::type = true>
  operator T() = delete;       //a)

  template <>
  //operator bool<bool, true>()  //1)
  //operator bool()              //2)
  //operator <bool, true> bool() //3)
  {return "whatever";}
};

Drittens: Autsch: Wie sähe die Spezialisierung für das Template aus?? Ich habs nicht hinbekommen...

Immer außerhalb der Klasse.

13.3.3 Best Viable Function [over.match.best]
...
Given these definitions, a viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then
— for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2), or, if not that,
— F1 is a non-template function and F2 is a function template specialization, or, if not that,
— F1 and F2 are function template specializations, and the function template for F1 is more specialized than the template for F2 according to the partial ordering rules described in 14.5.5.2, or, if not that,
— the context is an initialization by user-defined conversion (see 8.5, 13.3.1.5, and 13.3.1.6) and the standard conversion sequence from the return type of F1 to the destination type (i.e., the type of the entity being initialized) is a better conversion sequence than the standard conversion sequence from the return type of F2 to the destination type. [Example:
struct A {
A();
operator int();
operator double();
} a;
int i = a; // a.operator int() followed by no conversion
// is better than a.operator double() followed by
// a conversion to int
float x = a; // ambiguous: both possibilities require conversions,
// and neither is better than the other
—end example]

n3290 schrieb:

13.3.3 Best viable function [over.match.best]
...
Given these definitions, a viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then
— for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2), or, if not that,
— the context is an initialization by user-defined conversion (see 8.5, 13.3.1.5, and 13.3.1.6) and the standard conversion sequence from the return type of F1 to the destination type (i.e., the type of the entity being initialized) is a better conversion sequence than the standard conversion sequence from the return type of F2 to the destination type. [ Example:
struct A {
A();
operator int();
operator double();
} a;
int i = a; // a.operator int() followed by no conversion
// is better than a.operator double() followed by
// a conversion to int
float x = a; // ambiguous: both possibilities require conversions,
// and neither is better than the other
— F1 is a non-template function and F2 is a function template specialization, or, if not that,
— F1 and F2 are function template specializations, and the function template for F1 is more specialized than the template for F2 according to the partial ordering rules described in 14.5.6.2.

Die Reihenfolge, in der die Alternativen abgearbeitet werden, hat sich offenbar geändert. msvc macht es praktisch so wie im neuen Standard vorgesehen, g++ benutzt (noch) die alten Regeln. Nach den alten Regeln führt allein die Tatsache, dass eine Funktion eine Templatefunktion ist und die andere nicht zur Entscheidung, ein Vergleich der Konvertierungsränge findet gar nicht statt.

Edit: Nachdem klar ist, wonach gesucht werden muss, findet sich auch der zugehörige Report schnell.