Có sử dụng cho unique_ptr với mảng không?

std::unique_ptr có hỗ trợ cho mảng, ví dụ:

std::unique_ptr<int[]> p(new int[10]);

Nhưng nó có cần thiết không? có lẽ nó là thuận tiện hơn để sử dụng std::vectorhoặc std::array.

Bạn có tìm thấy bất kỳ sử dụng cho cấu trúc đó?

Một số người không có sự sang trọng trong việc sử dụng std::vector, ngay cả với người cấp phát. Một số người cần một mảng kích thước động, như vậy std::arraylà ra. Và một số người nhận được mảng của họ từ mã khác được biết là trả về một mảng; và mã đó sẽ không được viết lại để trả về một vectorhoặc một cái gì đó.

Bằng cách cho phép unique_ptr<T[]>, bạn phục vụ những nhu cầu đó.

Tóm lại, bạn sử dụng unique_ptr<T[]>khi bạn cần . Khi các lựa chọn thay thế đơn giản là sẽ không làm việc cho bạn. Đó là một công cụ của phương sách cuối cùng.

Có sự đánh đổi, và bạn chọn giải pháp phù hợp với những gì bạn muốn. Off đỉnh đầu của tôi:

Kích thước ban đầu

• vectorvà unique_ptr<T[]>cho phép kích thước được chỉ định trong thời gian chạy
• array chỉ cho phép kích thước được chỉ định tại thời gian biên dịch

Thay đổi kích thước

• arrayvà unique_ptr<T[]>không cho phép thay đổi kích thước
• vector làm

Lưu trữ

• vectorvà unique_ptr<T[]>lưu trữ dữ liệu bên ngoài đối tượng (thường là trên heap)
• array lưu trữ dữ liệu trực tiếp trong đối tượng

Đang sao chép

• arrayvà vectorcho phép sao chép
• unique_ptr<T[]> không cho phép sao chép

Hoán đổi / di chuyển

• vectorvà unique_ptr<T[]>có O (1) thời gian swapvà các hoạt động di chuyển
• arraycó O (n) thời gian swapvà các hoạt động di chuyển, trong đó n là số phần tử trong mảng

Con trỏ / tham chiếu / iterator không hợp lệ

• array đảm bảo các con trỏ, tham chiếu và các trình vòng lặp sẽ không bao giờ bị vô hiệu trong khi đối tượng đang hoạt động, ngay cả trên swap()
• unique_ptr<T[]>không có vòng lặp; con trỏ và tham chiếu chỉ bị vô hiệu bởi swap()trong khi đối tượng đang sống. (Sau khi hoán đổi, các con trỏ trỏ vào mảng mà bạn đã tráo đổi, vì vậy chúng vẫn "hợp lệ" theo nghĩa đó.)
• vector có thể làm mất hiệu lực con trỏ, tham chiếu và lặp trong bất kỳ sự phân bổ lại nào (và cung cấp một số đảm bảo rằng việc tái phân bổ chỉ có thể xảy ra đối với các hoạt động nhất định).

Khả năng tương thích với các khái niệm và thuật toán

• arrayvà vectorlà cả hai Container
• unique_ptr<T[]> không phải là một container

Tôi phải thừa nhận, đây có vẻ là một cơ hội cho một số tái cấu trúc với thiết kế dựa trên chính sách.

Một lý do bạn có thể sử dụng unique_ptrlà nếu bạn không muốn trả chi phí thời gian chạy của việc khởi tạo giá trị mảng.

std::vector<char> vec(1000000); // allocates AND value-initializes 1000000 chars

std::unique_ptr<char[]> p(new char[1000000]); // allocates storage for 1000000 chars

Hàm std::vectortạo và std::vector::resize()sẽ khởi tạo giá trị T- nhưng newsẽ không làm điều đó nếu Tlà POD.

Xem các đối tượng khởi tạo giá trị trong C ++ 11 và std :: vector constructor

Lưu ý rằng vector::reserveđây không phải là một thay thế ở đây: Truy cập con trỏ thô sau std :: vector :: reserved có an toàn không?

Đó là cùng một lý do một lập trình viên C có thể chọn mallochơn calloc.

An std::vectorcó thể được sao chép xung quanh, trong khi unique_ptr<int[]>cho phép thể hiện quyền sở hữu duy nhất của mảng. std::arraymặt khác, yêu cầu kích thước được xác định tại thời điểm biên dịch, có thể là không thể trong một số trường hợp.

Scott Meyers có điều này để nói trong C ++ hiện đại hiệu quả

Sự tồn tại của std::unique_ptrđối với mảng nên chỉ quan tâm đến trí tuệ đối với bạn, bởi vì std::array, std::vector, std::stringhầu như lúc nào cũng lựa chọn cấu trúc dữ liệu tốt hơn so với mảng thô. Về tình huống duy nhất tôi có thể hình dung khi nào std::unique_ptr<T[]>sẽ có ý nghĩa khi bạn đang sử dụng API giống như C trả về một con trỏ thô cho một mảng heap mà bạn cho là quyền sở hữu.

Tôi nghĩ rằng câu trả lời của Charles Salvia có liên quan mặc dù: đó std::unique_ptr<T[]>là cách duy nhất để khởi tạo một mảng trống có kích thước không được biết đến tại thời điểm biên dịch. Scott Meyers sẽ nói gì về động lực này khi sử dụng std::unique_ptr<T[]>?

Trái ngược với std::vectorvà std::array, std::unique_ptrcó thể sở hữu một con trỏ NULL.
Điều này rất hữu ích khi làm việc với các API C mong đợi một mảng hoặc NULL:

void legacy_func(const int *array_or_null);

void some_func() {    
    std::unique_ptr<int[]> ptr;
    if (some_condition) {
        ptr.reset(new int[10]);
    }

    legacy_func(ptr.get());
}

Tôi đã sử dụng unique_ptr<char[]>để thực hiện một nhóm bộ nhớ preallocated được sử dụng trong một công cụ trò chơi. Ý tưởng là cung cấp các nhóm bộ nhớ preallocated được sử dụng thay vì phân bổ động để trả về kết quả yêu cầu va chạm và các thứ khác như vật lý hạt mà không phải phân bổ / bộ nhớ trống ở mỗi khung. Nó khá thuận tiện cho loại kịch bản này khi bạn cần nhóm bộ nhớ để phân bổ các đối tượng có thời gian sử dụng hạn chế (thường là một, 2 hoặc 3 khung hình) không yêu cầu logic phá hủy (chỉ phân bổ bộ nhớ).

Có thể tìm thấy một mẫu chung trong một số lệnh gọi Windows Win32 API , trong đó việc sử dụng std::unique_ptr<T[]>có thể có ích, ví dụ: khi bạn không biết chính xác bộ đệm đầu ra sẽ lớn như thế nào khi gọi một số API Win32 (sẽ ghi một số dữ liệu bên trong bộ đệm đó):

// Buffer dynamically allocated by the caller, and filled by some Win32 API function.
// (Allocation will be made inside the 'while' loop below.)
std::unique_ptr<BYTE[]> buffer;

// Buffer length, in bytes.
// Initialize with some initial length that you expect to succeed at the first API call.
UINT32 bufferLength = /* ... */;

LONG returnCode = ERROR_INSUFFICIENT_BUFFER;
while (returnCode == ERROR_INSUFFICIENT_BUFFER)
{
    // Allocate buffer of specified length
    buffer.reset( BYTE[bufferLength] );
    //        
    // Or, in C++14, could use make_unique() instead, e.g.
    //
    // buffer = std::make_unique<BYTE[]>(bufferLength);
    //

    //
    // Call some Win32 API.
    //
    // If the size of the buffer (stored in 'bufferLength') is not big enough,
    // the API will return ERROR_INSUFFICIENT_BUFFER, and the required size
    // in the [in, out] parameter 'bufferLength'.
    // In that case, there will be another try in the next loop iteration
    // (with the allocation of a bigger buffer).
    //
    // Else, we'll exit the while loop body, and there will be either a failure
    // different from ERROR_INSUFFICIENT_BUFFER, or the call will be successful
    // and the required information will be available in the buffer.
    //
    returnCode = ::SomeApiCall(inParam1, inParam2, inParam3, 
                               &bufferLength, // size of output buffer
                               buffer.get(),  // output buffer pointer
                               &outParam1, &outParam2);
}

if (Failed(returnCode))
{
    // Handle failure, or throw exception, etc.
    ...
}

// All right!
// Do some processing with the returned information...
...

Tôi đã phải đối mặt với một trường hợp mà tôi phải sử dụng std::unique_ptr<bool[]>, đó là trong thư viện HDF5 (Một thư viện lưu trữ dữ liệu nhị phân hiệu quả, được sử dụng rất nhiều trong khoa học). Một số trình biên dịch (Visual Studio 2015 trong trường hợp của tôi) cung cấp khả năng nénstd::vector<bool> (bằng cách sử dụng 8 bool trong mỗi byte), đây là một thảm họa đối với một cái gì đó như HDF5, không quan tâm đến việc nén đó. Với std::vector<bool>, HDF5 cuối cùng đã đọc rác vì nén đó.

Đoán xem ai đã ở đó để giải cứu, trong trường hợp std::vectorkhông hoạt động và tôi cần phân bổ một mảng động một cách sạch sẽ? :-)

Tóm lại: đó là hiệu quả bộ nhớ cao nhất.

A std::stringđi kèm với một con trỏ, độ dài và bộ đệm "tối ưu hóa chuỗi ngắn". Nhưng tình huống của tôi là tôi cần lưu trữ một chuỗi gần như luôn trống, trong một cấu trúc mà tôi có hàng trăm ngàn. Trong C, tôi sẽ chỉ sử dụng char *, và nó sẽ là null hầu hết thời gian. Điều này cũng hoạt động với C ++, ngoại trừ việc a char *không có hàm hủy và không biết tự xóa. Ngược lại, a std::unique_ptr<char[]>sẽ tự xóa khi đi ra khỏi phạm vi. Một khoảng trống std::stringchiếm tới 32 byte, nhưng một khoảng trống std::unique_ptr<char[]>chiếm tới 8 byte, nghĩa là chính xác kích thước của con trỏ.

Nhược điểm lớn nhất là, mỗi khi tôi muốn biết độ dài của chuỗi, tôi phải gọi strlennó.

Để trả lời những người nghĩ rằng bạn "phải" sử dụng vectorthay vì unique_ptrtôi có một trường hợp trong lập trình CUDA trên GPU khi bạn phân bổ bộ nhớ trong Thiết bị, bạn phải tìm một mảng con trỏ (có cudaMalloc). Sau đó, khi lấy dữ liệu này trong Máy chủ, bạn phải quay lại một con trỏ và unique_ptrxử lý con trỏ dễ dàng. Chi phí chuyển đổi double*thêm vector<double>là không cần thiết và dẫn đến mất hoàn hảo.

Thêm một lý do để cho phép và sử dụng std::unique_ptr<T[]> , chưa được đề cập trong các phản hồi cho đến nay: nó cho phép bạn khai báo loại phần tử mảng.

Điều này rất hữu ích khi bạn muốn giảm thiểu chuỗi #include câu lệnh được trong các tiêu đề (để tối ưu hóa hiệu suất xây dựng.)

Ví dụ -

mygroup.h:

class ALargeAndComplicatedClassWithLotsOfDependencies;

class MyClass {
   ...
private:
   std::unique_ptr<ALargeAndComplicatedClassWithLotsOfDependencies[]> m_InternalArray;
};

mygroup.cpp:

#include "myclass.h"
#include "ALargeAndComplicatedClassWithLotsOfDependencies.h"

// MyClass implementation goes here

Với cấu trúc mã trên, bất kỳ ai cũng có thể #include "myclass.h"và sử dụng MyClassmà không cần phải bao gồm các phụ thuộc triển khai nội bộ được yêu cầu bởi MyClass::m_InternalArray.

m_InternalArrayThay vào đó, nếu được khai báo là a std::array<ALargeAndComplicatedClassWithLotsOfDependencies>, hoặc a std::vector<...>, tương ứng - kết quả sẽ được cố gắng sử dụng loại không hoàn chỉnh, đó là lỗi thời gian biên dịch.

Tôi không thể không đồng ý với tinh thần của câu trả lời được chấp nhận đủ mạnh. "Một công cụ cuối cùng"? Cách xa nó!

Theo cách tôi thấy, một trong những tính năng mạnh nhất của C ++ so với C và với một số ngôn ngữ tương tự khác là khả năng diễn đạt các ràng buộc để có thể kiểm tra chúng tại thời điểm biên dịch và có thể ngăn chặn việc lạm dụng ngẫu nhiên. Vì vậy, khi thiết kế một cấu trúc, hãy tự hỏi những gì nó nên cho phép hoạt động. Tất cả các mục đích sử dụng khác đều bị cấm và tốt nhất là nếu các hạn chế đó có thể được triển khai tĩnh (tại thời gian biên dịch) để việc sử dụng sai dẫn đến lỗi biên dịch.

Vì vậy, khi một người cần một mảng, các câu trả lời cho các câu hỏi sau chỉ định hành vi của nó: 1. Kích thước của nó là a) động khi chạy, hoặc b) tĩnh, nhưng chỉ được biết khi chạy, hoặc c) tĩnh và được biết tại thời gian biên dịch? 2. Mảng có thể được phân bổ trên ngăn xếp hay không?

Và dựa trên các câu trả lời, đây là cấu trúc dữ liệu tốt nhất cho một mảng như vậy:

       Dynamic     |   Runtime static   |         Static
Stack std::vector      unique_ptr<T[]>          std::array
Heap  std::vector      unique_ptr<T[]>     unique_ptr<std::array>

Đúng, tôi nghĩ unique_ptr<std::array>cũng nên được xem xét, và cũng không phải là một công cụ của phương sách cuối cùng. Chỉ cần nghĩ những gì phù hợp nhất với thuật toán của bạn.

Tất cả những thứ này tương thích với API C đơn giản thông qua con trỏ thô đến mảng dữ liệu ( vector.data()/ array.data()/ uniquePtr.get()).

PS Ngoài những cân nhắc ở trên, còn có một quyền sở hữu: std::arrayvà std::vectorcó ngữ nghĩa giá trị (có hỗ trợ riêng để sao chép và chuyển theo giá trị), trong khi unique_ptr<T[]>chỉ có thể được di chuyển (thực thi quyền sở hữu duy nhất). Hoặc là có thể hữu ích trong các kịch bản khác nhau. Ngược lại, mảng tĩnh đơn giản ( int[N]) và mảng động đơn giản ( new int[10]) không cung cấp và do đó nên tránh nếu có thể - điều này có thể xảy ra trong phần lớn các trường hợp. Nếu điều đó là không đủ, các mảng động đơn giản cũng không cung cấp cách nào để truy vấn kích thước của chúng - cơ hội bổ sung cho các lỗi bộ nhớ và lỗ hổng bảo mật.

Chúng có thể là câu trả lời đúng nhất có thể khi bạn chỉ chọc một con trỏ thông qua một API hiện có (nghĩ thông báo cửa sổ hoặc tham số gọi lại liên quan đến luồng) có một số đo thời gian sống sau khi bị "bắt" ở phía bên kia của nở, nhưng không liên quan đến mã gọi:

unique_ptr<byte[]> data = get_some_data();

threadpool->post_work([](void* param) { do_a_thing(unique_ptr<byte[]>((byte*)param)); },
                      data.release());

Tất cả chúng ta đều muốn mọi thứ tốt đẹp cho chúng ta. C ++ dành cho những lần khác.

unique_ptr<char[]>có thể được sử dụng ở nơi bạn muốn hiệu năng của C và sự tiện lợi của C ++. Hãy xem xét bạn cần phải hoạt động trên hàng triệu (ok, hàng tỷ nếu bạn chưa tin tưởng) chuỗi. Lưu trữ mỗi trong số chúng trong một đối tượng stringhoặc vector<char>đối tượng riêng biệt sẽ là một thảm họa cho các thói quen quản lý bộ nhớ (heap). Đặc biệt nếu bạn cần phân bổ và xóa các chuỗi khác nhau nhiều lần.

Tuy nhiên, bạn có thể phân bổ một bộ đệm duy nhất để lưu trữ nhiều chuỗi đó. Bạn sẽ không thích char* buffer = (char*)malloc(total_size);vì những lý do rõ ràng (nếu không rõ ràng, hãy tìm kiếm "tại sao sử dụng ptrs thông minh"). Bạn muốnunique_ptr<char[]> buffer(new char[total_size]);

Bằng cách tương tự, các cân nhắc về hiệu suất và sự thuận tiện tương tự áp dụng cho phi chardữ liệu (xem xét hàng triệu vectơ / ma trận / đối tượng).

• Bạn cần cấu trúc của mình để chỉ chứa một con trỏ vì lý do tương thích nhị phân.
• Bạn cần giao diện với API trả về bộ nhớ được phân bổ new[]
• Công ty hoặc dự án của bạn có một quy tắc chung chống lại việc sử dụng std::vector, ví dụ, để ngăn các lập trình viên bất cẩn vô tình giới thiệu các bản sao
• Bạn muốn ngăn các lập trình viên bất cẩn vô tình giới thiệu các bản sao trong trường hợp này.

Có một quy tắc chung là các thùng chứa C ++ sẽ được ưu tiên hơn so với việc sử dụng các con trỏ của riêng bạn với các con trỏ. Đó là một quy tắc chung; nó có ngoại lệ Còn nữa; đây chỉ là những ví dụ

Nếu bạn cần một mảng động của các đối tượng không thể sao chép được, thì một con trỏ thông minh đến một mảng là cách để đi. Ví dụ, nếu bạn cần một mảng nguyên tử.