Mẫu thiết kế tốt cho trình bao bọc c ++ xung quanh đối tượng ac

Tôi đã viết một trình bao bọc c ++ mở rộng xung quanh một thư viện c rất khó sử dụng nhưng cũng rất hữu ích. Mục tiêu là để có được sự kiên định của c ++ trong việc phân bổ đối tượng, phơi bày các thuộc tính của nó, giải phóng đối tượng, sao chép ngữ nghĩa, v.v ...

Vấn đề là ở đây: đôi khi thư viện c muốn đối tượng bên dưới (một con trỏ tới đối tượng) và hàm hủy lớp không được phá hủy bộ nhớ bên dưới. Trong khi hầu hết thời gian, hàm hủy nên phân bổ đối tượng bên dưới. Tôi đã thử nghiệm với việc thiết lập một bool hasOwnershipcờ trong lớp để hàm hủy, toán tử gán, v.v ... sẽ biết liệu nó có nên giải phóng bộ nhớ bên dưới hay không. Tuy nhiên, điều này là cồng kềnh cho người dùng, và đôi khi, không có cách nào để biết khi nào một quá trình khác sẽ sử dụng bộ nhớ đó.

Hiện tại, tôi đã thiết lập nó khi bài tập đến từ một con trỏ cùng loại với kiểu cơ bản, sau đó tôi đặt cờ hasOwnership. Tôi làm tương tự khi hàm tạo quá tải được gọi bằng cách sử dụng con trỏ từ thư viện c. Tuy nhiên, điều này vẫn không xử lý trường hợp khi người dùng đã tạo đối tượng và chuyển nó đến một trong các chức năng của tôi để gọi c_api và thư viện lưu trữ con trỏ để sử dụng sau. Nếu họ xóa đối tượng của mình, thì chắc chắn sẽ gây ra một segfault trong thư viện c.

Có một mẫu thiết kế sẽ đơn giản hóa quá trình này? Có lẽ một số loại tham khảo đếm?

Nếu trách nhiệm dọn dẹp các công cụ được phân bổ động thay đổi giữa lớp trình bao bọc của bạn và thư viện C dựa trên cách mọi thứ được sử dụng, thì bạn đang xử lý một thư viện C được thiết kế tồi hoặc bạn đang cố gắng làm quá nhiều trong lớp trình bao bọc của mình.

Trong trường hợp đầu tiên, tất cả những gì bạn có thể làm là theo dõi xem ai chịu trách nhiệm dọn dẹp và hy vọng không có lỗi nào xảy ra (bởi bạn hoặc bởi những người duy trì thư viện C).

Trong trường hợp thứ hai, bạn nên suy nghĩ lại về thiết kế trình bao bọc của bạn. Có phải tất cả các chức năng thuộc về cùng một lớp, hoặc nó có thể được chia thành nhiều lớp. Có lẽ thư viện C sử dụng một cái gì đó tương tự như mẫu thiết kế Facade và bạn nên giữ một cấu trúc tương tự trong trình bao bọc C ++ của mình.

Trong mọi trường hợp, ngay cả khi thư viện C chịu trách nhiệm dọn dẹp một số nội dung, không có gì sai khi giữ một tham chiếu / con trỏ đến nội dung đó. Bạn chỉ cần nhớ rằng bạn không chịu trách nhiệm làm sạch những gì con trỏ đề cập đến.

Thường thì bạn có thể sử dụng một mẫu như thế này:

class C {
public:
  void foo() {
    underlying_foo(handle.get());
  }

  void bar() {
    // transfers ownership
    underlying_bar(handle.release());
  }

  // use default copy/move constructor and assignment operator

private:
  struct deleter {
    void operator()(T* ptr) {
      deleter_fn(ptr);
    }
  };
  std::unique_ptr<T, deleter> handle;
};

Bằng cách sử dụng, releasebạn có thể chuyển quyền sở hữu một cách rõ ràng. Tuy nhiên điều này là khó hiểu và bạn nên tránh nó nếu có thể.

Hầu hết các thư viện C đều có vòng đời đối tượng giống như C ++ (cấp phát đối tượng, truy cập, hủy) để ánh xạ độc đáo lên mẫu C ++ mà không cần chuyển quyền sở hữu.

Nếu người dùng cần quyền sở hữu chung, họ nên sử dụng shared_ptrvới các lớp của bạn. Đừng cố gắng thực hiện bất kỳ quyền sở hữu chia sẻ bản thân.

Cập nhật: Nếu bạn muốn chuyển quyền sở hữu rõ ràng hơn, bạn có thể sử dụng vòng loại tham chiếu:

void bar() && { ... }

Sau đó, người dùng phải gọi các bargiá trị như thế này:

C o;
std::move(o).bar();  // transfer of ownership is explicit at call site

Có một câu trả lời thẳng thắn cho vấn đề của bạn, con trỏ thông minh. Bằng cách sử dụng một con trỏ thông minh để giữ bộ nhớ của thư viện C và thêm một tham chiếu khi con trỏ cũng ở trong thư viện (và thả tham chiếu khi thư viện C trở lại), sau đó bạn sẽ tự động giải phóng bộ nhớ khi số tham chiếu giảm xuống 0 (và chỉ sau đó)

Nếu thư viện có thể giải phóng mọi thứ trong nội bộ và các tình huống có thể xảy ra được ghi lại rõ ràng, thì tất cả những gì bạn có thể làm là đặt một lá cờ giống như bạn đang làm.