Czy skompilowaną bibliotekę C ++ 11 (lib, dll itp.) Można połączyć ze starszymi kompilatorami C ++?

Czy starsze kompilatory C ++ (np. VS2008 i gcc3.4) mogą łączyć się z bibliotekami zewnętrznymi napisanymi w C ++ 11?

Myślę, że pliki .lib C ++ 11 są na tym etapie tylko bajtowym kodem i nie powinny niepokoić starszym kompilatorom, w jaki sposób zostały wygenerowane, o ile można je w jakiś sposób rozwiązać i wywołać.

Tworzę małą bibliotekę, której interfejs API powinien nadal obsługiwać użytkowników C ++ 03. Patrząc w przyszłość, zastanawiam się, czy mogę wdrożyć bibliotekę za pomocą pomocnych funkcji takich jak std::unique_ptri takie, czy też muszę się trzymać boost::?

Pod warunkiem, że twoja biblioteka używa tylko C ++ 11 w swojej implementacji i nie ujawnia publicznie obiektów lub typów C ++ 11, a zwłaszcza jeśli używasz statycznego łączenia, to tak, jest to możliwe, a nawet standardowe.

Rozważ typowy przypadek, w którym biblioteka udostępnia interfejs na poziomie C (który może być używany przez najszerszą gamę klientów), ale który jest wewnętrznie zaimplementowany w C ++. Klienci łączący się z taką biblioteką muszą martwić się tylko publicznym binarnym interfejsem API (funkcje eksportowane), który będzie musiał być starszym językiem C / C ++ dla maksymalnej kompatybilności. Program Java może łączyć się z interfejsami API na poziomie C, które są wewnętrznie zaimplementowane w C ++. Nie oznacza to, że Java musi „obsługiwać C ++”. Podobnie klient w starym stylu C / C ++ może łączyć się z interfejsem API na poziomie C lub C ++, który wewnętrznie korzysta z bardziej awangardowej wersji bibliotek C ++ lub dowolnych innych bibliotek. Dwie oddzielne rzeczy: co jest wymagane, aby połączyć się z interfejsem biblioteki i co sama biblioteka wewnętrznie łączy (lub pobiera statycznie).

Po prostu nie narażasz klientów swojej biblioteki na zależności implementacji.

Jeśli możesz statycznie połączyć swoje zależności (C ++ 11 lub cokolwiek innego) z biblioteką, jest to czyste i samodzielne. Biblioteka to prawdziwa czarna skrzynka: tylko kod bajtowy. Ale nawet jeśli twoja biblioteka łączy się z twoimi zależnościami poprzez „niejawne dynamiczne” połączenie (nie mylić z oczywistością typu LoadLibrary / GetProcAddress i podobnymi metodami w * nix i OS X), starsi klienci powinni nadal mieć możliwość łączenia się z biblioteką interfejs publiczny, nawet jeśli nie mogą połączyć się z bibliotekami, od których zależy biblioteka .

Wygląda na to, że chcesz napisać nową bibliotekę do użytku dla innych i że chcesz używać C + 11 jako języka implementacji. Należy wziąć pod uwagę szereg kwestii:

• wprowadzając nową wersję C ++, wprowadzisz potrzebę wdrożenia nowych bibliotek środowiska uruchomieniowego C ++ w swojej bibliotece, czy to w porządku?
• należy nie używać nowych C + 11 rodzajów w interfejsie publicznym, w przeciwnym razie nie będzie w stanie go nazwać.
• Zasadniczo należy unikać złożonych typów, takich jak unikalny_ptr, a nawet wektor itp. O ile nie rozpowszechniasz biblioteki jako kodu źródłowego, układ obiektów w bibliotece może różnić się od układu w kodzie klienta. Trzymaj się prostych typów, które nie powodują ryzyka zmiany układu obiektu.