Mới (std :: nothrow) so với New trong khối try/catch

Question

Tôi đã thực hiện một số nghiên cứu sau khi học new, không giống như malloc() mà tôi đã sử dụng, không trả về NULL cho phân bổ không thành công và thấy có hai cách riêng biệt kiểm tra xem liệu mới có thành công hay không. Những hai cách là:

try 
{ 
    ptr = new int[1024]; 
} 
catch(std::bad_alloc& exc) 
{ 
    assert(); 
}; 

và

ptr = new (std::nothrow) int[1024]; 
if(ptr == NULL) 
    assert(); 

Tôi tin rằng hai cách đạt được cùng một mục tiêu, (! Đúng cho tôi nếu tôi sai dĩ nhiên), vì vậy câu hỏi của tôi là thế này:

là tùy chọn tốt hơn để kiểm tra xem new có thành công hay không, hoàn toàn dựa trên khả năng đọc, bảo trì và hiệu suất, trong khi bỏ qua quy ước lập trình C++ không thực tế.

Answer 1

Hãy xem xét những gì bạn đang làm. Bạn đang cấp phát bộ nhớ. Và nếu vì lý do nào đó, việc cấp phát bộ nhớ không thể hoạt động, bạn assert. Đó là nhiều hơn hoặc ít hơn chính xác những gì sẽ xảy ra nếu bạn chỉ cần để cho các std::bad_alloc tuyên truyền trở lại main. Trong bản phát hành bản phát hành, trong đó assert là chương trình không hoạt động, chương trình của bạn sẽ bị lỗi khi cố gắng truy cập vào bộ nhớ. Vì vậy, nó cũng giống như để cho các trường hợp ngoại lệ bong bóng lên: tạm dừng ứng dụng.

Vì vậy, hãy tự hỏi mình một câu hỏi: Bạn có thực sự cần phải quan tâm điều gì xảy ra nếu bạn hết bộ nhớ? Nếu tất cả những gì bạn đang làm là khẳng định, thì phương pháp ngoại lệ là tốt hơn, bởi vì nó không làm lộn xộn mã của bạn với ngẫu nhiên assert s. Bạn chỉ để cho ngoại lệ rơi trở lại main.

Nếu thực tế bạn có một bản mã đặc biệt trong trường hợp bạn không thể cấp phát bộ nhớ (nghĩa là bạn có thể tiếp tục hoạt động), ngoại lệ có thể hoặc không phải là cách để đi, tùy thuộc vào hệ thống . Nếu codepath chỉ là một switch được thiết lập bằng cách có một con trỏ là null, thì phiên bản nothrow sẽ đơn giản hơn.Nếu thay vào đó, bạn cần phải làm một cái gì đó khá khác nhau (kéo từ một bộ đệm tĩnh, hoặc xóa một số thứ, hoặc bất cứ thứ gì), sau đó bắt std::bad_alloc là khá tốt.

Answer 2

Tùy thuộc vào ngữ cảnh phân bổ đang diễn ra ở đâu. Nếu chương trình của bạn có thể tiếp tục ngay cả khi phân bổ không thành công (có thể trả lại mã lỗi cho người gọi), hãy sử dụng phương thức std::nothrow và kiểm tra NULL. Nếu không, bạn sẽ sử dụng các ngoại lệ cho luồng điều khiển, đó là cách thực hành không tốt. Mặt khác, nếu chương trình của bạn hoàn toàn cần phải có bộ nhớ được phân bổ thành công để có thể hoạt động, hãy sử dụng try-catch để bắt (không nhất thiết ở vùng lân cận của new) một ngoại lệ và thoát ra một cách duyên dáng từ chương trình.

Answer 3

Từ góc độ hiệu suất thuần túy, điều đó rất quan trọng. Có chi phí vốn có với xử lý ngoại lệ, mặc dù chi phí này thường đáng để giao dịch trong khả năng đọc và bảo trì ứng dụng. Lỗi phân bổ bộ nhớ của bản chất này không được trong trường hợp 99% của đơn đăng ký của bạn, vì vậy điều này sẽ xảy ra không thường xuyên.

Từ góc độ hiệu suất, bạn thường muốn tránh trình phân bổ chuẩn do hiệu suất tương đối kém. Tất cả điều này nói rằng, tôi thường chấp nhận phiên bản ném ngoại lệ vì thông thường các ứng dụng của chúng tôi ở trạng thái nếu phân bổ bộ nhớ không thành công, chúng ta có thể làm việc khác ngoài thoát một cách duyên dáng với thông báo lỗi thích hợp. không yêu cầu NULL kiểm tra tài nguyên mới được phân bổ của chúng tôi bởi vì theo định nghĩa, lỗi phân bổ sẽ di chuyển phạm vi ra khỏi vị trí quan trọng.

Answer 4

new được sử dụng để tạo đối tượng, không cấp phát bộ nhớ, do đó ví dụ của bạn có phần nhân tạo.

Trình tạo đối tượng thường ném nếu chúng không thành công. Có bước qua thực hiện new trong Visual Studio nhiều hơn một vài lần, tôi không tin rằng mã bắt bất kỳ trường hợp ngoại lệ. Do đó, việc tìm kiếm các ngoại lệ khi tạo đối tượng là rất hợp lý.

I nghĩstd::bad_alloc chỉ được ném nếu phần cấp phát bộ nhớ không thành công. Tôi không chắc chắn điều gì sẽ xảy ra nếu bạn vượt qua std::nothrow đến new nhưng trình tạo đối tượng sẽ ném - có sự mơ hồ trong tài liệu tôi đã đọc.

Sự khác biệt về hiệu suất giữa 2 phương pháp tiếp cận có lẽ không liên quan vì hầu hết thời gian xử lý có thể dễ dàng được chi tiêu trong hàm tạo đối tượng hoặc tìm kiếm vùng heap.

Quy tắc không phải lúc nào cũng phù hợp. Ví dụ, các hệ thống thời gian thực thường hạn chế phân bổ bộ nhớ động, vì vậy new, nếu có, có lẽ sẽ bị quá tải. Trong trường hợp đó, nó có thể sử dụng một con trỏ null trả về và xử lý thất bại cục bộ.