Bạn có sử dụng NULL hoặc 0 (không) cho con trỏ trong C ++ không?

Trong những ngày đầu của C ++ khi nó được bắt đầu trên C, bạn không thể sử dụng NULL vì nó được định nghĩa là (void*)0. Bạn không thể gán NULL cho bất kỳ con trỏ nào khác void*, điều này làm cho nó trở nên vô dụng. Quay lại những ngày đó, người ta chấp nhận rằng bạn đã sử dụng 0(không) cho con trỏ null.

Cho đến ngày nay, tôi vẫn tiếp tục sử dụng số 0 làm con trỏ null nhưng những người xung quanh vẫn khăng khăng sử dụng NULL. Cá nhân tôi không thấy bất kỳ lợi ích nào khi đặt tên ( NULL) cho một giá trị hiện có - và vì tôi cũng muốn kiểm tra các con trỏ như các giá trị thật:

if (p && !q)
  do_something();

sau đó sử dụng số 0 có ý nghĩa hơn (như trong trường hợp bạn sử dụng NULL, bạn không thể sử dụng một cách hợp lý p && !q- bạn cần so sánh rõ ràng với nhau NULL, trừ khi bạn cho NULLlà bằng không, trong trường hợp tại sao lại sử dụng NULL).

Có bất kỳ lý do khách quan nào để thích số 0 hơn NULL (hoặc ngược lại), hay tất cả chỉ là sở thích cá nhân?

Chỉnh sửa: Tôi nên thêm (và có nghĩa là ban đầu nói) rằng với RAII và các ngoại lệ, tôi hiếm khi sử dụng các con trỏ zero / NULL, nhưng đôi khi bạn vẫn cần chúng.

Đây là Stroustrup đảm nhận việc này: Câu hỏi thường gặp về Phong cách và Kỹ thuật của C ++

Trong C ++, định nghĩa NULLlà 0, do đó chỉ có sự khác biệt về mặt thẩm mỹ. Tôi thích tránh các macro, vì vậy tôi sử dụng 0. Một vấn đề khác NULLlà mọi người đôi khi nhầm tưởng rằng nó khác 0 và / hoặc không phải là số nguyên. Trong mã chuẩn, NULLđôi khi / được định nghĩa là một cái gì đó không phù hợp và do đó phải / phải tránh. Điều đó ít phổ biến hơn những ngày này.

Nếu bạn phải đặt tên cho con trỏ null, hãy gọi nó nullptr; đó là những gì nó được gọi trong C ++ 11. Sau đó, nullptrsẽ là một từ khóa.

Điều đó nói rằng, đừng đổ mồ hôi những thứ nhỏ nhặt.

Có một vài lập luận (một trong số đó là tương đối gần đây) mà tôi tin rằng mâu thuẫn với quan điểm của Bjarne về vấn đề này.

1. Tài liệu về ý định

Việc sử dụng NULLcho phép tìm kiếm khi sử dụng và nó cũng nhấn mạnh rằng nhà phát triển muốn sử dụng một NULLcon trỏ, bất kể nó có được trình biên dịch giải thích NULLhay không.

2. Quá tải con trỏ và 'int' là tương đối hiếm

Ví dụ mà mọi người trích dẫn là:

void foo(int*);
void foo (int);

void bar() {
  foo (NULL);  // Calls 'foo(int)'
}

Tuy nhiên, ít nhất theo ý kiến ​​của tôi, vấn đề ở trên không phải là chúng ta đang sử dụng NULL cho hằng số con trỏ null, mà là chúng ta có quá tải 'foo', có các loại đối số rất khác nhau. Tham số phải là một intquá, vì bất kỳ loại nào khác sẽ dẫn đến một cuộc gọi mơ hồ và do đó tạo ra một cảnh báo trình biên dịch hữu ích.

3. Công cụ phân tích có thể giúp NGAY HÔM NAY!

Ngay cả khi không có C ++ 0x, ngày nay vẫn có các công cụ xác minh rằng nó NULLđang được sử dụng cho con trỏ và 0đang được sử dụng cho các loại tích phân.

4. C ++ 11 sẽ có một std::nullptr_tloại mới .

Đây là đối số mới nhất cho bảng. Vấn đề của 0và NULLđang được giải quyết tích cực cho C ++ 0x và bạn có thể đảm bảo rằng đối với mọi triển khai cung cấp NULL, điều đầu tiên họ sẽ làm là:

#define NULL  nullptr

Đối với những người sử dụng NULLchứ không phải là 0, sự thay đổi sẽ là một sự cải tiến trong loại an toàn với ít hoặc không có nỗ lực - nếu bất cứ điều gì nó cũng có thể bắt gặp một vài lỗi mà họ đã sử dụng NULLcho 0. Đối với bất cứ ai sử dụng 0ngày hôm nay .... erm ... cũng hy vọng họ có kiến ​​thức tốt về các biểu thức thông thường ...

Sử dụng NULL. NULL cho thấy ý định của bạn. Đó là 0 là một chi tiết thực hiện không quan trọng.

Tôi luôn luôn sử dụng:

• NULL cho con trỏ
• '\0' cho ký tự
• 0.0 cho phao và đôi

trong đó 0 sẽ làm tốt Đó là một vấn đề của ý định báo hiệu. Điều đó nói rằng, tôi không phải là hậu môn về nó.

Tôi đã ngừng sử dụng NULL ủng hộ 0 từ lâu (cũng như hầu hết các macro khác). Tôi đã làm điều này không chỉ vì tôi muốn tránh các macro càng nhiều càng tốt, mà còn bởi vì NULL dường như đã được sử dụng quá mức trong mã C và C ++. Nó dường như được sử dụng bất cứ khi nào cần một giá trị 0, không chỉ cho con trỏ.

Trên các dự án mới, tôi đặt điều này trong một tiêu đề dự án:

static const int nullptr = 0;

Bây giờ, khi trình biên dịch tuân thủ C ++ 0x đến, tất cả những gì tôi phải làm là xóa dòng đó. Một lợi ích tuyệt vời của việc này là Visual Studio đã nhận ra nullptr như một từ khóa và làm nổi bật nó một cách thích hợp.

    cerr << sizeof(0) << endl;
    cerr << sizeof(NULL) << endl;
    cerr << sizeof(void*) << endl;

    ============
    On a 64-bit gcc RHEL platform you get:
    4
    8
    8
    ================

Noi dung chinh cua cau chuyen. Bạn nên sử dụng NULL khi bạn đang xử lý các con trỏ.

1) Nó tuyên bố ý định của bạn (đừng bắt tôi tìm kiếm trong tất cả các mã của bạn đang cố gắng tìm hiểu xem một biến là một con trỏ hoặc một số loại số).

2) Trong các lệnh gọi API nhất định mong đợi các đối số biến, chúng sẽ sử dụng con trỏ NULL để chỉ ra phần cuối của danh sách đối số. Trong trường hợp này, sử dụng '0' thay vì NULL có thể gây ra sự cố. Trên nền tảng 64 bit, cuộc gọi va_arg muốn con trỏ 64 bit, nhưng bạn sẽ chỉ truyền một số nguyên 32 bit. Có vẻ như tôi đang dựa vào 32 bit khác để loại bỏ bạn? Tôi đã thấy một số trình biên dịch nhất định (ví dụ icpc của Intel) không quá duyên dáng - và điều này dẫn đến lỗi thời gian chạy.

Nếu tôi nhớ lại chính xác thì NULL được định nghĩa khác trong các tiêu đề mà tôi đã sử dụng. Đối với C, nó được định nghĩa là (void *) 0 và đối với C ++, nó được định nghĩa là chỉ 0. Mã trông giống như:

#ifndef __cplusplus
#define NULL (void*)0
#else
#define NULL 0
#endif

Cá nhân tôi vẫn sử dụng giá trị NULL để biểu diễn các con trỏ null, điều này cho thấy rõ rằng bạn đang sử dụng một con trỏ thay vì một số loại tích phân. Có, bên trong giá trị NULL vẫn là 0 nhưng nó không được biểu thị như vậy.

Ngoài ra, tôi không dựa vào việc chuyển đổi tự động các số nguyên thành các giá trị boolean nhưng so sánh rõ ràng với chúng.

Ví dụ thích sử dụng:

if (pointer_value != NULL || integer_value == 0)

thay vì:

if (pointer_value || !integer_value)

Đủ để nói rằng đây là tất cả các biện pháp khắc phục trong C ++ 11, nơi người ta có thể chỉ cần sử dụng nullptrthay vì NULL, và nullptr_tđó cũng là loại a nullptr.

Tôi muốn nói rằng lịch sử đã lên tiếng và những người tranh luận ủng hộ việc sử dụng 0 (không) là sai (bao gồm cả Bjarne Stroustrup). Các lý lẽ ủng hộ 0 chủ yếu là tính thẩm mỹ và "sở thích cá nhân".

Sau khi tạo C ++ 11, với loại nullptr mới, một số trình biên dịch đã bắt đầu phàn nàn (với các tham số mặc định) về việc chuyển 0 đến các hàm với các đối số con trỏ, vì 0 không phải là con trỏ.

Nếu mã được viết bằng NULL, một tìm kiếm và thay thế đơn giản có thể được thực hiện thông qua cơ sở mã để biến nó thành nullptr. Nếu bạn bị mắc kẹt với mã được viết bằng cách sử dụng lựa chọn 0 làm con trỏ thì việc cập nhật nó sẽ tẻ nhạt hơn nhiều.

Và nếu bạn phải viết mã mới ngay bây giờ theo tiêu chuẩn C ++ 03 (và không thể sử dụng nullptr), bạn thực sự chỉ nên sử dụng NULL. Nó sẽ giúp bạn dễ dàng cập nhật hơn trong tương lai.

Tôi thường sử dụng 0. Tôi không thích macro và không có gì đảm bảo rằng một số tiêu đề của bên thứ ba mà bạn đang sử dụng không xác định lại NULL là một cái gì đó kỳ lạ.

Bạn có thể sử dụng một đối tượng nullptr theo đề xuất của Scott Meyers và những người khác cho đến khi C ++ nhận được từ khóa nullptr:

const // It is a const object...
class nullptr_t 
{
public:
    template<class T>
    operator T*() const // convertible to any type of null non-member pointer...
    { return 0; }

    template<class C, class T>
    operator T C::*() const   // or any type of null member pointer...
    { return 0; }

private:
    void operator&() const;  // Can't take address of nullptr

} nullptr = {};

Google "nullptr" để biết thêm.

Tôi đã từng làm việc trên một máy trong đó 0 là một địa chỉ hợp lệ và NULL được xác định là một giá trị bát phân đặc biệt. Trên máy đó (0! = NULL), vì vậy mã như

char *p;

...

if (p) { ... }

sẽ không làm việc như bạn mong đợi. Bạn phải viết

if (p != NULL) { ... }

Mặc dù tôi tin rằng hầu hết các trình biên dịch định nghĩa NULL là 0 ngày nay nhưng tôi vẫn nhớ bài học từ những năm trước: NULL không nhất thiết phải là 0.

Tôi nghĩ rằng tiêu chuẩn đảm bảo rằng NULL == 0, vì vậy bạn có thể làm một trong hai. Tôi thích NULL vì nó ghi lại ý định của bạn.

Sử dụng 0 hoặc NULL sẽ có tác dụng tương tự.

Tuy nhiên, điều đó không có nghĩa là cả hai đều thực hành lập trình tốt. Cho rằng không có sự khác biệt về hiệu suất, việc chọn một tùy chọn nhận biết ở mức độ thấp so với lựa chọn bất khả tri / trừu tượng là một thực tiễn lập trình tồi. Giúp người đọc mã của bạn hiểu quá trình suy nghĩ của bạn .

NULL, 0, 0.0, '\ 0', 0x00 và tất cả đều dịch sang cùng một thứ, nhưng là các thực thể logic khác nhau trong chương trình của bạn. Chúng nên được sử dụng như vậy. NULL là một con trỏ, 0 là số lượng, 0x0 là một giá trị có bit thú vị, v.v. Bạn sẽ không gán '\ 0' cho một con trỏ cho dù nó có biên dịch hay không.

Tôi biết một số cộng đồng khuyến khích thể hiện kiến ​​thức chuyên sâu về môi trường bằng cách phá vỡ hợp đồng của môi trường. Các lập trình viên có trách nhiệm, tuy nhiên, tạo mã có thể duy trì và giữ các thực hành đó ra khỏi mã của họ.

Lạ thay, không ai, kể cả Stroustroup đã đề cập đến điều đó. Trong khi nói chuyện rất nhiều về các tiêu chuẩn và thẩm mỹ không ai nhận thấy rằng nó là nguy hiểm để sử dụng 0trong NULL's Thay vào đó, ví dụ, trong danh sách đối số biến trên kiến trúc nơi sizeof(int) != sizeof(void*). Giống như Stroustroup, tôi thích 0vì lý do thẩm mỹ, nhưng người ta phải cẩn thận không sử dụng nó khi loại của nó có thể mơ hồ.

Tôi cố gắng tránh toàn bộ câu hỏi bằng cách sử dụng tài liệu tham khảo C ++ nếu có thể. Thay vì

void foo(const Bar* pBar) { ... }

bạn thường có thể viết

void foo(const Bar& bar) { ... }

Tất nhiên, điều này không phải lúc nào cũng hoạt động; nhưng con trỏ null có thể được sử dụng quá mức.

Tôi với Stroustrup về điều này :-) Vì NULL không phải là một phần của ngôn ngữ, tôi thích sử dụng 0.

Chủ yếu là sở thích cá nhân, mặc dù người ta có thể đưa ra lập luận rằng NULL làm cho khá rõ ràng rằng đối tượng là một con trỏ hiện không trỏ đến bất cứ thứ gì, ví dụ:

void *ptr = &something;
/* lots o' code */
ptr = NULL; // more obvious that it's a pointer and not being used

IIRC, tiêu chuẩn không yêu cầu NULL là 0, vì vậy sử dụng bất cứ điều gì được xác định trong <stddef.h> có lẽ là tốt nhất cho trình biên dịch của bạn.

Một khía cạnh khác của tranh luận là liệu bạn có nên sử dụng các so sánh logic (truyền ẩn cho bool) hay kiểm tra mức độ khám phá đối với NULL, nhưng điều đó cũng dễ đọc.

Tôi thích sử dụng NULL vì nó làm rõ rằng ý định của bạn là giá trị đại diện cho một con trỏ không phải là một giá trị số học. Thực tế rằng đó là một vĩ mô là không may, nhưng vì nó đã ăn sâu vào nó nên có rất ít nguy hiểm (trừ khi ai đó làm điều gì đó thực sự đau đầu). Tôi ước nó là một từ khóa ngay từ đầu, nhưng bạn có thể làm gì?

Điều đó nói rằng, tôi không có vấn đề gì với việc sử dụng con trỏ làm giá trị thật trong chính chúng. Cũng như với NULL, đó là một thành ngữ ăn sâu.

C ++ 09 sẽ thêm cấu trúc nullptr mà tôi nghĩ là đã quá hạn lâu.

Tôi luôn luôn sử dụng 0. Không phải vì bất kỳ lý do suy nghĩ thực tế nào, chỉ vì khi tôi mới học C ++, tôi đã đọc một cái gì đó được khuyến nghị sử dụng 0 và tôi luôn luôn làm theo cách đó. Về lý thuyết có thể có một vấn đề nhầm lẫn về khả năng đọc nhưng trong thực tế tôi chưa bao giờ gặp phải một vấn đề như vậy trong hàng ngàn giờ và hàng triệu dòng mã. Như Stroustrup nói, đó thực sự chỉ là vấn đề thẩm mỹ cá nhân cho đến khi tiêu chuẩn trở thành nullptr.

Ai đó đã nói với tôi một lần ... Tôi sẽ định nghĩa lại NULL thành 69. Kể từ đó tôi không sử dụng nó: P

Nó làm cho mã của bạn khá dễ bị tổn thương.

Biên tập:

Không phải tất cả mọi thứ trong tiêu chuẩn là hoàn hảo. Macro NULL là hằng số con trỏ null C ++ được xác định thực hiện không tương thích hoàn toàn với macro C NULL, ngoài kiểu ẩn ẩn chuyển đổi nó trong một công cụ vô dụng và dễ bị lỗi.

NULL không hoạt động như một con trỏ null mà là một chữ O / OL.

Cho tôi biết ví dụ tiếp theo không khó hiểu:

void foo(char *); 
void foo(int); 
foo(NULL); // calls int version instead of pointer version! 

Là vì ​​tất cả những điều đó, trong tiêu chuẩn mới xuất hiện std :: nullptr_t

Nếu bạn không muốn chờ đợi tiêu chuẩn mới và muốn sử dụng nullptr, hãy sử dụng ít nhất một tiêu chuẩn đàng hoàng như đề xuất của Meyers (xem bình luận jon.h).

Vâng, tôi lập luận rằng không sử dụng con trỏ 0 hoặc NULL bất cứ khi nào có thể.

Sử dụng chúng sớm hay muộn sẽ dẫn đến lỗi phân đoạn trong mã của bạn. Theo kinh nghiệm của tôi, và con trỏ trong gereral là một trong những lỗi lớn nhất trong C ++

đồng thời, nó dẫn đến các câu lệnh "if-not-null" trên toàn bộ mã của bạn. Đẹp hơn nhiều nếu bạn có thể dựa vào luôn luôn một trạng thái hợp lệ.

Hầu như luôn luôn có một sự thay thế tốt hơn.

Đặt con trỏ về 0 chỉ là không rõ ràng. Đặc biệt nếu bạn đến một ngôn ngữ khác ngoài C ++. Điều này bao gồm C cũng như Javascript.

Gần đây tôi đã delt với một số mã như vậy:

virtual void DrawTo(BITMAP *buffer) =0;

cho chức năng ảo thuần túy lần đầu tiên. Tôi nghĩ rằng đó là một số jiberjash ma thuật trong một tuần. Khi tôi nhận ra, về cơ bản, nó chỉ thiết lập con trỏ hàm thành một null(vì các hàm ảo chỉ là các con trỏ hàm trong hầu hết các trường hợp cho C ++), tôi tự đá mình.

virtual void DrawTo(BITMAP *buffer) =null;

sẽ ít gây nhầm lẫn hơn so với cơ sở đó mà không có khoảng cách thích hợp với đôi mắt mới của tôi. Trên thực tế, tôi tự hỏi tại sao C ++ không sử dụng chữ thường nullgiống như nó sử dụng chữ thường và sai.