Quando si può affermare che un puntatore non è nullo?

Question

Quando si può affermare che un puntatore non è nullo?

#1 da (9 voti)
#2 da (-4 voti)

4

Questo è apparso come parte di una revisione del codice per un segmento di codice simile a questo:

auto somePikachu = GetMeAPikachu();
NT_ASSERT(somePikachu != nullptr); // this only fires on debug build
somePikachu->ThunderBolt();

A mio parere l'assert è ridondante poiché se somePikachu è null si bloccherà comunque nella riga successiva quando tenta di chiamare Thunderbolt . (Ovviamente se ThunderBolt non richiede il dereferenziamento di questo puntatore non succederà nulla sulla versione di rilascio). Quindi l'affermazione non sta comprando nulla IMHO. C'è un'altra scuola di pensiero che è dell'opinione che l'affermazione aggiunge valore alla leggibilità e rende chiaro l'intento del progetto. Mi piacerebbe avere l'opinione della comunità sul modello corretto di affermare il design per la validità dei puntatori. Sentitevi liberi di includere altri possibili scenari che corrispondono alla dichiarazione del problema.

c++ pointers assertions

posta bashrc 14.09.2015 - 11:22

fonte

2 risposte

-4

When is it ok to assert for a pointer being non-null?

Ti direi che non è mai ok usare assert.

Se la condizione non riesce, il programma termina. Ti dà alcune informazioni di debug, ma l'effetto è lo stesso - non qualcosa che desideri vedere agli utenti dell'applicazione.

Se definisci NDEBUG, il controllo scompare. Ma in un caso in cui in qualche modo tale condizione viene soddisfatta, molto probabilmente la tua applicazione finirà con qualche tipo di comportamento indefinito.

Quindi, cosa fare se la condizione non viene soddisfatta? Fai un'eccezione.

E nel gestore delle eccezioni, puoi provare a risolvere il problema. Se non è possibile, richiedi l'assistenza dell'utente.

risposta data 14.09.2015 - 13:08

fonte

Leggi altre domande sui tag c++ pointers assertions

Rappresentazione in virgola mobile -128 + 127 = -1 = 1111 1111 Restituzione di una bandiera che indica il successo [chiuso]

score 9 · Accepted Answer

Il valore dell'asserzione è:

Documenta esplicitamente l'assunzione del programmatore che GetMeAPikachu restituisce non null. Ciò è particolarmente utile se la funzione a un certo punto della cronologia ha cambiato il comportamento o se ci sono circostanze specifiche in cui la funzione può restituire null, ma il programmatore sta affermando che queste circostanze non si applicano qui.
Trasforma la situazione di errore da "c'era un crash, ora vai e trova il motivo" in "questo puntatore era nullo".
È indipendente dai dettagli di implementazione di ThunderBolt . Se quella funzione non è virtuale e non accede alle variabili membro stesso, il crash potrebbe semplicemente non accadere affatto, o essere in profondità nella struttura delle chiamate, e potrebbe non essere una violazione di accesso, ma probabilmente un'istruzione illegale perché alla fine riuscito a saltare attraverso un puntatore / vtable funzione non valida.