Tại sao con trỏ không được khởi tạo bằng NULL theo mặc định?

Ai đó có thể vui lòng giải thích tại sao con trỏ không được khởi tạo thành NULLkhông?
Thí dụ:

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

Chương trình sẽ không bước vào bên trong if bởi vì bufkhông phải là null.

Tôi muốn biết tại sao, trong trường hợp nào chúng ta cần một biến có bật thùng rác, con trỏ đặc biệt định địa chỉ thùng rác trên bộ nhớ?

Tất cả chúng ta đều nhận thấy rằng con trỏ (và các loại POD khác) nên được khởi tạo.
Câu hỏi sau đó trở thành 'ai nên khởi tạo chúng'.

Về cơ bản có hai phương pháp:

• Trình biên dịch khởi tạo chúng.
• Nhà phát triển khởi tạo chúng.

Hãy giả sử rằng trình biên dịch khởi tạo bất kỳ biến nào không được nhà phát triển khởi tạo một cách rõ ràng. Sau đó, chúng tôi gặp phải các tình huống trong đó việc khởi tạo biến là không bình thường và lý do nhà phát triển không thực hiện điều đó tại điểm khai báo là họ cần thực hiện một số thao tác và sau đó gán.

Vì vậy, bây giờ chúng ta có tình huống rằng trình biên dịch đã thêm một lệnh bổ sung vào mã khởi tạo biến thành NULL, sau đó mã nhà phát triển được thêm vào để thực hiện việc khởi tạo chính xác. Hoặc trong các điều kiện khác, biến có thể không bao giờ được sử dụng. Rất nhiều nhà phát triển C ++ sẽ hét lên lỗi trong cả hai điều kiện với chi phí của hướng dẫn bổ sung đó.

Nó không chỉ là về thời gian. Nhưng cả không gian. Có rất nhiều môi trường mà cả hai tài nguyên đều ở mức cao và các nhà phát triển cũng không muốn từ bỏ.

NHƯNG : Bạn có thể mô phỏng tác động của việc buộc khởi tạo. Hầu hết các trình biên dịch sẽ cảnh báo bạn về các biến chưa được khởi tạo. Vì vậy tôi luôn chuyển mức cảnh báo của mình lên mức cao nhất có thể. Sau đó, yêu cầu trình biên dịch coi tất cả các cảnh báo là lỗi. Trong các điều kiện này, hầu hết các trình biên dịch sau đó sẽ tạo ra lỗi cho các biến chưa được khởi tạo nhưng được sử dụng và do đó sẽ ngăn không cho mã được tạo.

Trích dẫn Bjarne Stroustrup trong TC ++ PL (Phiên bản đặc biệt tr.22):

Việc triển khai tính năng không được áp đặt chi phí đáng kể cho các chương trình không yêu cầu tính năng đó.

Vì quá trình khởi tạo cần có thời gian. Và trong C ++, điều đầu tiên bạn nên làm với bất kỳ biến nào là khởi tạo nó một cách rõ ràng:

int * p = & some_int;

hoặc là:

int * p = 0;

hoặc là:

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

Bởi vì một trong những phương châm của C ++ là:

Bạn không trả tiền cho những gì bạn không sử dụng

Vì lý do này rất, sự operator[]của vectorlớp không kiểm tra xem chỉ số này nằm ngoài giới hạn, ví dụ.

Vì lý do lịch sử, chủ yếu là vì đây là cách nó được thực hiện trong C. Tại sao nó được thực hiện như vậy trong C, là một câu hỏi khác, nhưng tôi nghĩ rằng nguyên tắc chi phí bằng không đã liên quan bằng cách nào đó trong quyết định thiết kế này.

Bên cạnh đó, chúng tôi có một cảnh báo khi bạn thổi nó: "có thể được sử dụng trước khi được gán một giá trị" hoặc rác tương tự tùy thuộc vào trình biên dịch của bạn.

Bạn biên dịch với các cảnh báo, phải không?

Có rất ít tình huống mà trong đó một biến chưa được khởi tạo sẽ có ý nghĩa và việc khởi tạo mặc định có chi phí nhỏ, vậy tại sao lại làm như vậy?

C ++ không phải là C89. Chết tiệt, ngay cả C cũng không phải là C89. Bạn có thể kết hợp khai báo và mã, vì vậy bạn nên trì hoãn khai báo cho đến khi bạn có giá trị phù hợp để khởi tạo.

Một con trỏ chỉ là một loại khác. Nếu bạn tạo int, charhoặc bất kỳ loại POD nào khác, nó không được khởi tạo bằng 0, vậy tại sao con trỏ lại phải? Điều này có thể được coi là chi phí không cần thiết đối với một người viết một chương trình như thế này.

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

Nếu bạn biết bạn sẽ khởi tạo nó, tại sao chương trình phải chịu chi phí khi bạn tạo lần đầu pBufở đầu phương thức? Đây là nguyên tắc chi phí không.

Nếu bạn muốn một con trỏ luôn được khởi tạo thành NULL, bạn có thể sử dụng mẫu C ++ để mô phỏng chức năng đó:

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

Lưu ý rằng dữ liệu tĩnh được khởi tạo bằng 0 (trừ khi bạn nói khác).

Và có, bạn nên luôn khai báo các biến của mình càng muộn càng tốt và với giá trị ban đầu. Mã như

int j;
char *foo;

nên đặt chuông báo thức khi bạn đọc nó. Tôi không biết liệu có bất kỳ lint nào có thể thuyết phục được cá chép về điều đó không vì nó hợp pháp 100%.

Một lý do có thể khác tại sao, là tại thời gian liên kết các con trỏ được cấp một địa chỉ, nhưng việc định địa chỉ / hủy tham chiếu gián tiếp một con trỏ là trách nhiệm của lập trình viên. Thông thường, trình biên dịch không quan tâm ít hơn, nhưng gánh nặng được chuyển cho lập trình viên để quản lý các con trỏ và đảm bảo rằng không xảy ra rò rỉ bộ nhớ.

Thực sự, tóm lại, chúng được khởi tạo theo nghĩa là tại thời điểm liên kết, biến con trỏ được cấp một địa chỉ. Trong mã ví dụ của bạn ở trên, điều đó được đảm bảo sẽ xảy ra sự cố hoặc tạo ra một SIGSEGV.

Vì lợi ích của sự tỉnh táo, hãy luôn khởi tạo con trỏ tới NULL, theo cách đó nếu có bất kỳ nỗ lực nào để tham khảo nó mà không có mallochoặc newsẽ gợi ý cho lập trình viên lý do tại sao chương trình hoạt động sai.

Hy vọng điều này sẽ hữu ích và có ý nghĩa,

Chà, nếu C ++ đã khởi tạo con trỏ, thì những người C phàn nàn "C ++ chậm hơn C" sẽ có điều gì đó thực sự đáng lo ngại;)

C ++ xuất phát từ nền tảng C - và có một số lý do trở lại từ điều này:

C, thậm chí nhiều hơn C ++ là một ngôn ngữ thay thế hợp ngữ. Nó không làm bất cứ điều gì bạn không yêu cầu nó làm. Vì vậy: Nếu bạn muốn NULL - hãy làm điều đó!

Ngoài ra, nếu bạn vô hiệu hóa mọi thứ bằng một ngôn ngữ bình thường như C, các câu hỏi về tính nhất quán sẽ tự động xuất hiện: Nếu bạn làm sai điều gì đó - nó có nên tự động được điền không? Điều gì về một cấu trúc được tạo trên ngăn xếp? tất cả các byte có nên được làm bằng không? Còn các biến toàn cục thì sao? còn câu lệnh như "(* 0x18);" điều đó không có nghĩa là vị trí bộ nhớ 0x18 nên được làm bằng không?

Những gợi ý bạn nói đến là gì?

Để an toàn ngoại lệ, luôn luôn sử dụng auto_ptr, shared_ptr, weak_ptrvà các biến thể khác của họ.
Dấu hiệu của mã tốt là mã không bao gồm một lệnh gọi đến delete.

Oh Boy. Câu trả lời thực sự là rất dễ dàng để xóa bộ nhớ, đây là cách khởi tạo cơ bản cho một con trỏ. Điều này cũng không liên quan gì đến việc khởi tạo chính đối tượng.

Xem xét các cảnh báo mà hầu hết các trình biên dịch đưa ra ở mức cao nhất, tôi không thể tưởng tượng được việc lập trình ở mức cao nhất và coi chúng là lỗi. Vì việc bật chúng lên chưa bao giờ giúp tôi tiết kiệm dù chỉ một lỗi trong số lượng lớn mã được tạo ra, tôi không thể khuyến nghị điều này.