Thiết kế API C: Ai nên phân bổ?

Question

Cách thích hợp/ưu tiên để cấp phát bộ nhớ trong API C là gì?

tôi có thể thấy, lúc đầu, hai lựa chọn:

1) Hãy để cho người gọi làm tất cả những (bên ngoài xử lý bộ nhớ):

myStruct *s = malloc(sizeof(s)); 
myStruct_init(s); 

myStruct_foo(s); 

myStruct_destroy(s); 
free(s); 

Các _init và _destroy chức năng là cần thiết vì một số bộ nhớ hơn có thể được phân bổ bên trong, và nó phải được xử lý ở đâu đó.

này có những bất lợi của việc lâu hơn, mà còn là malloc thể được loại bỏ trong một số trường hợp (ví dụ, nó có thể được thông qua một cấu trúc ngăn xếp phân bổ:

int bar() { 
    myStruct s; 
    myStruct_init(&s); 

    myStruct_foo(&s); 

    myStruct_destroy(&s); 
} 

Ngoài ra, nó là cần thiết cho người gọi đến biết kích thước của cấu trúc.

2) Ẩn malloc s trong _init và free s trong _destroy.

Ưu điểm: mã ngắn hơn, vì các hàm sẽ được gọi. Cấu trúc hoàn toàn mờ đục.

Nhược điểm: Không thể chuyển giao cấu trúc được phân bổ theo cách khác.

myStruct *s = myStruct_init(); 

myStruct_foo(s); 

myStruct_destroy(foo); 

Tôi hiện đang nghiêng về trường hợp đầu tiên; sau đó một lần nữa, tôi không biết về thiết kế C API.

Answer 1

Ví dụ yêu thích của tôi về API C thiết kế đẹp là GTK+ sử dụng phương pháp # 2 mà bạn mô tả.

Mặc dù lợi thế khác của phương pháp # 1 không chỉ là bạn có thể phân bổ đối tượng trên ngăn xếp, mà còn có thể sử dụng lại cùng một phiên bản nhiều lần. Nếu đó không phải là một trường hợp sử dụng phổ biến, thì sự đơn giản của # 2 có lẽ là một lợi thế.

Tất nhiên, đó chỉ là ý kiến ​​của tôi :)

Answer 2

Cả hai đều được chấp nhận - có sự cân bằng giữa chúng, như bạn đã lưu ý.

Có các ví dụ thực tế lớn về cả hai - như Dean Harding cho biết, GTK + sử dụng phương pháp thứ hai; OpenSSL là một ví dụ sử dụng đầu tiên.

Answer 3

Một bất lợi khác của số 2 là người gọi không có quyền kiểm soát cách mọi thứ được phân bổ. Điều này có thể được làm việc xung quanh bằng cách cung cấp một API cho khách hàng để đăng ký các chức năng phân bổ/deallocation của riêng mình (như SDL), nhưng thậm chí có thể không đủ chi tiết.

Điểm bất lợi của số 1 là nó không hoạt động tốt khi bộ đệm đầu ra không cố định (ví dụ: chuỗi). Tốt nhất, sau đó bạn sẽ cần phải cung cấp một chức năng khác để có được chiều dài của bộ đệm đầu tiên để người gọi có thể phân bổ nó. Tệ nhất, nó chỉ đơn giản là không thể làm như vậy hiệu quả (tức là chiều dài máy tính trên một con đường riêng biệt là quá đắt so với tính toán và sao chép trong một lần).

Lợi thế của số 2 là nó cho phép bạn hiển thị kiểu dữ liệu của bạn đúng như một con trỏ mờ (tức là khai báo cấu trúc nhưng không xác định cấu trúc và sử dụng con trỏ một cách nhất quán).Sau đó, bạn có thể thay đổi định nghĩa của cấu trúc như bạn thấy phù hợp trong các phiên bản tương lai của thư viện của bạn, trong khi khách hàng vẫn tương thích ở cấp nhị phân. Với # 1, bạn phải làm điều đó bằng cách yêu cầu máy khách chỉ định phiên bản bên trong struct theo một cách nào đó (ví dụ: tất cả các trường cbSize trong Win32 API), và sau đó viết mã thủ công có thể xử lý cả phiên bản cũ và mới hơn của cấu trúc duy trì tương thích nhị phân khi thư viện của bạn phát triển.

Nói chung, nếu cấu trúc của bạn là dữ liệu trong suốt sẽ không thay đổi với bản sửa đổi nhỏ trong tương lai của thư viện, tôi sẽ đi với # 1. Nếu nó là một đối tượng dữ liệu phức tạp hơn hoặc ít hơn và bạn muốn đóng gói đầy đủ để đánh lừa nó để phát triển trong tương lai, hãy đi với # 2.

Answer 4

Cả hai đều có chức năng tương đương. Tuy nhiên, theo ý kiến ​​của tôi, phương pháp # 2 dễ sử dụng hơn. Một vài lý do cho việc thích 2 trên 1 là:

1. Điều này trực quan hơn. Tại sao tôi phải gọi free trên đối tượng sau khi tôi (rõ ràng) đã phá hủy nó bằng cách sử dụng myStruct_Destroy.

2. Ẩn chi tiết của myStruct từ người dùng. Anh ta không phải lo lắng về kích thước của nó, v.v.

3. Trong phương pháp # 2, myStruct_init không phải lo lắng về trạng thái ban đầu của đối tượng.

4. Bạn không phải lo lắng về rò rỉ bộ nhớ từ người dùng quên gọi free.

Tuy nhiên, phương pháp triển khai API của bạn đang được gửi đi như một thư viện chia sẻ riêng biệt. Để cô lập mô-đun của bạn khỏi bất kỳ sự không khớp nào trong việc triển khai các phiên bản malloc/new và free/delete trên các phiên bản trình biên dịch, bạn nên giữ phân bổ bộ nhớ và phân bổ lại cho chính mình. Lưu ý, điều này đúng hơn với C++ so với C.

Answer 5

Vấn đề tôi có với phương pháp đầu tiên không quá nhiều vì nó dài hơn đối với người gọi, đó là api hiện bị còng tay khi có thể mở rộng số tiền bộ nhớ nó đang sử dụng chính xác bởi vì nó không biết bộ nhớ mà nó nhận được được phân bổ như thế nào. Người gọi không phải lúc nào cũng biết trước bao nhiêu bộ nhớ nó sẽ cần (hãy tưởng tượng nếu bạn đang cố gắng thực hiện một vectơ).

Một tùy chọn khác mà bạn không đề cập đến, điều này sẽ vượt quá phần lớn thời gian, là chuyển một con trỏ hàm mà api sử dụng làm cấp phát. Điều này không cho phép bạn sử dụng ngăn xếp, nhưng cho phép bạn làm điều gì đó như thay thế việc sử dụng malloc với một nhóm bộ nhớ, mà vẫn giữ api kiểm soát khi nào nó muốn phân bổ.

Đối với phương pháp nào là thiết kế api phù hợp, nó được thực hiện theo cả hai cách trong thư viện chuẩn C. strdup() và stdio sử dụng phương thức thứ hai trong khi sprintf và strcat sử dụng phương thức đầu tiên. Cá nhân tôi thích phương pháp thứ hai (hoặc thứ ba) trừ khi 1) Tôi biết tôi sẽ không bao giờ cần realloc và 2) Tôi mong đợi tuổi thọ của các đối tượng của tôi là ngắn và do đó sử dụng ngăn xếp là rất convienent

chỉnh sửa: Có thực sự là 1 tùy chọn khác và đó là một tùy chọn tồi tệ với tiền lệ nổi bật. Bạn có thể làm điều đó theo cách strtok() hiện nó với statics. Không tốt, chỉ đề cập đến vì lợi ích đầy đủ.

Answer 6

Cả hai cách đều ổn, tôi có xu hướng thực hiện theo cách đầu tiên như nhiều C tôi làm cho các hệ thống nhúng và tất cả bộ nhớ là các biến nhỏ trên ngăn xếp hoặc phân bổ tĩnh.Bằng cách này có thể không có hết bộ nhớ, hoặc bạn có đủ lúc đầu hoặc bạn đang hơi say từ đầu. Tốt để biết khi bạn có 2K Ram :-) Vì vậy, tất cả các thư viện của tôi giống như # 1 nơi bộ nhớ được giả định được phân bổ.

Nhưng đây là trường hợp cạnh của phát triển C.

Có nói rằng, tôi chắc chắn sẽ đi với # 1 vẫn còn. Có lẽ sử dụng init và finalize/dispose (thay vì phá hủy) cho tên.

Answer 7

Điều đó có thể đưa ra một số yếu tố phản xạ:

trường hợp # 1 mimick chương trình cấp phát bộ nhớ của C++, với ít nhiều lợi ích tương tự:

• phân bổ dễ dàng là tạm thời trên stack (hoặc trong mảng tĩnh hoặc như vậy để viết bạn phân bổ struct riêng thay thế malloc).
• dễ dàng miễn phí bộ nhớ nếu bất cứ điều gì đi sai trong init

trường hợp # 2 ẩn biết thêm thông tin về cơ cấu sử dụng và cũng có thể được sử dụng cho các cấu trúc đục, thường khi cấu trúc theo cách nhìn của người sử dụng không phải là chính xác giống như được sử dụng nội bộ bởi lib (nói rằng có thể có thêm một số trường ẩn ở cuối cấu trúc).

API hỗn hợp giữa trường hợp # 1 và trường hợp 2 cũng phổ biến: có trường được sử dụng để truyền con trỏ tới cấu trúc đã được khởi tạo, nếu nó được phân bổ (và con trỏ luôn được trả về). Với API như vậy, miễn phí thường là trách nhiệm của người gọi ngay cả khi init thực hiện phân bổ.

Trong hầu hết các trường hợp, có thể tôi sẽ tìm trường hợp số 1.

Answer 8

Tại sao không cung cấp cả hai, để tận dụng tối đa cả hai thế giới?

Sử dụng hàm _init và _terminate để sử dụng phương pháp # 1 (hoặc bất kỳ tên nào bạn thấy phù hợp).

Sử dụng các hàm _create và _destroy bổ sung cho phân bổ động. Kể từ _init và _terminate đã tồn tại, nó có hiệu quả boils xuống:

myStruct *myStruct_create() 
{ 
    myStruct *s = malloc(sizeof(*s)); 
    if (s) 
    { 
     myStruct_init(s); 
    } 
    return (s); 
} 

void myStruct_destroy (myStruct *s) 
{ 
    myStruct_terminate(s); 
    free(s); 
} 

Nếu bạn muốn nó được đục, sau đó hãy _init và _terminate static và không tiếp xúc với họ trong API, chỉ cung cấp _create và _destroy. Nếu bạn cần phân bổ khác, ví dụ: với một cuộc gọi lại cụ thể, cung cấp một tập hợp các hàm khác cho điều này, ví dụ: _createcalled, _destroycalled.

Điều quan trọng là theo dõi phân bổ, nhưng bạn vẫn phải thực hiện việc này. Bạn phải luôn luôn sử dụng các đối tác của phân bổ được sử dụng cho deallocation.

Answer 9

Tôi sẽ đi cho (1) với một phần mở rộng đơn giản, đó là để có chức năng _init của bạn luôn trả về con trỏ đến đối tượng. Khởi tạo con trỏ của bạn sau đó có thể chỉ đọc:

myStruct *s = myStruct_init(malloc(sizeof(myStruct))); 

Như bạn có thể thấy phía bên tay phải, chỉ có tham chiếu đến loại và không còn biến nữa.Một macro đơn giản sau đó cung cấp cho bạn (2) ít nhất một phần

#define NEW(T) (T ## _init(malloc(sizeof(T)))) 

và khởi tạo con trỏ của bạn đọc

myStruct *s = NEW(myStruct); 

Answer 10

Phương pháp số 2 mỗi lần.

Tại sao? bởi vì với phương pháp số 1 bạn phải rò rỉ chi tiết triển khai cho người gọi. Người gọi phải biết ít nhất cấu trúc lớn đến mức nào. Bạn không thể thay đổi việc thực hiện nội bộ của đối tượng mà không biên dịch lại bất kỳ mã nào sử dụng nó.

Answer 11

Xem phương pháp của bạn # 2 nói

myStruct *s = myStruct_init(); 

myStruct_foo(s); 

myStruct_destroy(s); 

Bây giờ xem nếu myStruct_init() nhu cầu quay trở lại một số mã lỗi vì lý do khác nhau sau đó cho phép đi theo con đường này.

myStruct *s; 
int ret = myStruct_init(&s); // int myStruct_init(myStruct **s); 

myStruct_foo(s); 

myStruct_destroy(s);