Khi tạo thư viện lớp trong C ++, bạn có thể chọn giữa thư viện động ( .dll, .so) và tĩnh ( .lib, .a). Sự khác biệt giữa chúng là gì và khi nào thì thích hợp để sử dụng cái nào?
Câu trả lời:
Thư viện tĩnh tăng kích thước mã trong nhị phân của bạn. Chúng luôn được tải và bất kỳ phiên bản mã nào bạn biên dịch là phiên bản mã sẽ chạy.
Thư viện động được lưu trữ và phiên bản riêng. Có thể tải phiên bản của thư viện động không phải là phiên bản gốc được gửi cùng với mã của bạn nếu bản cập nhật được coi là tương thích nhị phân với phiên bản gốc.
Ngoài ra, các thư viện động không nhất thiết phải được tải - chúng thường được tải khi được gọi lần đầu tiên - và có thể được chia sẻ giữa các thành phần sử dụng cùng một thư viện (tải nhiều dữ liệu, tải một mã).
Các thư viện động được coi là cách tiếp cận tốt hơn hầu hết thời gian, nhưng ban đầu chúng có một lỗ hổng lớn (google DLL hell), tất cả đã bị loại bỏ bởi các HĐH Windows gần đây (đặc biệt là Windows XP).
Những người khác đã giải thích thỏa đáng thư viện tĩnh là gì, nhưng tôi muốn chỉ ra một số lưu ý khi sử dụng thư viện tĩnh, ít nhất là trên Windows:
Singletons: Nếu một cái gì đó cần phải toàn cầu / tĩnh và duy nhất, hãy cẩn thận về việc đưa nó vào một thư viện tĩnh. Nếu nhiều DLL được liên kết với thư viện tĩnh đó, mỗi tệp sẽ nhận được bản sao riêng của singleton. Tuy nhiên, nếu ứng dụng của bạn là một EXE duy nhất không có DLL tùy chỉnh, điều này có thể không thành vấn đề.
Loại bỏ mã không được ước tính: Khi bạn liên kết với thư viện tĩnh, chỉ các phần của thư viện tĩnh được tham chiếu bởi DLL / EXE của bạn sẽ được liên kết vào DLL / EXE của bạn.
Ví dụ: nếu mylib.libchứa a.objvà b.objvà DLL / EXE của bạn chỉ tham chiếu các hàm hoặc biến từ a.obj, toàn bộ b.objsẽ bị loại bỏ bởi trình liên kết. Nếu b.objchứa các đối tượng toàn cục / tĩnh, các hàm tạo và hàm hủy của chúng sẽ không được thực thi. Nếu những người xây dựng / phá hủy có tác dụng phụ, bạn có thể thất vọng vì sự vắng mặt của họ.
Tương tự như vậy, nếu thư viện tĩnh chứa các điểm vào đặc biệt, bạn có thể cần phải quan tâm rằng chúng thực sự được bao gồm. Một ví dụ về điều này trong lập trình nhúng (được chứ không phải Windows) sẽ là một trình xử lý ngắt được đánh dấu là ở một địa chỉ cụ thể. Bạn cũng cần đánh dấu trình xử lý ngắt là điểm vào để đảm bảo nó không bị loại bỏ.
Một hậu quả khác của việc này là một thư viện tĩnh có thể chứa các tệp đối tượng hoàn toàn không sử dụng được do các tham chiếu chưa được giải quyết, nhưng nó sẽ không gây ra lỗi liên kết cho đến khi bạn tham chiếu một hàm hoặc biến từ các tệp đối tượng đó. Điều này có thể xảy ra lâu sau khi thư viện được viết.
Các biểu tượng gỡ lỗi: Bạn có thể muốn có một PDB riêng cho mỗi thư viện tĩnh hoặc bạn có thể muốn các biểu tượng gỡ lỗi được đặt trong các tệp đối tượng để chúng được đưa vào PDB cho DLL / EXE. Tài liệu Visual C ++ giải thích các tùy chọn cần thiết .
RTTI: Bạn có thể kết thúc với nhiều type_infođối tượng cho cùng một lớp nếu bạn liên kết một thư viện tĩnh duy nhất thành nhiều DLL. Nếu chương trình của bạn giả định rằng đó type_infolà dữ liệu "đơn lẻ" và sử dụng &typeid()hoặc type_info::before(), bạn có thể nhận được kết quả không mong muốn và đáng ngạc nhiên.
Một lib là một đơn vị mã được gói trong ứng dụng của bạn.
Một dll là một đơn vị độc lập của mã thực thi. Nó chỉ được tải trong quá trình khi một cuộc gọi được thực hiện trong mã đó. Một dll có thể được sử dụng bởi nhiều ứng dụng và được tải trong nhiều quy trình, trong khi vẫn chỉ có một bản sao của mã trên ổ cứng.
Ưu điểm của DLL : có thể được sử dụng để tái sử dụng / chia sẻ mã giữa một số sản phẩm; tải trong bộ nhớ quá trình theo yêu cầu và có thể được tải khi không cần thiết; có thể được nâng cấp độc lập với phần còn lại của chương trình.
Nhược điểm của DLL : tác động hiệu suất của việc tải dll và khởi động lại mã; vấn đề về phiên bản ("dll hell")
Lib thuận : không có tác động hiệu suất vì mã luôn được tải trong quá trình và không bị từ chối; không có vấn đề về phiên bản.
Nhược điểm của Lib : thực thi / xử lý "phình to" - tất cả các mã nằm trong tệp thực thi của bạn và được tải khi bắt đầu quá trình; không sử dụng lại / chia sẻ - mỗi sản phẩm có bản sao mã riêng.
Bên cạnh ý nghĩa kỹ thuật của thư viện tĩnh so với thư viện động (tệp tĩnh đóng gói mọi thứ trong một thư viện nhị phân lớn so với thư viện động cho phép chia sẻ mã giữa một số tệp thực thi khác nhau), còn có ý nghĩa pháp lý .
Ví dụ: nếu bạn đang sử dụng mã được cấp phép LGPL và bạn liên kết tĩnh với thư viện LGPL (và do đó tạo một nhị phân lớn), mã của bạn sẽ tự động trở thành Mã nguồn mở ( miễn phí như tự do) . Nếu bạn liên kết với các đối tượng được chia sẻ, thì bạn chỉ cần LGPL các cải tiến / sửa lỗi mà bạn thực hiện cho chính thư viện LGPL.
Điều này trở thành một vấn đề quan trọng hơn nhiều nếu bạn quyết định cách biên dịch các ứng dụng di động chẳng hạn (trong Android bạn có lựa chọn tĩnh so với động, trong iOS bạn không - nó luôn tĩnh).
Các chương trình C ++ được xây dựng theo hai giai đoạn
Thư viện tĩnh (.lib) chỉ là một gói các tệp .obj và do đó không phải là một chương trình hoàn chỉnh. Nó đã không trải qua giai đoạn thứ hai (liên kết) để xây dựng một chương trình. Mặt khác, các DLL giống như exe và do đó là các chương trình hoàn chỉnh.
Nếu bạn xây dựng thư viện tĩnh, nó chưa được liên kết và do đó người tiêu dùng của thư viện tĩnh của bạn sẽ phải sử dụng cùng trình biên dịch mà bạn đã sử dụng (nếu bạn sử dụng g ++, họ sẽ phải sử dụng g ++).
Thay vào đó, nếu bạn xây dựng một dll (và xây dựng nó một cách chính xác ), bạn đã xây dựng một chương trình hoàn chỉnh mà tất cả người tiêu dùng có thể sử dụng, bất kể họ đang sử dụng trình biên dịch nào. Tuy nhiên, có một số hạn chế khi xuất từ dll, nếu muốn tương thích trình biên dịch chéo.
consumers of your static library will have to use the same compiler that you usednếu thư viện tĩnh sử dụng thư viện C ++, chẳng hạn như #include <iostream>.
$$:~/static [32]> cat foo.c
#include<stdio.h>
void foo()
{
printf("\nhello world\n");
}
$$:~/static [33]> cat foo.h
#ifndef _H_FOO_H
#define _H_FOO_H
void foo();
#endif
$$:~/static [34]> cat foo2.c
#include<stdio.h>
void foo2()
{
printf("\nworld\n");
}
$$:~/static [35]> cat foo2.h
#ifndef _H_FOO2_H
#define _H_FOO2_H
void foo2();
#endif
$$:~/static [36]> cat hello.c
#include<foo.h>
#include<foo2.h>
void main()
{
foo();
foo2();
}
$$:~/static [37]> cat makefile
hello: hello.o libtest.a
cc -o hello hello.o -L. -ltest
hello.o: hello.c
cc -c hello.c -I`pwd`
libtest.a:foo.o foo2.o
ar cr libtest.a foo.o foo2.o
foo.o:foo.c
cc -c foo.c
foo2.o:foo.c
cc -c foo2.c
clean:
rm -f foo.o foo2.o libtest.a hello.o
$$:~/static [38]>$$:~/dynamic [44]> cat foo.c
#include<stdio.h>
void foo()
{
printf("\nhello world\n");
}
$$:~/dynamic [45]> cat foo.h
#ifndef _H_FOO_H
#define _H_FOO_H
void foo();
#endif
$$:~/dynamic [46]> cat foo2.c
#include<stdio.h>
void foo2()
{
printf("\nworld\n");
}
$$:~/dynamic [47]> cat foo2.h
#ifndef _H_FOO2_H
#define _H_FOO2_H
void foo2();
#endif
$$:~/dynamic [48]> cat hello.c
#include<foo.h>
#include<foo2.h>
void main()
{
foo();
foo2();
}
$$:~/dynamic [49]> cat makefile
hello:hello.o libtest.sl
cc -o hello hello.o -L`pwd` -ltest
hello.o:
cc -c -b hello.c -I`pwd`
libtest.sl:foo.o foo2.o
cc -G -b -o libtest.sl foo.o foo2.o
foo.o:foo.c
cc -c -b foo.c
foo2.o:foo.c
cc -c -b foo2.c
clean:
rm -f libtest.sl foo.o foo
2.o hello.o
$$:~/dynamic [50]>Một thư viện tĩnh được biên dịch vào máy khách. Một .lib được sử dụng tại thời gian biên dịch và nội dung của thư viện trở thành một phần của việc thực thi tiêu thụ.
Một thư viện động được tải trong thời gian chạy và không được biên dịch vào tệp thực thi của máy khách. Các thư viện động linh hoạt hơn vì nhiều tệp thực thi của máy khách có thể tải DLL và sử dụng chức năng của nó. Điều này cũng giữ cho kích thước tổng thể và khả năng duy trì của mã khách hàng của bạn ở mức tối thiểu.
Bạn nên suy nghĩ cẩn thận về những thay đổi theo thời gian, phiên bản, tính ổn định, khả năng tương thích, v.v.
Nếu có hai ứng dụng sử dụng mã được chia sẻ, bạn có muốn buộc các ứng dụng đó thay đổi cùng nhau không, trong trường hợp chúng cần tương thích với nhau? Sau đó sử dụng dll. Tất cả các exe sẽ được sử dụng cùng một mã.
Hoặc bạn muốn cách ly chúng với nhau, để bạn có thể thay đổi cái này và tự tin rằng bạn đã không phá vỡ cái kia. Sau đó sử dụng lib tĩnh.
DLL địa ngục là khi bạn có thể NÊN sử dụng lib tĩnh, nhưng thay vào đó bạn đã sử dụng một dll, và không phải tất cả các exes đều có thể kết hợp với nó.
Một thư viện tĩnh phải được liên kết vào tệp thực thi cuối cùng; nó trở thành một phần của thực thi và đi theo nó bất cứ nơi nào nó đi. Một thư viện động được tải mỗi khi tệp thực thi được thực thi và tách biệt với tệp thực thi dưới dạng tệp DLL.
Bạn sẽ sử dụng DLL khi bạn muốn có thể thay đổi chức năng do thư viện cung cấp mà không phải liên kết lại tệp thực thi (chỉ cần thay thế tệp DLL, mà không phải thay thế tệp thực thi).
Bạn sẽ sử dụng thư viện tĩnh bất cứ khi nào bạn không có lý do để sử dụng thư viện động.
Bài viết của Ulrich Drepper về " Cách viết thư viện chia sẻ " cũng là tài nguyên tốt, chi tiết cách tận dụng tốt nhất các thư viện dùng chung hoặc cái mà anh ta gọi là "Đối tượng chia sẻ động" (DSOs). Nó tập trung nhiều hơn vào các thư viện được chia sẻ ở định dạng nhị phân ELF , nhưng một số cuộc thảo luận cũng phù hợp với Windows DLL.
Đối với một cuộc thảo luận tuyệt vời về chủ đề này, hãy đọc bài viết này từ Sun.
Nó đi vào tất cả các lợi ích bao gồm có thể chèn các thư viện xen kẽ. Chi tiết hơn về can thiệp có thể được tìm thấy trong bài viết này ở đây .
Thực sự sự đánh đổi mà bạn đang thực hiện (trong một dự án lớn) đang trong thời gian tải ban đầu, các thư viện sẽ được liên kết lúc này hay lúc khác, quyết định phải đưa ra là liên kết sẽ đủ lâu để trình biên dịch cần cắn viên đạn và làm nó lên phía trước, hoặc trình liên kết động có thể làm điều đó khi tải.
Nếu thư viện của bạn sẽ được chia sẻ giữa một số tệp thực thi, thường có ý nghĩa làm cho nó động để giảm kích thước của các tệp thực thi. Nếu không, chắc chắn làm cho nó tĩnh.
Có một số nhược điểm của việc sử dụng một dll. Có thêm chi phí để tải và dỡ nó. Ngoài ra còn có một phụ thuộc bổ sung. Nếu bạn thay đổi dll để làm cho nó không tương thích với các tệp thực thi của bạn, chúng sẽ ngừng hoạt động. Mặt khác, nếu bạn thay đổi thư viện tĩnh, các tệp thực thi được biên dịch của bạn bằng phiên bản cũ sẽ không bị ảnh hưởng.
Nếu thư viện là tĩnh, thì tại thời điểm liên kết, mã được liên kết với tệp thực thi của bạn. Điều này làm cho khả năng thực thi của bạn lớn hơn (so với khi bạn đi theo tuyến đường động).
Nếu thư viện là động thì tại thời điểm liên kết tham chiếu đến các phương thức cần thiết được tích hợp vào tệp thực thi của bạn. Điều này có nghĩa là bạn phải gửi thư thực thi của bạn và thư viện động. Bạn cũng nên xem xét liệu quyền truy cập được chia sẻ vào mã trong thư viện có an toàn không, địa chỉ tải ưu tiên trong số các nội dung khác.
Nếu bạn có thể sống với thư viện tĩnh, hãy đi với thư viện tĩnh.
Chúng tôi sử dụng rất nhiều DLL (> 100) trong dự án của chúng tôi. Các DLL này có sự phụ thuộc lẫn nhau và do đó chúng tôi đã chọn thiết lập liên kết động. Tuy nhiên, nó có những nhược điểm sau:
Có lẽ một thiết lập tốt hơn là làm cho mọi thứ trở thành một thư viện tĩnh (và do đó bạn chỉ cần có một tệp thực thi). Điều này chỉ hoạt động nếu không có sự sao chép mã. Một thử nghiệm dường như ủng hộ giả định này, nhưng tôi không thể tìm thấy một trích dẫn chính thức của MSDN. Vì vậy, ví dụ tạo 1 exe với:
Mã và các biến của shared_lib2 phải có mặt trong tệp thực thi được hợp nhất cuối cùng chỉ một lần. Bất cứ ai có thể hỗ trợ câu hỏi này?
Thư viện tĩnh là kho lưu trữ chứa mã đối tượng cho thư viện, khi được liên kết vào một ứng dụng mà mã được biên dịch thành tệp thực thi. Các thư viện dùng chung khác nhau ở chỗ chúng không được biên dịch thành tệp thực thi. Thay vào đó, trình liên kết động tìm kiếm một số thư mục tìm kiếm (các) thư viện mà nó cần, sau đó tải nó vào bộ nhớ. Nhiều hơn một thực thi có thể sử dụng cùng một thư viện chia sẻ cùng một lúc, do đó làm giảm việc sử dụng bộ nhớ và kích thước thực thi. Tuy nhiên, sau đó có nhiều tệp để phân phối với tệp thực thi. Bạn cần đảm bảo rằng thư viện được cài đặt vào hệ thống sử dụng ở nơi mà trình liên kết có thể tìm thấy nó, liên kết tĩnh loại bỏ vấn đề này nhưng dẫn đến một tệp thực thi lớn hơn.
Nếu bạn làm việc trên các dự án nhúng hoặc các thư viện tĩnh nền tảng chuyên dụng là cách duy nhất để đi, thì nhiều khi chúng sẽ ít gặp rắc rối hơn để biên dịch vào ứng dụng của bạn. Cũng có các dự án và makefile bao gồm mọi thứ làm cho cuộc sống hạnh phúc hơn.
Tôi sẽ đưa ra một quy tắc chung rằng nếu bạn có một cơ sở mã lớn, tất cả được xây dựng trên các thư viện cấp thấp hơn (ví dụ: khung Utils hoặc Gui), mà bạn muốn phân vùng thành các thư viện dễ quản lý hơn, sau đó biến chúng thành các thư viện tĩnh. Các thư viện động không thực sự mua cho bạn bất cứ thứ gì và có ít bất ngờ hơn - ví dụ sẽ chỉ có một ví dụ về singletons.
Nếu bạn có một thư viện hoàn toàn tách biệt với phần còn lại của cơ sở mã (ví dụ: thư viện của bên thứ ba) thì hãy xem xét biến nó thành một dll. Nếu thư viện là LGPL, bạn có thể cần phải sử dụng dll do các điều kiện cấp phép.