Verifica del puntatore NULL in C / C ++ [chiuso]

In una recente revisione del codice, un collaboratore sta cercando di imporre che tutti i NULLcontrolli sui puntatori vengano eseguiti nel modo seguente:

int * some_ptr;
// ...
if (some_ptr == NULL)
{
    // Handle null-pointer error
}
else
{
    // Proceed
}

invece di

int * some_ptr;
// ...
if (some_ptr)
{
    // Proceed
}
else
{
    // Handle null-pointer error
}

Sono d'accordo che il suo modo sia un po 'più chiaro nel senso che sta esplicitamente dicendo "Assicurati che questo puntatore non sia NULL", ma lo contrasterei dicendo che chiunque sta lavorando su questo codice capirà che l'uso di una variabile puntatore in un ifL'istruzione sta implicitamente controllando NULL. Inoltre penso che il secondo metodo abbia una minore possibilità di introdurre un bug delk:

if (some_ptr = NULL)

che è solo un dolore assoluto da trovare ed eseguire il debug.

In che modo preferisci e perché?

Nella mia esperienza, sono preferiti i test del modulo if (ptr)o if (!ptr). Non dipendono dalla definizione del simbolo NULL. Non espongono l'opportunità per l'assegnazione accidentale. E sono chiari e concisi.

Modifica: Come sottolinea SoapBox in un commento, sono compatibili con le classi C ++ come ad esempio auto_ptroggetti che fungono da puntatori e che forniscono una conversione boolper abilitare esattamente questo idioma. Per questi oggetti, un confronto esplicito NULLdovrebbe invocare una conversione in puntatore che potrebbe avere altri effetti collaterali semantici o essere più costoso del semplice controllo dell'esistenza che la boolconversione implica.

Ho una preferenza per il codice che dice cosa significa senza testo non necessario. if (ptr != NULL)ha lo stesso significato di if (ptr)ma a scapito della specificità ridondante. La prossima cosa logica è scrivere if ((ptr != NULL) == TRUE)e in questo modo risiede la follia. Il linguaggio C è chiaro che un valore booleano testato da if, whileo simili ha una specifica significato di valore diverso da zero è vero e lo zero è falso. La ridondanza non lo rende più chiaro.

if (foo)è abbastanza chiaro. Usalo

Inizierò con questo: la coerenza è il re, la decisione è meno importante della coerenza nella tua base di codice.

In C ++

NULL è definito come 0 o 0L in C ++.

Se hai letto Il linguaggio di programmazione C ++ Bjarne Stroustrup suggerisce di usare 0esplicitamente per evitare la NULLmacro durante l'assegnazione , non sono sicuro che abbia fatto lo stesso con i confronti, è passato un po 'di tempo da quando ho letto il libro, penso che abbia appena fatto if(some_ptr)senza un confronto esplicito, ma sono confuso su questo.

La ragione di ciò è che la NULLmacro è ingannevole (come quasi tutte le macro) in realtà è 0letterale, non un tipo unico come suggerisce il nome. Evitare le macro è una delle linee guida generali in C ++. D'altra parte, 0sembra un numero intero e non lo è se confrontato o assegnato ai puntatori. Personalmente potrei andare in entrambi i modi, ma in genere ignoro il confronto esplicito (anche se ad alcune persone questo non piace, questo è probabilmente il motivo per cui hai un collaboratore che suggerisce comunque un cambiamento).

Indipendentemente dai sentimenti personali, questa è in gran parte una scelta del minimo male in quanto non esiste un metodo giusto.

Questo è chiaro e un linguaggio comune e lo preferisco, non c'è possibilità di assegnare accidentalmente un valore durante il confronto e si legge chiaramente:

if(some_ptr){;}

Questo è chiaro se sai che some_ptrè un tipo di puntatore, ma può anche apparire come un confronto intero:

if(some_ptr != 0){;}

Questo è chiaro, nei casi comuni ha senso ... Ma è un'astrazione che perde, NULLè in realtà 0letterale e potrebbe finire per essere abusato facilmente:

if(some_ptr != NULL){;}

C ++ 0x ha nullptr che ora è il metodo preferito in quanto è esplicito e preciso, basta fare attenzione all'assegnazione accidentale:

if(some_ptr != nullptr){;}

Fino a quando non sarai in grado di migrare a C ++ 0x, direi che è una perdita di tempo preoccuparsi di quale di questi metodi usi, sono tutti insufficienti ed è per questo che è stato inventato nullptr (insieme a problemi di programmazione generici che sono emersi con un perfetto inoltro .) La cosa più importante è mantenere la coerenza.

In C.

C è una bestia diversa.

In C NULL può essere definito come 0 o come ((void *) 0), C99 consente costanti puntatore null definite dall'implementazione. Quindi, in realtà, si riduce alla definizione di NULL dell'implementazione e dovrai ispezionarla nella tua libreria standard.

Le macro sono molto comuni e in generale vengono utilizzate molto per compensare le carenze nel supporto della programmazione generica nel linguaggio e in altre cose. Il linguaggio è molto più semplice e la dipendenza dal pre-processore è più comune.

Da questa prospettiva probabilmente consiglierei di usare la NULLdefinizione macro in C.

Lo uso if (ptr), ma non vale assolutamente la pena discuterne.

Mi piace la mia strada perché è concisa, anche se altri dicono che == NULLrende più facile la lettura e più esplicita. Vedo da dove vengono, non sono d'accordo che le cose extra lo rendono più facile. (Odio la macro, quindi sono di parte.) A te.

Non sono d'accordo con la tua tesi. Se non ricevi avvisi per le assegnazioni in modo condizionale, devi aumentare i livelli di avviso. Semplice come quella. (E per l'amore di tutto ciò che è buono, non cambiarli.)

Nota in C ++ 0x, possiamo fare if (ptr == nullptr), che per me fa più bello di lettura. (Ancora una volta, odio la macro. Ma nullptrè carino.) Lo faccio if (ptr)comunque, solo perché è quello a cui sono abituato.

Francamente, non vedo perché sia ​​importante. Uno dei due è abbastanza chiaro e chiunque abbia una moderata esperienza con C o C ++ dovrebbe capire entrambi. Un commento, però:

Se si prevede di riconoscere l'errore e non si continua a eseguire la funzione (ovvero, si genererà un'eccezione o si restituirà immediatamente un codice di errore), è necessario renderlo una clausola di protezione:

int f(void* p)
{
    if (!p) { return -1; }

    // p is not null
    return 0;
}

In questo modo, eviti il ​​"codice freccia".

Personalmente l'ho sempre usato if (ptr == NULL)perché rende esplicito il mio intento, ma a questo punto è solo un'abitudine.

L'utilizzo =al posto di ==verrà rilevato da qualsiasi compilatore competente con le impostazioni di avviso corrette.

Il punto importante è scegliere uno stile coerente per il tuo gruppo e attenersi ad esso. Indipendentemente dal modo in cui vai, alla fine ti abituerai e la perdita di attrito quando lavorerai nel codice di altre persone sarà il benvenuto.

Solo un altro punto a favore della foo == NULLpratica: se fooè, diciamo, un int *o un bool *, allora il if (foo)controllo può essere accidentalmente interpretato da un lettore come test del valore della punta, cioè come if (*foo). Il NULLconfronto qui è un promemoria che stiamo parlando di un puntatore.

Ma suppongo che una buona convenzione di denominazione metta in discussione questo argomento.

In realtà, utilizzo entrambe le varianti.

Esistono situazioni in cui si verifica prima la validità di un puntatore e, se è NULL, si ritorna / esci da una funzione. (So ​​che questo può portare alla discussione "una funzione dovrebbe avere solo un punto di uscita")

Il più delle volte, si controlla il puntatore, quindi si fa quello che si desidera e quindi si risolve il caso di errore. Il risultato può essere il brutto codice rientrato x-times con più if.

Il linguaggio di programmazione C (K&R) ti farebbe controllare null == ptr per evitare un'assegnazione accidentale.

Se lo stile e il formato faranno parte delle tue recensioni, ci dovrebbe essere una guida di stile concordata su cui misurare. Se ce n'è uno, fai quello che dice la guida di stile. Se non ce n'è uno, dettagli come questo dovrebbero essere lasciati mentre sono scritti. È una perdita di tempo ed energia e distrae da ciò che le recensioni di codice dovrebbero davvero scoprire. Scherzi a parte, senza una guida di stile spingerei a NON modificare il codice in questo modo per principio, anche quando non usa la convenzione che preferisco.

E non è importante, ma la mia preferenza personale è if (ptr). Il significato per me è più immediatamente evidente che persino if (ptr == NULL).

Forse sta cercando di dire che è meglio gestire le condizioni di errore prima del percorso felice? In tal caso, non sono ancora d'accordo con il revisore. Non so che ci sia una convenzione accettata per questo, ma secondo me la condizione più "normale" dovrebbe venire prima in ogni affermazione if. In questo modo ho meno scavi da fare per capire di cosa tratta la funzione e come funziona.

L'eccezione a ciò è se l'errore mi fa uscire dalla funzione, o posso recuperare da essa prima di andare avanti. In questi casi, gestisco prima l'errore:

if (error_condition)
  bail_or_fix();
  return if not fixed;

// If I'm still here, I'm on the happy path

Affrontando in anticipo l'insolita condizione, posso occuparmene e poi dimenticarmene. Ma se non riesco a tornare sul percorso felice gestendolo in anticipo, allora dovrebbe essere gestito dopo il caso principale perché rende il codice più comprensibile. Secondo me.

Ma se non è in una guida di stile, allora è solo la mia opinione e la tua opinione è altrettanto valida. Standardizzare o no. Non lasciare che un revisore pseudo-standardizzi solo perché ha un'opinione.

Questo è uno dei fondamenti di entrambi i linguaggi che i puntatori valutano su un tipo e un valore che possono essere usati come espressione di controllo, boolin C ++ e intin C. Basta usarlo.

• I puntatori non sono booleani
• I compilatori C / C ++ moderni emettono un avviso quando si scrive if (foo = bar)per caso.

Quindi preferisco

if (foo == NULL)
{
    // null case
}
else
{
    // non null case
}

o

if (foo != NULL)
{
    // non null case
}
else
{
    // null case
}

Tuttavia, se stessi scrivendo una serie di linee guida di stile, non inserirò cose come questa, inserirò cose come:

Assicurati di fare un controllo nullo sul puntatore.

Sono un grande fan del fatto che C / C ++ non verifica i tipi nelle condizioni booleane a if, fore whilele dichiarazioni. Uso sempre quanto segue:

if (ptr)

if (!ptr)

anche su numeri interi o altri tipi che vengono convertiti in bool:

while(i--)
{
    // Something to do i times
}

while(cin >> a >> b)
{
    // Do something while you've input
}

La codifica in questo stile è più leggibile e più chiara per me. Solo la mia opinione personale.

Di recente, mentre lavoravo con il microcontrollore OKI 431, ho notato che:

unsigned char chx;

if (chx) // ...

è più efficiente di

if (chx == 1) // ...

perché in un secondo momento il compilatore deve confrontare il valore di chx con 1. Dove chx è solo un flag vero / falso.

La maggior parte dei compilatori che ho usato avvertirà almeno ifdell'incarico senza ulteriore sintassi dello zucchero, quindi non compro quell'argomento. Detto questo, ho usato entrambi in modo professionale e non ho preferenze per nessuno dei due. Il == NULLè sicuramente più chiara anche se a mio parere.