Wiem, że to stary wątek, ale nikt nie wspomniał o interfejsach ABI ani o konkretnych problemach z kompilatorem. Więc pomyślałem, że tak.
Zasadniczo opiera się to na koncepcji, w której albo piszesz bibliotekę z nagłówkiem, aby rozpowszechniać ją wśród ludzi, albo ponownie wykorzystujesz siebie, a nie masz wszystko w nagłówku. Jeśli myślisz o ponownym użyciu nagłówka i plików źródłowych i ponownej kompilacji ich w każdym projekcie, to tak naprawdę nie ma to zastosowania.
Zasadniczo, jeśli skompilujesz swój kod C ++ i zbudujesz bibliotekę za pomocą jednego kompilatora, a następnie użytkownik spróbuje użyć tej biblioteki z innym kompilatorem lub inną wersją tego samego kompilatora, możesz otrzymać błędy konsolidatora lub dziwne zachowanie w czasie wykonywania z powodu niezgodności plików binarnych.
Na przykład dostawcy kompilatorów często zmieniają implementację STL między wersjami. Jeśli masz w bibliotece funkcję, która akceptuje std :: vector, to oczekuje, że bajty w tej klasie będą ułożone w sposób, w jaki zostały ułożone podczas kompilacji biblioteki. Jeśli w nowej wersji kompilatora dostawca wprowadził ulepszenia wydajności do std :: vector, kod użytkownika widzi nową klasę, która może mieć inną strukturę, i przekazuje tę nową strukturę do biblioteki. Stamtąd wszystko idzie w dół ... Dlatego nie zaleca się przekazywania obiektów STL poza granice biblioteki. To samo dotyczy typów C Run-Time (CRT).
Mówiąc o CRT, twoja biblioteka i kod źródłowy użytkownika generalnie muszą być połączone z tym samym CRT. W programie Visual Studio, jeśli tworzysz bibliotekę przy użyciu Multithreaded CRT, ale użytkownik łączy się z Multithreaded Debug CRT, wystąpią problemy z łączem, ponieważ biblioteka może nie znaleźć potrzebnych symboli. Nie pamiętam, która to była funkcja, ale dla Visual Studio 2015 Microsoft wprowadził jedną wbudowaną funkcję CRT. Nagle znalazło się w nagłówku, a nie w bibliotece CRT, więc biblioteki, które spodziewały się go znaleźć w czasie łączenia, nie mogły już tego zrobić, a to wygenerowało błędy łącza. W rezultacie te biblioteki wymagały ponownej kompilacji z Visual Studio 2015.
Możesz również uzyskać błędy łącza lub dziwne zachowanie, jeśli używasz interfejsu API systemu Windows, ale tworzysz z innymi ustawieniami Unicode dla użytkownika biblioteki. Dzieje się tak, ponieważ interfejs API systemu Windows ma funkcje, które używają ciągów Unicode lub ASCII oraz makr / definicji, które automagicznie używają poprawnych typów w oparciu o ustawienia Unicode projektu. Jeśli przekażesz ciąg znaków przez granicę biblioteki, który jest niewłaściwego typu, wszystko zepsuje się w czasie wykonywania. Lub może się okazać, że program nie łączy się w pierwszej kolejności.
Te rzeczy są również prawdziwe w przypadku przekazywania obiektów / typów przez granice bibliotek z bibliotek innych firm (np. Wektor Eigen lub macierz GSL). Jeśli biblioteka innej firmy zmieni swój nagłówek między kompilacją biblioteki a użytkownikiem kompilującym kod, sytuacja się zepsuje.
Zasadniczo, aby być bezpiecznym, jedynymi rzeczami, które można przekazać poza granice biblioteki, są typy i zwykłe stare dane (POD). W idealnym przypadku każdy POD powinien mieć strukturę zdefiniowaną w Twoich własnych nagłówkach i nie opierać się na nagłówkach innych firm.
Jeśli podasz bibliotekę tylko z nagłówkiem, cały kod zostanie skompilowany z tymi samymi ustawieniami kompilatora i z tymi samymi nagłówkami, więc wiele z tych problemów zniknie (pod warunkiem, że wersja trzeciej częściowej biblioteki, której Ty i Twój użytkownik używa, jest zgodna z API).
Istnieją jednak wady, o których wspomniano powyżej, takie jak wydłużony czas kompilacji. Możesz także prowadzić firmę, więc możesz nie chcieć przekazywać wszystkich szczegółów implementacji kodu źródłowego wszystkim użytkownikom na wypadek, gdyby któryś z nich go ukradł.