Có phải std :: unique_ptr <T> để biết định nghĩa đầy đủ của T không?

Tôi có một số mã trong một tiêu đề trông như thế này:

#include <memory>

class Thing;

class MyClass
{
    std::unique_ptr< Thing > my_thing;
};

Nếu tôi bao gồm tiêu đề này trong một cpp không bao gồm Thingđịnh nghĩa loại, thì điều này không biên dịch theo VS2010-SP1:

1> C: \ Tệp chương trình (x86) \ Microsoft Visual Studio 10.0 \ VC \ include \ memory (2067): lỗi C2027: sử dụng loại không xác định 'Thing'

Thay thế std::unique_ptrbằng std::shared_ptrvà nó biên dịch.

Vì vậy, tôi đoán rằng đó std::unique_ptrlà triển khai hiện tại của VS2010 yêu cầu định nghĩa đầy đủ và hoàn toàn phụ thuộc vào triển khai.

Hoặc là nó? Có điều gì đó trong các yêu cầu tiêu chuẩn của nó khiến cho std::unique_ptrviệc triển khai không thể chỉ hoạt động với một tuyên bố chuyển tiếp không? Nó cảm thấy kỳ lạ vì nó chỉ nên giữ một con trỏ Thing, phải không?

Thông qua từ đây .

Hầu hết các mẫu trong thư viện chuẩn C ++ yêu cầu chúng phải được khởi tạo với các kiểu hoàn chỉnh. Tuy nhiên shared_ptrvà unique_ptrlà một phần ngoại lệ. Một số, nhưng không phải tất cả các thành viên của họ có thể được khởi tạo với các loại không đầy đủ. Động lực cho việc này là để hỗ trợ các thành ngữ như pimpl sử dụng con trỏ thông minh và không có nguy cơ hành vi không xác định.

Hành vi không xác định có thể xảy ra khi bạn có một loại không đầy đủ và bạn gọi deletenó:

class A;
A* a = ...;
delete a;

Trên đây là mã hợp pháp. Nó sẽ biên dịch. Trình biên dịch của bạn có thể hoặc không thể phát ra cảnh báo cho mã ở trên như ở trên. Khi nó thực thi, những điều xấu có thể sẽ xảy ra. Nếu bạn rất may mắn chương trình của bạn sẽ sụp đổ. Tuy nhiên, một kết quả có thể xảy ra hơn là chương trình của bạn sẽ âm thầm rò rỉ bộ nhớ như ~A()sẽ không được gọi.

Sử dụng auto_ptr<A>trong ví dụ trên không giúp được gì. Bạn vẫn nhận được hành vi không xác định giống như bạn đã sử dụng một con trỏ thô.

Tuy nhiên, sử dụng các lớp không đầy đủ ở một số nơi là rất hữu ích! Đây là nơi shared_ptrvà unique_ptrgiúp đỡ. Việc sử dụng một trong những con trỏ thông minh này sẽ cho phép bạn thoát khỏi một loại không hoàn chỉnh, trừ khi cần phải có một loại hoàn chỉnh. Và quan trọng nhất, khi cần phải có một loại hoàn chỉnh, bạn sẽ gặp lỗi thời gian biên dịch nếu bạn cố gắng sử dụng con trỏ thông minh với một loại không đầy đủ tại thời điểm đó.

Không còn hành vi không xác định:

Nếu mã của bạn biên dịch, thì bạn đã sử dụng một loại hoàn chỉnh ở mọi nơi bạn cần.

class A
{
    class impl;
    std::unique_ptr<impl> ptr_;  // ok!

public:
    A();
    ~A();
    // ...
};

shared_ptrvà unique_ptryêu cầu một loại hoàn chỉnh ở những nơi khác nhau. Những lý do rất mơ hồ, phải làm với một deleter động so với một deleter tĩnh. Những lý do chính xác không quan trọng. Trong thực tế, trong hầu hết các mã, điều thực sự không quan trọng đối với bạn để biết chính xác nơi cần một loại hoàn chỉnh. Chỉ cần mã, và nếu bạn nhận được nó sai, trình biên dịch sẽ cho bạn biết.

Tuy nhiên, trong trường hợp nó hữu ích cho bạn, đây là bảng ghi lại một số thành viên shared_ptrvà unique_ptrliên quan đến các yêu cầu về tính đầy đủ. Nếu thành viên yêu cầu một loại hoàn chỉnh, thì mục nhập có "C", nếu không, mục nhập bảng được điền "I".

Complete type requirements for unique_ptr and shared_ptr

                            unique_ptr       shared_ptr
+------------------------+---------------+---------------+
|          P()           |      I        |      I        |
|  default constructor   |               |               |
+------------------------+---------------+---------------+
|      P(const P&)       |     N/A       |      I        |
|    copy constructor    |               |               |
+------------------------+---------------+---------------+
|         P(P&&)         |      I        |      I        |
|    move constructor    |               |               |
+------------------------+---------------+---------------+
|         ~P()           |      C        |      I        |
|       destructor       |               |               |
+------------------------+---------------+---------------+
|         P(A*)          |      I        |      C        |
+------------------------+---------------+---------------+
|  operator=(const P&)   |     N/A       |      I        |
|    copy assignment     |               |               |
+------------------------+---------------+---------------+
|    operator=(P&&)      |      C        |      I        |
|    move assignment     |               |               |
+------------------------+---------------+---------------+
|        reset()         |      C        |      I        |
+------------------------+---------------+---------------+
|       reset(A*)        |      C        |      C        |
+------------------------+---------------+---------------+

Bất kỳ hoạt động nào yêu cầu chuyển đổi con trỏ đều yêu cầu các loại hoàn chỉnh cho cả hai unique_ptrvà shared_ptr.

Hàm unique_ptr<A>{A*}tạo có thể thoát khỏi chỉ với phần chưa hoàn thành Anếu trình biên dịch không bắt buộc phải thiết lập lệnh gọi đến ~unique_ptr<A>(). Ví dụ, nếu bạn đặt unique_ptrheap, bạn có thể thoát khỏi một cách không đầy đủ A. Thông tin chi tiết về điểm này có thể được tìm thấy trong câu trả lời của BarryTheHatchet tại đây .

Trình biên dịch cần định nghĩa của Thing để tạo hàm hủy mặc định cho MyClass. Nếu bạn khai báo rõ ràng hàm hủy và di chuyển triển khai (trống) của nó sang tệp CPP, mã sẽ biên dịch.

Điều này không phụ thuộc vào việc thực hiện. Lý do nó hoạt động là vì shared_ptrxác định hàm hủy chính xác để gọi trong thời gian chạy - nó không phải là một phần của chữ ký loại. Tuy nhiên, hàm unique_ptrhủy là một phần của kiểu của nó và nó phải được biết tại thời điểm biên dịch.

Có vẻ như các câu trả lời hiện tại không chính xác tại sao hàm tạo (hoặc hàm hủy) mặc định là vấn đề nhưng các câu trả lời trống được khai báo trong cpp thì không.

Đây là những gì đang xảy ra:

Nếu lớp bên ngoài (ví dụ MyClass) không có hàm tạo hoặc hàm hủy thì trình biên dịch sẽ tạo các lớp mặc định. Vấn đề với điều này là về cơ bản trình biên dịch sẽ chèn hàm tạo / hàm hủy mặc định trong tệp .hpp. Điều này có nghĩa là mã cho bộ điều khiển / bộ hủy mặc định được biên dịch cùng với nhị phân của máy chủ thực thi, không cùng với các nhị phân của thư viện của bạn. Tuy nhiên định nghĩa này không thể thực sự xây dựng các lớp một phần. Vì vậy, khi trình liên kết đi vào nhị phân của thư viện của bạn và cố gắng lấy hàm tạo / hàm hủy, nó không tìm thấy bất kỳ và bạn gặp lỗi. Nếu mã xây dựng / mã hủy nằm trong .cpp của bạn thì tệp nhị phân thư viện của bạn có sẵn để liên kết.

Điều này không liên quan gì đến việc sử dụng unique_ptr hoặc shared_ptr và các câu trả lời khác dường như có thể là lỗi khó hiểu trong VC ++ cũ để triển khai unique_ptr (VC ++ 2015 hoạt động tốt trên máy của tôi).

Vì vậy, đạo đức của câu chuyện là tiêu đề của bạn cần không có bất kỳ định nghĩa hàm tạo / hàm hủy. Nó chỉ có thể chứa tuyên bố của họ. Ví dụ, ~MyClass()=default;trong hpp sẽ không hoạt động. Nếu bạn cho phép trình biên dịch chèn hàm tạo hoặc hàm hủy mặc định, bạn sẽ gặp lỗi liên kết.

Một lưu ý khác: Nếu bạn vẫn gặp lỗi này ngay cả sau khi bạn có hàm tạo và hàm hủy trong tệp cpp thì rất có thể lý do là thư viện của bạn không được biên dịch đúng. Ví dụ, một lần tôi chỉ đơn giản thay đổi loại dự án từ Bảng điều khiển sang Thư viện trong VC ++ và tôi đã gặp lỗi này vì VC ++ không thêm ký hiệu tiền xử lý _LIB và điều đó tạo ra chính xác thông báo lỗi.

Chỉ để hoàn thiện:

Tiêu đề: À

class B; // forward declaration

class A
{
    std::unique_ptr<B> ptr_;  // ok!  
public:
    A();
    ~A();
    // ...
};

Nguồn A.cpp:

class B {  ...  }; // class definition

A::A() { ... }
A::~A() { ... }

Định nghĩa của lớp B phải được xem bởi hàm tạo, hàm hủy và bất cứ thứ gì có thể xóa hoàn toàn B. (Mặc dù hàm tạo không xuất hiện trong danh sách trên, trong VS2017, ngay cả hàm tạo cũng cần định nghĩa của B. Và điều này có ý nghĩa khi xem xét trong trường hợp có ngoại lệ trong hàm tạo, unique_ptr lại bị hủy.)

Định nghĩa đầy đủ của Điều được yêu cầu tại điểm khởi tạo mẫu. Đây là lý do chính xác tại sao thành ngữ pimpl biên dịch.

Nếu không thể, mọi người sẽ không hỏi những câu như thế này .

Câu trả lời đơn giản là chỉ sử dụng shared_ptr thay thế.

Đôi vơi tôi,

QList<QSharedPointer<ControllerBase>> controllers;

Chỉ cần bao gồm tiêu đề ...

#include <QSharedPointer>