Perché i puntatori non vengono inizializzati con NULL per impostazione predefinita?

Qualcuno può spiegare perché i puntatori non vengono inizializzati NULL?
Esempio:

  void test(){
     char *buf;
     if (!buf)
        // whatever
  }

Il programma non entrerebbe nel if perché bufnon è nullo.

Vorrei sapere perché, in quale caso abbiamo bisogno di una variabile con trash attivato, in particolare dei puntatori che indirizzano il cestino in memoria?

Sappiamo tutti che il puntatore (e altri tipi di POD) dovrebbe essere inizializzato.
La domanda diventa quindi "chi dovrebbe inizializzarli".

Bene, ci sono fondamentalmente due metodi:

• Il compilatore li inizializza.
• Lo sviluppatore li inizializza.

Supponiamo che il compilatore abbia inizializzato qualsiasi variabile non esplicitamente inizializzata dallo sviluppatore. Quindi ci imbattiamo in situazioni in cui l'inizializzazione della variabile non era banale e il motivo per cui lo sviluppatore non lo ha fatto al punto della dichiarazione era che doveva eseguire alcune operazioni e quindi assegnare.

Quindi ora abbiamo la situazione in cui il compilatore ha aggiunto un'istruzione extra al codice che inizializza la variabile a NULL, quindi in seguito viene aggiunto il codice dello sviluppatore per eseguire l'inizializzazione corretta. Oppure in altre condizioni la variabile potenzialmente non viene mai utilizzata. Molti sviluppatori C ++ griderebbero fallo in entrambe le condizioni al costo di quell'istruzione extra.

Non è solo questione di tempo. Ma anche spazio. Ci sono molti ambienti in cui entrambe le risorse sono preziose e nemmeno gli sviluppatori vogliono arrendersi.

MA : è possibile simulare l'effetto di forzare l'inizializzazione. La maggior parte dei compilatori ti avviserà delle variabili non inizializzate. Quindi imposto sempre il mio livello di avviso al massimo livello possibile. Quindi dite al compilatore di trattare tutti gli avvisi come errori. In queste condizioni, la maggior parte dei compilatori genererà quindi un errore per le variabili non inizializzate ma utilizzate e quindi impedirà la generazione del codice.

Citando Bjarne Stroustrup in TC ++ PL (Special Edition p.22):

L'implementazione di una funzionalità non dovrebbe imporre costi generali significativi ai programmi che non la richiedono.

Perché l'inizializzazione richiede tempo. E in C ++, la prima cosa che dovresti fare con qualsiasi variabile è inizializzarla esplicitamente:

int * p = & some_int;

o:

int * p = 0;

o:

class A {
   public:
     A() : p( 0 ) {}  // initialise via constructor
   private:
     int * p;
};

Perché uno dei motti di C ++ è:

Non paghi per quello che non usi

Proprio per questo motivo, il operator[]della vectorclasse non controlla se l'indice è fuori limite, ad esempio.

Per ragioni storiche, principalmente perché è così che è fatto in C. Perché è fatto così in C, è un'altra questione, ma penso che il principio zero overhead sia stato coinvolto in qualche modo in questa decisione progettuale.

Inoltre, abbiamo un avvertimento per quando lo fai saltare: "è possibilmente usato prima di assegnare un valore" o parole simili a seconda del tuo compilatore.

Compili con avvisi, giusto?

Ci sono praticamente poche situazioni in cui ha senso che una variabile non venga inizializzata e l'inizializzazione predefinita ha un piccolo costo, quindi perché farlo?

C ++ non è C89. Diavolo, anche C non è C89. È possibile combinare dichiarazioni e codice, quindi è necessario rimandare la dichiarazione fino a quando non si dispone di un valore adatto con cui inizializzare.

Un puntatore è solo un altro tipo. Se si crea un int, charo digita qualsiasi altro POD non è inizializzato a zero, quindi perché dovrebbe un puntatore? Questo potrebbe essere considerato un sovraccarico non necessario per qualcuno che scrive un programma come questo.

char* pBuf;
if (condition)
{
    pBuf = new char[50];
}
else
{
    pBuf = m_myMember->buf();
}

Se sai che stai per inizializzarlo, perché il programma dovrebbe sostenere un costo quando crei pBufper la prima volta all'inizio del metodo? Questo è il principio zero overhead.

Se vuoi un puntatore che sia sempre inizializzato su NULL, puoi usare un modello C ++ per emulare quella funzionalità:

template<typename T> class InitializedPointer
{
public:
    typedef T       TObj;
    typedef TObj    *PObj;
protected:
    PObj        m_pPointer;

public:
    // Constructors / Destructor
    inline InitializedPointer() { m_pPointer=0; }
    inline InitializedPointer(PObj InPointer) { m_pPointer = InPointer; }
    inline InitializedPointer(const InitializedPointer& oCopy)
    { m_pPointer = oCopy.m_pPointer; }
    inline ~InitializedPointer() { m_pPointer=0; }

    inline PObj GetPointer() const  { return (m_pPointer); }
    inline void SetPointer(PObj InPtr)  { m_pPointer = InPtr; }

    // Operator Overloads
    inline InitializedPointer& operator = (PObj InPtr)
    { SetPointer(InPtr); return(*this); }
    inline InitializedPointer& operator = (const InitializedPointer& InPtr)
    { SetPointer(InPtr.m_pPointer); return(*this); }
    inline PObj operator ->() const { return (m_pPointer); }
    inline TObj &operator *() const { return (*m_pPointer); }

    inline bool operator!=(PObj pOther) const
    { return(m_pPointer!=pOther); }
    inline bool operator==(PObj pOther) const
    { return(m_pPointer==pOther); }
    inline bool operator!=(const InitializedPointer& InPtr) const
    { return(m_pPointer!=InPtr.m_pPointer); }
    inline bool operator==(const InitializedPointer& InPtr) const
    { return(m_pPointer==InPtr.m_pPointer); }

    inline bool operator<=(PObj pOther) const
    { return(m_pPointer<=pOther); }
    inline bool operator>=(PObj pOther) const
    { return(m_pPointer>=pOther); }
    inline bool operator<=(const InitializedPointer& InPtr) const
    { return(m_pPointer<=InPtr.m_pPointer); }
    inline bool operator>=(const InitializedPointer& InPtr) const
    { return(m_pPointer>=InPtr.m_pPointer); }

    inline bool operator<(PObj pOther) const
    { return(m_pPointer<pOther); }
    inline bool operator>(PObj pOther) const
    { return(m_pPointer>pOther); }
    inline bool operator<(const InitializedPointer& InPtr) const
    { return(m_pPointer<InPtr.m_pPointer); }
    inline bool operator>(const InitializedPointer& InPtr) const
    { return(m_pPointer>InPtr.m_pPointer); }
};

Nota che i dati statici sono inizializzati a 0 (a meno che tu non dica diversamente).

E sì, dovresti sempre dichiarare le tue variabili il più tardi possibile e con un valore iniziale. Codice come

int j;
char *foo;

dovrebbe far scattare un campanello d'allarme quando lo leggi. Non so se qualche lanugine può essere persuasa a lamentarsene, dato che è legale al 100%.

Un altro possibile motivo è che in fase di collegamento ai puntatori viene assegnato un indirizzo, ma l'indirizzamento / de-referenziamento indiretto di un puntatore è responsabilità del programmatore. Di solito, al compilatore non interessa di meno, ma il compito di gestire i puntatori e di assicurarsi che non si verifichino perdite di memoria viene trasferito al programmatore.

In realtà, in poche parole, sono inizializzati nel senso che al momento del collegamento alla variabile pointer viene assegnato un indirizzo. Nel codice di esempio sopra, è garantito che si arresti in modo anomalo o generi un SIGSEGV.

Per motivi di sanità mentale, inizializza sempre i puntatori a NULL, in questo modo se qualsiasi tentativo di dereferenziarlo senza malloco newindurrà il programmatore nel motivo per cui il programma si è comportato male.

Spero che questo aiuti e abbia un senso,

Bene, se C ++ inizializzasse i puntatori, allora la gente di C che si lamenta "C ++ è più lento di C" avrebbe qualcosa di reale a cui aggrapparsi;)

Il C ++ proviene da uno sfondo C e ci sono alcuni motivi che tornano da questo:

C, anche più di C ++ è una sostituzione del linguaggio assembly. Non fa nulla che tu non gli dica di fare. Perciò: se vuoi NULLO, fallo!

Inoltre, se annulli le cose in un linguaggio bare-metal come il C, sorgono automaticamente domande sulla coerenza: se malloc qualcosa, dovrebbe essere azzerato automaticamente? Che ne dici di una struttura creata sullo stack? tutti i byte dovrebbero essere azzerati? E le variabili globali? che dire di una dichiarazione come "(* 0x18);" non significa allora che la posizione di memoria 0x18 dovrebbe essere azzerata?

Quali sono questi suggerimenti di cui parli?

Per la sicurezza rispetto alle eccezioni, utilizzare sempre auto_ptr, shared_ptr, weak_ptre le loro altre varianti.
Un segno distintivo di un buon codice è quello che non include una singola chiamata a delete.

Oh ragazzo. La vera risposta è che è facile azzerare la memoria, che è un'inizializzazione di base per esempio un puntatore. Il che non ha nulla a che fare con l'inizializzazione dell'oggetto stesso.

Considerando gli avvertimenti che la maggior parte dei compilatori fornisce ai livelli più alti, non riesco a immaginare di programmare al livello più alto e di trattarli come errori. Dato che alzarli non mi ha mai salvato nemmeno un bug in enormi quantità di codice prodotto, non posso raccomandarlo.