Có phải thực hành tốt để NULL một con trỏ sau khi xóa nó?

Tôi sẽ bắt đầu bằng cách nói, sử dụng con trỏ thông minh và bạn sẽ không bao giờ phải lo lắng về điều này.

Các vấn đề với mã sau đây là gì?

Foo * p = new Foo;
// (use p)
delete p;
p = NULL;

Điều này đã gây ra bởi một câu trả lời và bình luận cho một câu hỏi khác. Một bình luận từ Neil Butterworth đã tạo ra một số upvote:

Đặt con trỏ thành NULL sau khi xóa không phải là thông lệ tốt trong C ++. Có những lúc nó là một điều tốt để làm, và có những lúc nó là vô nghĩa và có thể che giấu lỗi.

Có rất nhiều trường hợp nó sẽ không giúp đỡ. Nhưng theo kinh nghiệm của tôi, nó không thể làm tổn thương. Ai đó soi sáng cho tôi.

Đặt con trỏ thành 0 (là "null" trong C ++ tiêu chuẩn, NULL xác định từ C có phần khác nhau) để tránh sự cố khi xóa hai lần.

Hãy xem xét những điều sau đây:

Foo* foo = 0; // Sets the pointer to 0 (C++ NULL)
delete foo; // Won't do anything

Trong khi:

Foo* foo = new Foo();
delete foo; // Deletes the object
delete foo; // Undefined behavior 

Nói cách khác, nếu bạn không đặt con trỏ bị xóa thành 0, bạn sẽ gặp rắc rối nếu bạn thực hiện xóa hai lần. Một đối số chống lại việc thiết lập các con trỏ thành 0 sau khi xóa sẽ là làm như vậy chỉ cần che dấu hai lần xóa các lỗi và bỏ qua chúng.

Rõ ràng tốt nhất là không có lỗi xóa hai lần, nhưng tùy thuộc vào ngữ nghĩa sở hữu và vòng đời đối tượng, điều này có thể khó đạt được trong thực tế. Tôi thích một lỗi xóa mặt nạ kép hơn UB.

Cuối cùng, một sidenote liên quan đến việc quản lý phân bổ đối tượng, tôi khuyên bạn nên xem xét std::unique_ptrquyền sở hữu nghiêm ngặt / số ít, std::shared_ptrcho quyền sở hữu chung hoặc thực hiện con trỏ thông minh khác, tùy thuộc vào nhu cầu của bạn.

Đặt con trỏ thành NULL sau khi bạn đã xóa những gì nó chỉ ra chắc chắn không thể làm tổn thương, nhưng nó thường là một phần trợ giúp ban nhạc cho một vấn đề cơ bản hơn: Tại sao bạn lại sử dụng một con trỏ ở vị trí đầu tiên? Tôi có thể thấy hai lý do điển hình:

• Bạn chỉ đơn giản muốn một cái gì đó được phân bổ trên đống. Trong trường hợp bọc nó trong một đối tượng RAII sẽ an toàn và sạch sẽ hơn nhiều. Kết thúc phạm vi của đối tượng RAII khi bạn không còn cần đối tượng nữa. Đó là cách std::vectorhoạt động, và nó giải quyết vấn đề vô tình để lại con trỏ để giải phóng bộ nhớ xung quanh. Không có con trỏ.
• Hoặc có lẽ bạn muốn một số ngữ nghĩa sở hữu chia sẻ phức tạp. Con trỏ được trả về newcó thể không giống với con trỏ deleteđược gọi trên. Trong khi đó, nhiều đối tượng có thể đã sử dụng đối tượng. Trong trường hợp đó, một con trỏ dùng chung hoặc một cái gì đó tương tự sẽ được ưu tiên hơn.

Nguyên tắc nhỏ của tôi là nếu bạn để lại các con trỏ xung quanh trong mã người dùng, bạn đang làm sai. Con trỏ không nên ở đó để chỉ vào rác ở nơi đầu tiên. Tại sao không có một đối tượng chịu trách nhiệm đảm bảo tính hợp lệ của nó? Tại sao phạm vi của nó không kết thúc khi đối tượng trỏ tới?

Tôi đã có một thực tiễn tốt hơn nữa: Nếu có thể, hãy kết thúc phạm vi của biến!

{
    Foo* pFoo = new Foo;
    // use pFoo
    delete pFoo;
}

Tôi luôn đặt một con trỏ tới NULL(ngay bây giờ nullptr) sau khi xóa (các) đối tượng mà nó trỏ tới.

1. Nó có thể giúp bắt được nhiều tài liệu tham khảo đến bộ nhớ đã giải phóng (giả sử nền tảng của bạn bị lỗi trên một con trỏ rỗng).

2. Nó sẽ không bắt được tất cả các tham chiếu đến bộ nhớ miễn phí nếu, ví dụ, bạn có các bản sao của con trỏ nằm xung quanh. Nhưng một số tốt hơn không có.

3. Nó sẽ che dấu xóa hai lần, nhưng tôi thấy những thứ đó ít phổ biến hơn nhiều so với truy cập vào bộ nhớ đã được giải phóng.

4. Trong nhiều trường hợp, trình biên dịch sẽ tối ưu hóa nó đi. Vì vậy, lập luận rằng nó không cần thiết không thuyết phục tôi.

5. Nếu bạn đã sử dụng RAII, thì không có nhiều deletemã trong mã của bạn để bắt đầu, do đó, lập luận rằng việc gán thêm gây ra sự lộn xộn không thuyết phục được tôi.

6. Thật tiện lợi, khi gỡ lỗi, để xem giá trị null thay vì con trỏ cũ.

7. Nếu điều này vẫn làm phiền bạn, hãy sử dụng một con trỏ thông minh hoặc một tham chiếu thay thế.

Tôi cũng đặt các loại xử lý tài nguyên khác thành giá trị không có tài nguyên khi tài nguyên là miễn phí (thường chỉ có trong hàm hủy của trình bao bọc RAII được viết để đóng gói tài nguyên).

Tôi đã làm việc trên một sản phẩm thương mại lớn (9 triệu báo cáo) (chủ yếu bằng C). Tại một thời điểm, chúng tôi đã sử dụng ma thuật macro để loại bỏ con trỏ khi bộ nhớ được giải phóng. Điều này ngay lập tức phơi bày rất nhiều lỗi ẩn nấp đã được khắc phục kịp thời. Theo như tôi có thể nhớ, chúng tôi chưa bao giờ có lỗi kép.

Cập nhật: Microsoft tin rằng đó là một cách thực hành tốt cho bảo mật và khuyến nghị thực hành trong các chính sách SDL của họ. Rõ ràng MSVC ++ 11 sẽ tự động dậm con trỏ bị xóa (trong nhiều trường hợp) nếu bạn biên dịch với tùy chọn / SDL.

Đầu tiên, có rất nhiều câu hỏi hiện có về chủ đề này và các chủ đề liên quan chặt chẽ, ví dụ Tại sao không xóa đặt con trỏ thành NULL? .

Trong mã của bạn, vấn đề xảy ra (sử dụng p). Ví dụ: nếu ở đâu đó bạn có mã như thế này:

Foo * p2 = p;

sau đó thiết lập p để NULL hoàn thành rất ít, vì bạn vẫn còn con trỏ p2 phải lo lắng.

Điều này không có nghĩa là việc đặt một con trỏ tới NULL luôn là vô nghĩa. Ví dụ: nếu p là biến thành viên trỏ đến tài nguyên thì tuổi thọ của nó không hoàn toàn giống với lớp chứa p, thì đặt p thành NULL có thể là một cách hữu ích để chỉ ra sự hiện diện hay vắng mặt của tài nguyên.

Nếu có thêm mã sau delete, Có. Khi con trỏ bị xóa trong hàm tạo hoặc ở cuối phương thức hoặc hàm, Không.

Điểm của dụ ngôn này là để nhắc nhở lập trình viên, trong thời gian chạy, đối tượng đã bị xóa.

Một cách thực hành tốt hơn nữa là sử dụng Smart Pointers (chia sẻ hoặc có phạm vi) để tự động xóa các đối tượng mục tiêu của chúng.

Như những người khác đã nói, delete ptr; ptr = 0;sẽ không khiến quỷ bay ra khỏi mũi của bạn. Tuy nhiên, nó không khuyến khích việc sử dụng ptrnhư một loại cờ. Mã trở nên bị vấy bẩn deletevà đặt con trỏ thành NULL. Bước tiếp theo là phân tán if (arg == NULL) return;mã của bạn để bảo vệ chống lại việc sử dụng NULLcon trỏ vô tình . Sự cố xảy ra khi kiểm traNULL trở thành phương tiện chính của bạn để kiểm tra trạng thái của một đối tượng hoặc chương trình.

Tôi chắc chắn rằng có một mùi mã về việc sử dụng một con trỏ làm cờ ở đâu đó nhưng tôi chưa tìm thấy.

Tôi sẽ thay đổi câu hỏi của bạn một chút:

Bạn sẽ sử dụng một con trỏ chưa được khởi tạo? Bạn có biết, một cái mà bạn đã không đặt thành NULL hoặc phân bổ bộ nhớ mà nó trỏ tới?

Có hai kịch bản trong đó việc đặt con trỏ thành NULL có thể được bỏ qua:

• biến con trỏ đi ra khỏi phạm vi ngay lập tức
• bạn đã quá tải ngữ nghĩa của con trỏ và đang sử dụng giá trị của nó không chỉ như một con trỏ bộ nhớ, mà còn như một khóa hoặc giá trị thô. Cách tiếp cận này tuy nhiên bị các vấn đề khác.

Trong khi đó, lập luận rằng việc đặt con trỏ thành NULL có thể ẩn lỗi đối với tôi nghe có vẻ như tranh luận rằng bạn không nên sửa lỗi vì bản sửa lỗi có thể ẩn một lỗi khác. Các lỗi duy nhất có thể hiển thị nếu con trỏ không được đặt thành NULL sẽ là các lỗi cố gắng sử dụng con trỏ. Nhưng việc đặt nó thành NULL thực sự sẽ gây ra chính xác lỗi tương tự như hiển thị nếu bạn sử dụng nó với bộ nhớ đã giải phóng, phải không?

Nếu bạn không có ràng buộc nào khác buộc bạn phải đặt hoặc không đặt con trỏ thành NULL sau khi bạn xóa nó (một ràng buộc như vậy đã được Neil Butterworth đề cập ), thì sở thích cá nhân của tôi là để nguyên.

Đối với tôi, câu hỏi không phải "đây có phải là một ý tưởng tốt?" nhưng "hành vi nào tôi sẽ ngăn chặn hoặc cho phép thành công bằng cách làm điều này?" Ví dụ, nếu điều này cho phép mã khác thấy rằng con trỏ không còn khả dụng, tại sao mã khác thậm chí còn cố gắng xem các con trỏ được giải phóng sau khi chúng được giải phóng? Thông thường, đó là một lỗi.

Nó cũng làm nhiều việc hơn mức cần thiết cũng như cản trở việc gỡ lỗi sau khi chết. Bạn càng ít chạm vào bộ nhớ sau khi bạn không cần nó, bạn càng dễ dàng tìm ra lý do tại sao một cái gì đó bị hỏng. Nhiều lần tôi đã dựa vào thực tế rằng bộ nhớ ở trạng thái tương tự như khi một lỗi cụ thể xảy ra để chẩn đoán và sửa lỗi đã nói.

Hoàn toàn vô hiệu hóa sau khi xóa mạnh mẽ gợi ý cho người đọc rằng con trỏ đại diện cho một cái gì đó là tùy chọn về mặt khái niệm . Nếu tôi thấy điều đó đã được thực hiện, tôi sẽ bắt đầu lo lắng rằng mọi nơi trong nguồn con trỏ sẽ được sử dụng rằng nó nên được thử nghiệm đầu tiên chống lại NULL.

Nếu đó là những gì bạn thực sự muốn nói, tốt hơn là làm cho nó rõ ràng trong nguồn bằng cách sử dụng cái gì đó như boost :: tùy chọn

optional<Foo*> p (new Foo);
// (use p.get(), but must test p for truth first!...)
delete p.get();
p = optional<Foo*>();

Nhưng nếu bạn thực sự muốn mọi người biết con trỏ đã "xấu đi", tôi sẽ thỏa thuận 100% với những người nói rằng điều tốt nhất để làm là làm cho nó vượt ra khỏi phạm vi. Sau đó, bạn đang sử dụng trình biên dịch để ngăn chặn khả năng xảy ra tình trạng xấu trong thời gian chạy.

Đó là em bé trong tất cả nước tắm C ++, không nên vứt nó đi. :)

Trong một chương trình có cấu trúc tốt với kiểm tra lỗi thích hợp, không có lý do gì để không gán nó null. 0đứng một mình như một giá trị không hợp lệ được công nhận toàn cầu trong bối cảnh này. Thất bại khó khăn và Thất bại sớm.

Nhiều đối số chống lại việc gán 0cho thấy rằng nó có thể ẩn một lỗi hoặc làm phức tạp luồng điều khiển. Về cơ bản, đó là một lỗi ngược dòng (không phải lỗi của bạn (xin lỗi vì lỗi xấu)) hoặc một lỗi khác thay cho lập trình viên - thậm chí có thể là một dấu hiệu cho thấy dòng chương trình đã phát triển quá phức tạp.

Nếu lập trình viên muốn giới thiệu việc sử dụng một con trỏ có thể là giá trị đặc biệt và viết tất cả các né tránh cần thiết xung quanh đó, thì đó là một sự phức tạp mà họ đã cố tình đưa ra. Việc kiểm dịch càng tốt, bạn càng sớm phát hiện ra các trường hợp sử dụng sai và càng ít có khả năng lây lan sang các chương trình khác.

Các chương trình có cấu trúc tốt có thể được thiết kế bằng các tính năng C ++ để tránh những trường hợp này. Bạn có thể sử dụng tài liệu tham khảo hoặc bạn chỉ có thể nói "truyền / sử dụng đối số null hoặc không hợp lệ là một lỗi" - một cách tiếp cận có thể áp dụng tương tự cho các thùng chứa, chẳng hạn như con trỏ thông minh. Tăng hành vi nhất quán và đúng đắn ngăn cấm các lỗi này đi xa.

Từ đó, bạn chỉ có một phạm vi và bối cảnh rất hạn chế nơi con trỏ null có thể tồn tại (hoặc được cho phép).

Điều tương tự có thể được áp dụng cho con trỏ không const. Theo sau giá trị của một con trỏ là không đáng kể vì phạm vi của nó quá nhỏ và việc sử dụng không đúng được kiểm tra và xác định rõ. Nếu bộ công cụ và kỹ sư của bạn không thể theo dõi chương trình sau khi đọc nhanh hoặc có kiểm tra lỗi không phù hợp hoặc luồng chương trình không nhất quán / khoan hồng, bạn có vấn đề khác, lớn hơn.

Cuối cùng, trình biên dịch và môi trường của bạn có thể có một số người bảo vệ cho những lần bạn muốn đưa ra lỗi (viết nguệch ngoạc), phát hiện truy cập vào bộ nhớ đã giải phóng và bắt các UB liên quan khác. Bạn cũng có thể giới thiệu chẩn đoán tương tự vào các chương trình của mình, thường xuyên mà không ảnh hưởng đến các chương trình hiện có.

Hãy để tôi mở rộng những gì bạn đã đặt vào câu hỏi của bạn.

Đây là những gì bạn đã đặt vào câu hỏi của bạn, ở dạng gạch đầu dòng:

Đặt con trỏ thành NULL sau khi xóa không phải là thông lệ tốt trong C ++. Có những lúc:

• đó là một điều tốt để làm
• và thời gian khi nó là vô nghĩa và có thể ẩn lỗi.

Tuy nhiên, không có lần nào điều này là xấu ! Bạn sẽ không giới thiệu nhiều lỗi hơn bằng cách vô hiệu hóa nó, bạn sẽ không rò rỉ bộ nhớ, bạn sẽ không khiến hành vi không xác định xảy ra.

Vì vậy, nếu nghi ngờ, chỉ cần null nó.

Phải nói rằng, nếu bạn cảm thấy rằng bạn phải vô hiệu hóa một số con trỏ, thì với tôi điều này nghe có vẻ như bạn chưa tách ra một phương thức đủ, và nên xem phương pháp tái cấu trúc gọi là "Phương thức trích xuất" để tách phương thức thành các bộ phận riêng biệt.

Đúng.

"Tác hại" duy nhất có thể làm là đưa sự kém hiệu quả (một hoạt động lưu trữ không cần thiết) vào chương trình của bạn - nhưng chi phí này sẽ không đáng kể liên quan đến chi phí phân bổ và giải phóng khối bộ nhớ trong hầu hết các trường hợp.

Nếu bạn không làm điều đó, một ngày nào đó bạn sẽ gặp phải một số lỗi khó chịu.

Tôi luôn sử dụng macro để xóa:

#define SAFEDELETE(ptr) { delete(ptr); ptr = NULL; }

(và tương tự cho một mảng, free (), giải phóng tay cầm)

Bạn cũng có thể viết các phương thức "tự xóa" lấy tham chiếu đến con trỏ của mã gọi, để chúng buộc con trỏ của mã gọi đến NULL. Ví dụ: để xóa một cây con của nhiều đối tượng:

static void TreeItem::DeleteSubtree(TreeItem *&rootObject)
{
    if (rootObject == NULL)
        return;

    rootObject->UnlinkFromParent();

    for (int i = 0; i < numChildren)
       DeleteSubtree(rootObject->child[i]);

    delete rootObject;
    rootObject = NULL;
}

biên tập

Vâng, các kỹ thuật này vi phạm một số quy tắc về việc sử dụng macro (và vâng, ngày nay bạn có thể đạt được kết quả tương tự với các mẫu) - nhưng bằng cách sử dụng trong nhiều năm, tôi chưa bao giờ truy cập vào bộ nhớ chết - một trong những điều khó khăn và khó khăn nhất và tốn nhiều thời gian nhất để gỡ lỗi các vấn đề bạn có thể gặp phải. Trong thực tế trong nhiều năm, họ đã loại bỏ một cách hiệu quả một lớp lỗi từ mọi đội tôi đã giới thiệu cho họ.

Ngoài ra còn có nhiều cách bạn có thể thực hiện như trên - Tôi chỉ cố gắng minh họa ý tưởng buộc mọi người phải NULL một con trỏ nếu họ xóa một đối tượng, thay vì cung cấp một phương tiện để họ giải phóng bộ nhớ không NULL con trỏ của người gọi .

Tất nhiên, ví dụ trên chỉ là một bước tiến tới một con trỏ tự động. Điều mà tôi không đề xuất vì OP đặc biệt hỏi về trường hợp không sử dụng con trỏ tự động.

"Có những lúc nó là một việc nên làm, và có những lúc nó là vô nghĩa và có thể che giấu lỗi"

Tôi có thể thấy hai vấn đề: Mã đơn giản đó:

delete myObj;
myobj = 0

trở thành một lớp lót trong môi trường đa luồng:

lock(myObjMutex); 
delete myObj;
myobj = 0
unlock(myObjMutex);

"Thực hành tốt nhất" của Don Neufeld không được áp dụng luôn. Ví dụ, trong một dự án ô tô, chúng tôi phải đặt con trỏ về 0 ngay cả trong các hàm hủy. Tôi có thể tưởng tượng trong phần mềm quan trọng an toàn quy tắc như vậy không phải là hiếm. Theo dõi họ sẽ dễ dàng hơn (và khôn ngoan) hơn là cố gắng thuyết phục nhóm / người kiểm tra mã cho mỗi con trỏ sử dụng trong mã, rằng một dòng vô hiệu hóa con trỏ này là dư thừa.

Một mối nguy hiểm khác là dựa vào kỹ thuật này trong các trường hợp ngoại lệ - sử dụng mã:

try{  
   delete myObj; //exception in destructor
   myObj=0
}
catch
{
   //myObj=0; <- possibly resource-leak
}

if (myObj)
  // use myObj <--undefined behaviour

Trong mã như vậy hoặc bạn tạo ra rò rỉ tài nguyên và hoãn sự cố hoặc quá trình gặp sự cố.

Vì vậy, hai vấn đề này tự phát qua đầu tôi (Herb Sutter chắc chắn sẽ nói thêm) làm cho tôi tất cả các câu hỏi thuộc loại "Làm thế nào để tránh sử dụng con trỏ thông minh và thực hiện công việc một cách an toàn với con trỏ bình thường" là lỗi thời.

Luôn luôn có con trỏ Dangling để lo lắng về.

Nếu bạn định phân bổ lại con trỏ trước khi sử dụng lại (hủy bỏ nó, chuyển nó đến một hàm, v.v.), làm cho con trỏ NULL chỉ là một thao tác bổ sung. Tuy nhiên, nếu bạn không chắc chắn liệu nó có được phân bổ lại hay không trước khi sử dụng lại, đặt nó thành NULL là một ý tưởng hay.

Như nhiều người đã nói, tất nhiên việc sử dụng con trỏ thông minh sẽ dễ dàng hơn nhiều.

Chỉnh sửa: Như Thomas Matthews đã nói trong câu trả lời trước đó , nếu một con trỏ bị xóa trong hàm hủy, thì không cần gán NULL cho nó vì nó sẽ không được sử dụng lại vì đối tượng đã bị hủy.

Tôi có thể tưởng tượng việc đặt một con trỏ thành NULL sau khi xóa nó trở nên hữu ích trong những trường hợp hiếm hoi khi có một kịch bản hợp pháp là sử dụng lại nó trong một hàm (hoặc đối tượng) duy nhất. Mặt khác, nó không có ý nghĩa - một con trỏ cần trỏ đến một cái gì đó có ý nghĩa miễn là nó tồn tại - thời gian.

Nếu mã không thuộc về phần quan trọng nhất về hiệu năng của ứng dụng của bạn, hãy giữ cho nó đơn giản và sử dụng shared_ptr:

shared_ptr<Foo> p(new Foo);
//No more need to call delete

Nó thực hiện đếm tham chiếu và an toàn chủ đề. Bạn có thể tìm thấy nó trong không gian tên tr1 (std :: tr1, #include <memory>) hoặc nếu trình biên dịch của bạn không cung cấp nó, hãy lấy nó từ boost.