Tại sao sử dụng std :: make_unique trong C ++ 17?

Theo như tôi hiểu, C ++ 14 đã giới thiệu std::make_uniquebởi vì, do thứ tự đánh giá tham số không được chỉ định, điều này không an toàn:

f(std::unique_ptr<MyClass>(new MyClass(param)), g()); // Syntax A

(Giải thích: nếu lần đánh giá đầu tiên cấp phát bộ nhớ cho con trỏ thô, sau đó các lệnh gọi g()và một ngoại lệ được đưa ra trước khi std::unique_ptrxây dựng, thì bộ nhớ sẽ bị rò rỉ.)

Gọi điện std::make_uniquelà một cách để hạn chế thứ tự cuộc gọi, do đó giúp mọi thứ an toàn:

f(std::make_unique<MyClass>(param), g());             // Syntax B

Kể từ đó, C ++ 17 đã làm rõ thứ tự đánh giá, làm cho Cú pháp A cũng an toàn, vì vậy đây là câu hỏi của tôi: vẫn còn lý do để sử dụng hàm tạo std::make_uniqueover std::unique_ptr's trong C ++ 17? Bạn có thể cho một số ví dụ?

Hiện tại, lý do duy nhất tôi có thể tưởng tượng là nó chỉ cho phép nhập MyClassmột lần (giả sử bạn không cần dựa vào tính đa hình với std::unique_ptr<Base>(new Derived(param))). Tuy nhiên, đó có vẻ như là một lý do khá yếu, đặc biệt là khi std::make_uniquekhông cho phép chỉ định một trình phân định trong khi phương std::unique_ptrthức khởi tạo của thì không.

Và chỉ cần nói rõ, tôi không ủng hộ việc xóa std::make_uniquekhỏi Thư viện Chuẩn (ít nhất là giữ cho nó có ý nghĩa đối với khả năng tương thích ngược), mà là tự hỏi liệu vẫn còn những tình huống mà nó được ưu tiên hơnstd::unique_ptr

Bạn nói đúng rằng lý do chính đã bị loại bỏ. Vẫn có những nguyên tắc không sử dụng mới và đó là lý do gõ ít hơn (không phải lặp lại kiểu hoặc sử dụng từ new). Phải thừa nhận rằng đó không phải là những lập luận mạnh mẽ nhưng tôi thực sự không muốn thấy newtrong mã của mình.

Cũng đừng quên về tính nhất quán. Bạn hoàn toàn nên sử dụng make_sharedđể sử dụng make_uniquelà tự nhiên và phù hợp với các mô hình. Sau đó, thật đơn giản nếu thay đổi std::make_unique<MyClass>(param)thành std::make_shared<MyClass>(param)(hoặc ngược lại) trong đó cú pháp A yêu cầu viết lại nhiều hơn.

make_uniquephân biệt Tvới T[]và T[N], unique_ptr(new ...)không.

Bạn có thể dễ dàng nhận được hành vi không xác định bằng cách chuyển một con trỏ đã được chỉnh new[]sửa đến a unique_ptr<T>hoặc bằng cách chuyển một con trỏ đã được chỉnh newsửa đến a unique_ptr<T[]>.

Lý do là để có mã ngắn hơn mà không bị trùng lặp. Đối chiếu

f(std::unique_ptr<MyClass>(new MyClass(param)), g());
f(std::make_unique<MyClass>(param), g());

Bạn tiết kiệm MyClass, newvà niềng răng. Chi phí chỉ có một nhân vật hơn trong làm so với ptr .

Mọi việc sử dụng newđều phải được kiểm tra cẩn thận để đảm bảo tính đúng đắn suốt đời; nó có bị xóa không? Chỉ một lần?

Mọi việc sử dụng make_uniquekhông dành cho những đặc điểm phụ đó; miễn là đối tượng sở hữu có thời gian tồn tại "đúng", nó đệ quy làm cho con trỏ duy nhất có "đúng".

Bây giờ, đúng unique_ptr<Foo>(new Foo())là giống hệt nhau theo mọi cách ^{từ 1} đến make_unique<Foo>(); nó chỉ yêu cầu đơn giản hơn "gửi mã nguồn của bạn cho tất cả các mục đích sử dụng newđể kiểm tra chúng".

¹ thực sự là một lời nói dối trong trường hợp chung. Chuyển tiếp hoàn hảo không phải là hoàn hảo, {}init mặc định, mảng đều là ngoại lệ.

Kể từ đó, C ++ 17 đã làm rõ thứ tự đánh giá, làm cho Cú pháp A cũng an toàn

Điều đó thực sự không đủ tốt. Việc dựa vào một điều khoản kỹ thuật mới được giới thiệu gần đây để đảm bảo an toàn không phải là một thực tiễn mạnh mẽ:

• Ai đó có thể biên dịch mã này trong C ++ 14.
• Bạn sẽ khuyến khích việc sử dụng dữ liệu thô newở nơi khác, ví dụ bằng cách sao chép-dán ví dụ của bạn.
• Như SM gợi ý, vì có sự trùng lặp mã, một loại có thể bị thay đổi mà không thay đổi được loại còn lại.
• Một số loại tái cấu trúc IDE tự động có thể di chuyển nó đến newnơi khác (được, được, không có nhiều cơ hội như vậy).

Nói chung, đó là một ý tưởng hay để mã của bạn phù hợp / mạnh mẽ / hợp lệ rõ ràng mà không cần dùng đến ngôn ngữ sắp xếp, tra cứu các điều khoản kỹ thuật nhỏ hoặc khó hiểu trong tiêu chuẩn.

(Về cơ bản đây là lập luận tương tự mà tôi đã đưa ra ở đây về thứ tự phá hủy tuple.)

Hãy xem xét hàm void (std :: unique_ptr (new A ()), std :: unique_ptr (new B ())) {...}

Giả sử rằng A () mới thành công, nhưng B () mới ném ra một ngoại lệ: bạn bắt nó để tiếp tục thực hiện bình thường chương trình của bạn. Thật không may, tiêu chuẩn C ++ không yêu cầu đối tượng A bị phá hủy và bộ nhớ của nó bị phân bổ: bộ nhớ âm thầm rò rỉ và không có cách nào để dọn dẹp nó. Bằng cách gói A và B vào std :: make_uniques, bạn chắc chắn rằng việc rò rỉ sẽ không xảy ra:

void function (std :: make_unique (), std :: make_unique ()) {...} Vấn đề ở đây là std :: make_unique và std :: make_unique hiện là các đối tượng tạm thời và việc dọn dẹp các đối tượng tạm thời được chỉ định chính xác trong tiêu chuẩn C ++: các trình hủy của chúng sẽ được kích hoạt và bộ nhớ được giải phóng. Vì vậy, nếu bạn có thể, hãy luôn thích phân bổ các đối tượng bằng cách sử dụng std :: make_unique và std :: make_shared.