2012-02-21 10 views
7

Estoy pensando en reemplazar todas las instancias de idioma de bool seguro por explicit operator bool en código que ya utiliza características C++ 11 (por lo que el hecho de que los compiladores anteriores no reconocen conversión explícita los operadores no importarán), así que me gustaría saber si puede causar algunos problemas sutiles.Incompatibilidades entre idioma bool seguro y operador explícito bool

Por lo tanto, ¿cuáles son todas las posibles incompatibilidades (incluso los más mínimos) que pueden ser causados ​​por el cambio de idioma bool segura de edad y sin brillo a la nueva y brillante explicit operator bool?

EDIT: Sé que la conmutación es una buena idea de todos modos, ya que esta última es una característica de idioma, bien entendida por el compilador, por lo que no va a funcionar peor de lo que en realidad es un truco. Simplemente quiero saber las posibles diferencias.

Respuesta

3

Si ha utilizado la conversión segura-bool de forma incorrecta en su código, solo entonces explicit operator bool será incompatible, ya que no le permitiría hacer las cosas incorrectamente de esa manera. De lo contrario, debería estar bien sin ningún problema. De hecho, incluso si hay un problema, todavía debe cambiar a explicit operator bool, porque si lo hace, entonces podría identificar el problema en el uso de la conversión segura-bool.

Según this article, algunos compiladores emiten instrucciones ineficientes para la ejecución segura-bool utilizando puntero de función miembro,

Cuando la gente comenzó a usar este lenguaje, se descubrió que había una pena de eficiencia en algunos compiladores - la El puntero de la función miembro provocó un dolor de cabeza en el compilador, lo que provocó una ejecución más lenta cuando se buscó la dirección. Aunque la diferencia es marginal, la práctica actual suele ser utilizar un puntero de datos miembro en lugar de un puntero de función miembro.

+0

Por supuesto que tienes razón. Pero hay una razón por la que etiqueté esto con 'language-lawyer'. Me gustaría obtener hechos puros del estándar en sí, no un consejo sobre buenas prácticas. Tengo que aclarar eso, pero gracias de todos modos. – Fanael

+0

@Fanael: Los estándares, C++ 03 y C++ 11 ambos, no hablan de expresiones idiomáticas de salvo-bool, por lo que no es posible citarlo para respaldar lo que dije. Todo lo que estoy implícito es que C++ 11 ha introducido 'operator bool explícito' para razón (s), y una de las razones, creo, es' explicit operator bool' es ** más seguro ** que el llamado lenguaje seguro-bool. – Nawaz

+1

Pero el estándar habla sobre las cosas que se usan para implementar el modismo Safe-bool. Por lo tanto, aunque el estándar no dice nada acerca de ese idioma en sí mismo, sus garantías exactas están prácticamente implícitas en el documento. – Fanael

4

Probablemente la mayor diferencia, asumiendo que su código es libre de errores (lo sé, no es una suposición segura), será que, en algunos casos, es posible que desee una conversión implícita a exactamente bool. Una función de conversión explicit no coincidirá.

struct S1 
{ 
    operator S1*() { return 0; } /* I know, not the best possible type */ 
} s1; 

struct S2 
{ 
    explicit operator bool() { return false; } 
} s2; 

void f() 
{ 
    bool b1 = s1; /* okay */ 
    bool b2 = s2; /* not okay */ 
} 
+2

Eso no es lenguaje seguro-bool. – Nawaz

+4

Ya había notado que el tipo de puntero que utilicé no es el mejor posible, sirve bien como ejemplo porque las diferencias entre esto y una implementación correcta son irrelevantes para mi respuesta, y esto es más legible. – hvd