Quindi, cosa usi?
int anInt = (int)aFloat;
o
int anInt = static_cast<int>(aFloat);
// and its brethren
E, ancora più importante, perché?
Innanzitutto, comprendi che quelle righe non sono equivalenti .
int* anInt = (int*)aFloat; // is equivalent to
int* anInt = reinterpret_cast<int*>(aFloat);
Quello che sta succedendo qui è che il programmatore chiede al compilatore di fare tutto il possibile per fare il cast.
La differenza è importante perché l'uso di static_cast richiede solo un tipo di base che è "sicuro" per la conversione, dove reinterpret_cast si convertirà in qualsiasi cosa, possibilmente semplicemente mappando il layout di memoria desiderato sulla memoria dell'oggetto dato.
Quindi, poiché il "filtro" non è lo stesso, l'uso di cast specifici è più chiaro e sicuro rispetto all'utilizzo del cast di C, se ti affidi al compilatore (o al sistema di runtime se usi dynamic_cast) per dirti dove ha fatto qualcosa di sbagliato, evitando C cast e reinterepret_cast.
Ora questo è più chiaro, c'è un'altra cosa: static_cast, reinterpret_cast, const_cast e dynamic_cast sono più facili da cercare .
E il punto finale: sono brutti . Questo è voluto Codice potenzialmente buggato, odori di codice, ovvi "trucchi" che potrebbero generare bug, sono più facili da rintracciare quando associati a sguardi brutti. Il codice errato dovrebbe essere brutto .
Questo è "in base alla progettazione". E ciò consente allo sviluppatore di sapere dove avrebbe potuto fare le cose meglio (evitando totalmente i cast, se non proprio necessario) e dove va bene ma è "documentato" nel codice "contrassegnandolo" come brutto.
A secondary reason for introducing the new-style cast was that C-style casts are very hard to spot in a program. For example, you can't conveniently search for casts using an ordinary editor or word processor. This near-invisibility of C-style casts is especially unfortunate because they are so potentially damaging. An ugly operation should have an ugly syntactic form. That observation was part of the reason for choosing the syntax for the new-style casts. A further reason was for the new-style casts to match the template notation, so that programmers can write their own casts, especially run-time checked casts.
Maybe, because static_cast is so ugly and so relatively hard to type, you're more likely to think twice before using one? That would be good, because casts really are mostly avoidable in modern C++.
I cast di C ++ sono più restrittivi (quindi esprimi meglio il tuo intento e rendi più facile la revisione del codice, ecc.). Sono anche molto più facili da cercare, se mai ne hai bisogno.
Opzione C: un cast "stile C ++", perché non è distinguibile da una costruzione:
int anInt = int(aFloat);
o anche:
int anInt(aFloat);
A parte questo, oltre a questi casi banali con i primitivi, che sono ben compresi, preferisco usare x_cast < > s sui cast in stile C. Ci sono tre ragioni per cui:
Definiscono in modo più preciso l'operazione che il programmatore stava tentando di eseguire.
Possono eseguire azioni che i cast di stile C non possono (specialmente nel caso di dynamic_cast < & gt ;, che possono essere sottoposti a cross-cast attraverso rami di una catena di ereditarietà multipla).
Sono brutti . Dichiarano a gran voce che il programmatore sta lavorando contro il sistema di tipi. In questo caso, è una cosa buona .
Se si scrive codice in C si usa un cast di Do. Se scrivi in C ++ usa un cast di C ++.
Mentre la maggior parte dei casting rompe la corretta sicurezza del tipo, quelli di C ++ sono più restrittivi, e quindi sei un po 'meno sicuro dal punto di vista del testo rispetto a un cast di C.
Posso tollerare che qualcuno usi (T *) NULL per forzare un sovraccarico ...
Ho alcune regole sui cast di stile C / C ++:
const_cast
. Per ovvie ragioni. Purtroppo, la mia regola sulla disapplicazione di un const che ha causato il raggiungimento della tastiera e la rottura del dito del programmatore non è stata approvata. reinterpret_cast
. È davvero il tipo di cast che C non ha: fingere che i bit di questo intero siano in realtà dei bit di un float. Questo evita sgradevoli come (int)(*(int*)(&floatVar))
. dynamic_cast
", interrompi e rivaluta la gerarchia delle classi polimorfiche e il design. Continua a rivalutare la progettazione della gerarchia di classi finché non riesci a eliminare quelle parole. static_cast
. Il ragionamento alla base di # 4 è semplicemente che non ha importanza. Le circostanze che non si adattano alle altre regole sono ovvie o veramente di basso livello. Una conversione ben compresa di tipi semplici come int-to-float non dovrebbe richiedere una sintassi speciale. E se sei nel profondo, brutto coraggio di qualcosa, beh, sei nel profondo, brutto coraggio di qualcosa. Non c'è bisogno di attirare l'attenzione sul fatto che "qui ci sono i draghi", dal momento che i denti, gli artigli e il fuoco lo hanno praticamente dato già.
Dipende davvero dalla lingua con cui lavoro, dal momento che sai cosa dicono: a Roma parla Roman. Quindi, se sto programmando in C, cerco di usare al massimo le caratteristiche di C, ma se sto programmando in C ++ vado avanti e uso le funzionalità di C ++ al massimo, anche se alcune persone non amano questo approccio perché dicono che rende il codice "meno portabile", dico che non mi interessa, sono in C ++ e programmazione in C ++, e ho bisogno di un compilatore completamente compatibile con C ++ per compilare il codice, altrimenti avrei lavorato con qualcosa di diverso innanzitutto.
static_cast ecc. sono stati inventati a causa di problemi con i cast di stile C quando usati nei template. Se stai scrivendo un modello, o se il codice potrebbe essere successivamente convertito in un modello, è una buona idea usare i cast di stile C ++. Il motivo è dovuto al fatto che lo stile C ++ esegue meglio l'intento esplicito, in modo che forniscano i risultati previsti nei casi in cui i cast di tipo C faranno la cosa sbagliata (dati particolari tipi di parametri del modello).
Oltre a questo, dico usare cast di stile C ++ se hai un problema specifico che ne ha bisogno - dynamic_cast è il più comune, ma anche quello probabilmente non è una cosa di tutti i giorni.
Qualsiasi altra cosa, e un cast di stile C potrebbe essere un po 'meno confuso e aiutare la leggibilità, o forse non a seconda di quanto sia familiare il lettore con lo stile del cast in questi giorni. A mio avviso, non è molto importante, soprattutto una preferenza personale, anche se non sorprenderti se a qualcuno non piace lo stile C.
Nota finale: se hai bisogno di così tanti cast che questo è un grosso problema, probabilmente stai sbagliando qualcos'altro. Ci sono delle eccezioni in alcuni casi, ma la maggior parte del codice di alto livello non dovrebbe richiedere molti (se ce ne sono).
Leggi altre domande sui tag c++ type-casting