2012-02-21 28 views
7

Sto pensando di sostituire tutte le istanze di idioma bool sicuro con explicit operator bool nel codice che utilizza già le caratteristiche C++ 11 (quindi il fatto che i compilatori meno recenti non hanno riconosciuto la conversione esplicita gli operatori non contano), quindi mi piacerebbe sapere se può causare alcuni problemi sottili.Incompatibilità tra safe bool idiom e operatore esplicito bool

Così, che cosa sono tutti le possibili incompatibilità (anche quelli più minuti) che possono essere causati da passaggio da vecchio e noioso sicura bool linguaggio di nuovo e lucido explicit operator bool?

EDIT: So che il passaggio è comunque una buona idea, dato che quest'ultimo è una funzionalità linguistica, ben compresa dal compilatore, quindi funzionerà non di peggio di quello che è in realtà solo un hack. Voglio semplicemente sapere le possibili differenze.

risposta

3

Se hai utilizzato la conversione di Safe Bool in modo errato nel codice, solo allora lo explicit operator bool non è compatibile, in quanto non ti consentirebbe di fare le cose in modo errato così facilmente. Altrimenti, dovrebbe andare bene senza problemi. In effetti, anche se c'è un problema, dovresti comunque passare a explicit operator bool, perché se lo fai, allora potresti identificare il problema nell'uso della conversione di sicuro-bool.

Secondo this article, alcuni compilatori emettono istruzioni inefficienti per l'attuazione di sicurezza bool con puntatore a funzione membro,

Quando la gente iniziato ad usare questo idioma, si è scoperto che c'era un rigore efficienza su alcuni compilatori - il il puntatore della funzione membro ha causato un mal di testa del compilatore con conseguente esecuzione più lenta quando l'indirizzo è stato recuperato. Sebbene la differenza sia marginale, la pratica corrente consiste in genere nell'utilizzare un puntatore dati membro anziché un puntatore funzione membro.

+0

Certo che hai ragione. Ma c'è una ragione per cui l'ho etichettato con "l'avvocato linguistico". Vorrei dei fatti puri che derivino dallo standard stesso, non un consiglio sulle buone pratiche. Devo chiarirlo, ma grazie comunque. – Fanael

+0

@Fanael: The Standards, C++ 03 e C++ 11 entrambi, non parliamo di idioma safe-bool, quindi non è possibile citare da esso per supportare ciò che ho detto. Tutto quello che sto insinuando è che C++ 11 ha introdotto 'bool operatore esplicito' per ragione (s), e uno dei motivi, penso, è' esplicito bool operatore 'è ** più sicuro ** rispetto al cosiddetto idioma di sicuro valore. – Nawaz

+1

Ma lo standard parla delle cose usate per implementare l'idioma di sicurezza. Quindi, mentre lo standard non dice nulla di quello stesso idioma, le sue esatte garanzie sono praticamente implicite nel documento. – Fanael

4

Probabilmente la più grande differenza, supponendo che il codice è esente da bug (lo so, non è un presupposto sicuro), sarà che in alcuni casi, può essere utile una conversione implicita esattamente bool. Una funzione di conversione explicit non corrisponderà.

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

Non è un idioma sicuro. – Nawaz

+4

Avevo già notato che il tipo di puntatore che ho usato non è il migliore possibile, serve come esempio perché le differenze tra questa e una corretta implementazione sono irrilevanti per la mia risposta, e questo è più leggibile. – hvd