Une bibliothèque C ++ 11 compilée (lib, dll, etc.) peut-elle être liée dans des compilateurs C ++ plus anciens?

Les anciens compilateurs C ++ (par exemple VS2008 et gcc3.4) pourraient-ils se lier à des bibliothèques externes écrites en C ++ 11?

Ma pensée est que les fichiers C ++ 11 .lib ne sont que du code octet à ce stade, et cela ne devrait pas déranger les anciens compilateurs sur la façon dont il a été généré, tant qu'il est en quelque sorte résolvable et appelable.

Je développe une petite bibliothèque dont l'API devrait toujours prendre en charge les utilisateurs C ++ 03. Donc, pour l'avenir, je me demande s'il est correct d'implémenter ma bibliothèque en utilisant des fonctionnalités utiles telles std::unique_ptrou telles, ou dois-je simplement rester avec boost::?

À condition que votre bibliothèque utilise uniquement C ++ 11 dans son implémentation et n'expose pas les fonctionnalités ou les types C ++ 11 publiquement, et surtout si vous utilisez une liaison statique, alors oui, cela est possible et même standard.

Considérez le cas courant où une bibliothèque expose une interface de niveau C (pour être utilisable par la plus grande variété de clients) mais qui est implémentée en interne en C ++. Les clients qui se lient à une telle bibliothèque n'ont qu'à se soucier de l'API binaire publique (fonctions exportées), que vous aurez contrainte d'utiliser en C / C ++ hérité pour une compatibilité maximale. Un programme Java peut se lier à des API de niveau C qui sont implémentées en interne en C ++. Cela ne signifie pas que Java doit "prendre en charge C ++". De même, un client C / C ++ à l'ancienne peut se lier à une API de niveau C ou de niveau C ++ qui utilise en interne une version plus avant-gardiste des bibliothèques C ++ ou de toute autre bibliothèque. Deux choses distinctes: ce qui est nécessaire pour établir un lien avec l'interface de la bibliothèque, et ce à quoi la bibliothèque elle-même est liée en interne (ou en tire statiquement).

Vous n'exposez simplement pas les clients de votre bibliothèque aux dépendances de votre implémentation.

Si vous pouvez lier statiquement vos dépendances (C ++ 11 ou autre) dans votre bibliothèque, c'est propre et autonome. La bibliothèque est une véritable boîte noire: rien que du bytecode. Mais même si votre bibliothèque est liée à vos dépendances via une liaison "dynamique implicite" (à ne pas confondre avec le type explicite LoadLibrary / GetProcAddress et les méthodes similaires sur * nix et OS X), les anciens clients devraient toujours être en mesure de se lier à cette bibliothèque. interface publique, même s'ils ne pouvaient pas se lier aux bibliothèques dont la bibliothèque dépend .

On dirait que vous voulez écrire une nouvelle bibliothèque pour les autres à utiliser, et que vous souhaitez utiliser C + 11 comme langage d'implémentation. Il y a un certain nombre de questions à considérer:

• en introduisant une nouvelle version de C ++, vous introduirez la nécessité de déployer les nouvelles bibliothèques d'exécution C ++ avec votre bibliothèque, est-ce OK?
• vous ne devez pas utiliser de nouveaux types C + 11 dans votre interface publique, sinon ils ne pourront pas l'appeler.
• En général, vous devez éviter les types complexes, tels que unique_ptr, même vector, etc. À moins que vous ne distribuiez votre bibliothèque en tant que code source, la disposition des objets dans votre bibliothèque peut différer de la disposition dans le code client. Restez avec des types simples qui ne présentent aucun risque de variations de disposition des objets.