Wewnętrznie biblioteka będzie pisana w Qt na 100% i tutaj nie ma sensu pisania 2 wersji chodzi jedynie o zewnętrzne, publiczne API a jest narzucone "z góry" że ma być "natywne" w projektach Qt czyli QString, QVector, QMap w argumentach i wartościach zwracanych a odpowiedniki std w reszcie projektów i dlatego myślałem o kompilacji warunkowej ale chciałem zapytać bo może są z tym jakieś problemy które mogłyby wyjść dopiero w trakcie a ktoś z was już o nich i wie i może zaoszczędzić mi czasu i nerwów.
W tej sytuacji to wpadasz w bagno. Niestety Qt używa singletonów i wiele klas się do nich odnosi. najczęściej są one powiązane z QApplication
.
To stwarza pewne ograniczenia co może być użyte w takiej bibliotece Qt a co nie.
Jeśli nie będziesz się pilnował to biblioteka po prostu nie będzie działać, gdy będzie łączona z aplikacją nie używającą Qt (na starcie będziesz miał crash).
To oznacza, że opakowywanie je czystym STL-em po prostu możne nie mieć sensu.
Niestety twój temat jest zbyt ogólny by odpowiedzieć czy jesteś w stanie to zrobić, czy nie.
Sytuacja jest podobna jak z innymi frameworkami, przykładowo można opakować bibliotekę Java tak by była dostępna z C++ (JNI), ale jeśli aplikacja docelowa nie ma wirtualnej maszyny Java to sprawa się bardzo komplikuje.
Nie oznacza to, że nie ma to zupełnie sensu. Przykładowo, robię teraz projekcie, gdzie biblioteki Java, .net, ObjC, Android są opakowywane za wspólnymi interface'ami. Następnie całe to opakowanie jest użyte do napisanie logiki w czystym C++, a następnie ta logika jest opakowywana API C#, ObjC, Java i dostarczana jest wspólna końcowa biblioteka dla wielu platform z API zdefiniowanym w języku charakterystycznym dla danej platformy.
Działa to zaskakująco dobrze.
Jednak problem, że czegoś może brakować do poprawnego działania w tym wypadku nie wystąpi, bo kod C++ jest środkiem kanapki pomiędzy dwoma kawałkami chleba charakterystycznymi dla danej platformy, więc zawsze ma się gwarancję, że wszystko co będzie potrzebne do poprawnego działania biblioteki będzie dostępne.