Łączenie statyczne/dynamiczne Runtime

Question

Jakie są najlepsze praktyki dotyczące wyboru metody łączenia w VC++? Czy cokolwiek/wszystko może być statycznie powiązane?

W projekcie powiązanym dynamicznie ważne jest względne/bezwzględne położenie połączonej biblioteki?

Jakie są plusy i minusy?

dodano: Miałem głównie na myśli pliki lib. Czy zachowują się tak samo, jak dll linkowania?

Answer 1

Dynamiczne linki umożliwiają aktualizację pojedynczych plików DLL bez ponownej kompilacji aplikacji. Właśnie dlatego okna można aktualizować bez ponownej kompilacji aplikacji, ponieważ dynamiczny linker jest w stanie określić punkty wejścia w bibliotece dll, pod warunkiem, że istnieje nazwa metody.

Statyczne powiązanie aplikacji ma tę zaletę, że połączenia z połączonym kodem nie są pośrednie, więc działają szybciej. Może to mieć wpływ na wyjątkowo zależny od wydajności kod.

Używanie bibliotek DLL może również pomóc w zmniejszeniu śladu pamięci, ponieważ skutecznie ładujesz biblioteki tylko wtedy, gdy ich potrzebujesz, i możesz je rozładować po zakończeniu (pomyśl o wtyczkach aplikacji, załaduj bibliotekę przeglądania obrazów tylko wtedy, gdy masz obraz open itp.)

EDYCJA: Robert Gamble dodał komentarz, który mi brakowało: biblioteki DLL są ładowane do pamięci współdzielonej przez wszystkie procesy w systemach operacyjnych. Oznacza to, że jeśli dwa programy (lub dwie instancje twojego programu) używają tej samej biblioteki DLL, użyją tej samej biblioteki DLL załadowanej do pamięci, co jeszcze bardziej zmniejszy całkowite zużycie pamięci.

Answer 2

Oczywistą zaletą biblioteki dll jest to, że można aktualizować poszczególne komponenty, nie tylko całą aplikację (teoretycznie) i udostępniać wspólne komponenty (enkapsulując je w bibliotekach dll). Niestety w praktyce istnieje pewna ilość powiązania między bibliotekami DLL (nawet jeśli dobrze zdefiniowano). To prowadzi do konieczności aktualizacji biblioteki dll w pasujących zestawach i bibliotekach izolujących, które nie grają dobrze razem.

Jeśli nie zrobione starannie uaktualnienie DLL może prowadzić do problemów znanych jako DLL Hell.

W prawdziwym życiu aplikacja zazwyczaj umieszcza wszystkie biblioteki dll, których używają w tym samym katalogu, co plik wykonywalny. Pozwala to na uaktualnienie, ale nie promuje udostępniania. Aktualizacja polega wówczas na uaktualnieniu zestawów bibliotek DLL w katalogu aplikacji w synchronizacji z biblioteką DLL w centralnym repozytorium systemu Windows.

Answer 3

DLL może powodują mniejszą workingset wykonawczego, jeżeli zgłoszenie zostało napisane w taki sposób, aby zarządzać kontekst przełączania między DLL (Na przykład, dla większych aplikacji, można podzielić funkcjonalność aplikacji w granicach logicznych być zaimplementowane w samodzielnych bibliotekach DLL i umożliwia ładowanie modułu ładującego w czasie wykonywania).

Chociaż prawdą jest, że biblioteki DLL są instalowane/kopiowane w tym samym folderze co pliki .exe, warunkiem jest przestrzeganie reguł ładowania ładowarek (w tym folderu systemowego (zły pomysł), PATH, bieżącego katalogu [zobacz: LoadLibrary Dokumentacja pomocy API dla pełnego opisu priorytetu]).

"Dodano" komentarz dotyczący plików LIB. W OBU dynamicznym i statycznym łączysz używając plików LIB. Ale w przypadku ładowania dynamicznego dostarczasz plik .exe wraz ze wszystkimi zależnymi bibliotekami DLL (pliki LIB zawierają wyeksportowane punkty wejściowe dla odpowiedniej biblioteki DLL).

Wolę pliki DLL, ponieważ moje aplikacje są zwykle większe i segmentowane, co pozwala mi dostarczać TYLKO te zaktualizowane komponenty (biblioteki DLL). Oddzielamy nawet logikę biznesową od prezentacji w ich własnych bibliotekach DLL [pozwala na lokalizację biblioteki zasobów tylko-zależnej od logiki.

Programowanie przy użyciu bibliotek DLL powoduje, że zmuszasz się do przestrzegania umowy eksportowanej klasy/metody lub funkcji.