Чому покажчики за замовчуванням не ініціалізуються з NULL?

Чи може хтось пояснити, чому покажчики не ініціалізуються NULL?
Приклад:

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

Програма не входитиме всередину if, тому що bufце не нуль.

Мені хотілося б знати, чому в будь-якому випадку нам потрібна змінна із кошиком, спеціально вказівники, що адресують кошик на пам'яті?

Усі ми розуміємо, що вказівник (та інші типи POD) слід ініціалізувати.
Тоді стає питання "хто повинен їх ініціалізувати".

Ну є в основному два методи:

• Компілятор ініціалізує їх.
• Розробник ініціалізує їх.

Припустимо, що компілятор ініціалізував будь-яку змінну, явно не ініціалізовану розробником. Тоді ми стикаємося з ситуаціями, коли ініціалізація змінної була нетривіальною, і причиною, яку розробник не робив цього в деклараційному пункті, було те, що йому / їй потрібно виконати якусь операцію, а потім призначити.

Отже, у нас виникла ситуація, що компілятор додав до коду додаткову інструкцію, яка ініціалізує змінну до NULL, потім пізніше додається код розробника, щоб зробити правильну ініціалізацію. Або за інших умов змінна потенційно ніколи не використовується. Багато розробників на C ++ прикриваються при обох умовах ціною додаткової інструкції.

Справа не лише в часі. Але і простір. Є багато середовищ, де обидва ресурси переважають, і розробники не хочуть відмовлятися і від них.

АЛЕ : Ви можете імітувати ефект примусової ініціалізації. Більшість компіляторів попередить вас про неініціалізовані змінні. Тому я завжди перетворюю свій попереджувальний рівень на найвищий можливий рівень. Потім скажіть компілятору, щоб всі попередження розглядалися як помилки. За цих умов більшість компіляторів буде генерувати помилку для змінних, які не ініціалізуються, але використовуються, і, таким чином, не дозволять створювати код.

Цитуючи Bjarne Stroustrup в TC ++ PL (Special Edition p.22):

Реалізація функції не повинна накладати значні накладні витрати на програми, які цього не потребують.

Тому що для ініціалізації потрібен час. І в C ++, перше, що ви повинні зробити з будь-якою змінною, - це явно ініціалізувати її:

int * p = & some_int;

або:

int * p = 0;

або:

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

Тому що одним із девізів C ++ є:

Ви не платите за те, що не використовуєте

Саме з цієї причини operator[] в vectorкласі не перевіряє , якщо індекс виходить за межі, наприклад.

З історичних причин, головним чином, тому, що це робиться в C. Чому це робиться так у C, це інше питання, але я думаю, що принцип нульових накладних витрат якимось чином був задіяний у цьому проектному рішенні.

Крім того, у нас є попередження про те, коли ви натискаєте його: "можливо, використовується до присвоєння значення" або подібного вербежу залежно від вашого компілятора.

Ви компілюєте з попередженнями, правда?

Є надзвичайно мало ситуацій, коли коли-небудь має сенс змінна бути неініціалізованою, а ініціалізація за замовчуванням має невелику вартість, то чому це робити?

C ++ не є C89. Чорт, навіть C не C89. Ви можете змішувати декларації та код, тому вам слід відкладати декларацію до тих пір, поки у вас є відповідне значення для ініціалізації.

Вказівник - це просто іншого типу. Якщо ви створюєте int, charабо будь-який інший тип POD, він не ініціалізується на нуль, то навіщо вказувати? Це може вважатися непотрібним накладним для того, хто пише подібну програму.

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

Якщо ви знаєте, що збираєтеся його ініціалізувати, то чому програма повинна нести витрати, коли ви вперше створюєте pBufу верхній частині методу? Це принцип нульових накладних витрат.

Якщо ви хочете, щоб вказівник, який завжди ініціалізується на NULL, ви можете використовувати шаблон C ++, щоб імітувати цю функціональність:

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); }
};

Зауважте, що статичні дані ініціалізуються до 0 (якщо не сказано інше).

І так, ви завжди повинні оголошувати свої змінні якомога пізніше та з початковим значенням. Код, як

int j;
char *foo;

повинні відключити дзвінки тривоги, коли ви її читаєте. Я не знаю, чи можна вмовити якісь волоски, аби вони розібрались, хоча це 100% легально.

Інша можлива причина того, що вказівники часу зв’язку надаються адресою, але непряма адресація / дереференція вказівника - це відповідальність програміста. Досить звичайно, компілятор не менше піклується, але тягар перекладається на програміста, щоб керувати покажчиками та переконатися, що не відбувається витоку пам'яті.

Дійсно, у двох словах, вони ініціалізуються в тому сенсі, що під час посилання змінній вказівника надається адреса. У наведеному вище прикладі коду гарантовано збій або генерування SIGSEGV.

Заради розумності завжди ініціалізуйте покажчики на NULL таким чином, якщо будь-яка спроба скинути її з ладу без mallocабо new призведе до втягнення програміста в причину неправильної поведінки програми.

Сподіваюся, це допомагає та має сенс,

Ну, якби C ++ ініціалізував покажчики, тоді люди, які скаржаться на те, що "C ++ повільніше, ніж C", було б щось справжнє;)

C ++ походить із середовища C - і з цієї причини повертається кілька причин:

C, навіть більше, ніж C ++ - це заміна мови складання. Це не робить нічого, чого ти не скажеш. З цього приводу: Якщо ви хочете НУЛЮВАТИ це - зробіть це!

Крім того, якщо ви зведете нанівець речі на голому металі, як-от C, автоматично виникають запитання про несумісність: Якщо ви щось зраджуєте - чи автоматично це буде занулено? Як щодо структури, створеної на стеці? чи всі байти повинні бути нульовими? Що з глобальними змінними? як щодо твердження типу "(* 0x18);" це не означає, що позиція пам'яті 0x18 повинна бути нульовою?

Про які ці вказівки ви говорите?

Для забезпечення безпеки винятків, завжди використовуйте auto_ptr, shared_ptr, weak_ptrта інші їх варіанти.
Ознакою хорошого коду є той, який не включає в себе жодного дзвінка delete.

О, малюк. Справжня відповідь полягає в тому, що пам’ять легко звести нанівець, що є базовою ініціалізацією для скажімо вказівника. Що також не має нічого спільного з ініціалізацією самого об’єкта.

З огляду на попередження, які дають більшість компіляторів на найвищих рівнях, я не можу уявити програмування на найвищому рівні і трактувати їх як помилки. Оскільки їх підняття ніколи не врятувало мене навіть однієї помилки у величезній кількості виробленого коду, я не можу цього рекомендувати.