Thiết kế API thư viện C ++


12

Tôi đang tìm kiếm một tài nguyên tốt để tìm hiểu về thiết kế API tốt cho các thư viện C ++, xem các đối tượng / dll được chia sẻ, v.v. Có rất nhiều tài nguyên về cách viết API đẹp, các lớp đẹp, các mẫu, v.v. đặt mọi thứ lại với nhau trong libs chia sẻ và thực thi. Những cuốn sách như Thiết kế phần mềm C ++ quy mô lớn của John Lakos rất thú vị nhưng đã lỗi thời.

Những gì tôi đang tìm kiếm là lời khuyên tức là về việc xử lý các mẫu. Với các mẫu trong API của tôi, tôi thường kết thúc với mã thư viện trong tệp thực thi của mình (hoặc thư viện khác) vì vậy nếu tôi sửa một lỗi trong đó, tôi không thể đơn giản tung ra thư viện mới mà phải biên dịch lại và phân phối lại tất cả các máy khách của mã đó. (và vâng, tôi biết một số giải pháp như cố gắng khởi tạo ít nhất các phiên bản phổ biến nhất trong thư viện, v.v.)

Tôi cũng đang tìm kiếm sự cẩn thận khác và những điều cần lưu ý để giữ khả năng tương thích nhị phân trong khi làm việc trên các thư viện C ++.

Có một trang web hay cuốn sách về những điều như vậy?


Tôi đã xử lý nó theo cách này: sivut.koti.ton.fi/~terop/GameApi.html - tức là trong khi có các mẫu bên trong lib, không có mẫu nào trong api ...
tp1

1
std::unique_ptrlà thứ khá mới. Chính xác thì bạn nghĩ gì phù hợp hơn về API đề xuất của bạn? Cách mà bạn phải quản lý thủ công tất cả các tài nguyên, hầu như đảm bảo rò rỉ và xóa hai lần, chẳng hạn? Hoặc cách mà nhiều loại của bạn có một hoặc hai tên chữ cái, khiến cho mục đích của chúng không thể thực hiện được?
DeadMG

1
@ tp1: Nhưng bạn không quan tâm đến việc tôi đã xử lý chúng. Bạn chỉ cần nói "XỬ LÝ" mà không làm gì với nó. Tôi đã không xử lý chúng và bây giờ thì sao? Thay vì sử dụng một lớp RAII không cho phép những sai lầm như vậy. Nếu bạn đã sử dụng, unique_ptrnó sẽ không thể viết mã như vậy.
DeadMG

1
@ tp1: Tôi nhận thấy rằng Env có thể bị phá hủy. Nó khá là nhiều. Dường như không có bất kỳ chức năng nào để quản lý các đối tượng. Nếu tôi muốn quản lý bộ nhớ chi tiết hơn so với "Mọi thứ tôi từng tạo" hoặc "Không có gì", có vẻ như tôi đã bị lừa.
DeadMG

3
Vui lòng thực hiện bất kỳ cuộc hội thoại mở rộng nào để Trò chuyện Kỹ thuật phần mềm . Bất kỳ thông tin hữu ích có thể được kết hợp trong câu hỏi hoặc một câu trả lời?
ChrisF

Câu trả lời:


12

Thực tế có một cuốn sách chính xác là những gì bạn tìm kiếm. Đó là cuộc gọi, đủ thích hợp, Thiết kế API cho C ++. Trang web của cuốn sách có mã nguồn từ cuốn sách và Errata là tốt.


1
Xác định +1 cho cuốn sách! Tôi đến để đề nghị điều này nhưng hóa ra bạn đánh tôi với nó.
zxcdw

+1: Tôi đang đọc xong cuốn sách này và nó là một tài nguyên tuyệt vời. Rất khuyến khích.
Korchkidu

3

Điều này là khá nhiều không thể. Một thực tế đơn giản là đôi khi, bạn cần trình biên dịch để thực hiện một công việc và bạn không thể chỉ dùng phép thuật cần thiết. Không có chức năng nào có thể làm cho std::vectorkhông phải là một thư viện chỉ tiêu đề. Trình biên dịch có thể làm cho nhiều phép thuật hoạt động, nhưng bạn không thể có chúng mà không cần gọi nó, và đó là một thực tế của cuộc sống.

Đây là những gì bạn có thể làm: không sử dụng các mẫu mà bạn không cần chúng. Đây là những gì bạn không thể làm: bất cứ điều gì khác.

Một thực tế đơn giản là việc biên dịch lại với phiên bản mới thực sự không phải là một gánh nặng lớn so với những lợi thế về hiệu suất, an toàn và chức năng mà bạn có thể có được với các thư viện được gõ tĩnh.


2
Tôi đã đề cập rằng như một ví dụ để suy nghĩ về. những gì tôi đang tìm kiếm là hướng dẫn về các vấn đề tương tự khác mà tôi nên chuẩn bị và thực hành tốt nhất để xử lý những vấn đề đó.
johannes

Chà, nếu tất cả các phiên bản mới phá vỡ tính tương thích ABI được đưa vào một không gian tên nội tuyến mới, thì đó có phải là thư viện chỉ có tiêu đề hay không?
Ded repeatator
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.