Conteneurs STL et compatibilité de l'interface binaire

Question

Interfaces binaires STL

Je suis curieux de savoir si quelqu'un travaille sur des couches d'interface compatibles pour les objets STL sur plusieurs compilateurs et plates-formes pour C ++.

L'objectif serait de prendre en charge les types STL en tant que types de données de première classe ou intrinsèques.

Y a-t-il une limitation de conception inhérente imposée par la création de modèles en général qui empêche cela? Cela semble être une limitation majeure de l'utilisation de la STL pour la distribution binaire.

Théorie - La réponse est peut-être pragmatique

1. Microsoft a fait des efforts dans .NET et ne se soucie pas vraiment de la prise en charge de C ++ STL comme étant "de première classe".

2. L'open-source ne veut pas promouvoir une distribution uniquement binaire et se concentre sur le fait de faire les choses correctement avec un seul compilateur au lieu d'une incompatibilité de 10 versions différentes.

Cela semble être soutenu par mon expérience avec Qt et d'autres bibliothèques - ils fournissent généralement une version pour l'environnement que vous allez utiliser. Qt 4.6 et VS2008 par exemple.

Références:

• http://code.google.com/p/stabi/
• Compatibilité binaire des conteneurs STL

Answer 1

Je pense que le problème précède votre théorie: C ++ ne spécifie pas l'ABI (interface binaire d'application).

En fait, même C ne le fait pas, mais étant une bibliothèque C juste une collection de fonctions (et pouvant être des variables globales), l'ABI est juste le nom des fonctions elles-mêmes. Selon la plate-forme, les noms peuvent être déformés d'une manière ou d'une autre, mais, comme chaque compilateur doit être capable de placer des cals système, tout finit par utiliser la même convention du constructeur du système d'exploitation (dans Windows, _cdecl entraîne simplement l'ajout d'un _ à la fonction nom.

Mais le C ++ est surchargé, donc un schéma de gestion plus complexe est nécessaire. À ce jour, aucun accord n’existe entre les fabricants de compilateurs sur la manière de procéder à une telle manipulation. Il est techniquement impossible de compiler une bibliothèque statique C ++ et de la lier à un OBJ C ++ provenant d'un autre compilateur. Il en va de même pour les DLL.

Et comme les compilateurs sont tous différents même pour les fonctions membres surchargées compilées, personne ne se pose le problème des modèles.

Cela PEUT techniquement être offert en introduisant une redirection pour chaque type paramétrique et en introduisant des tables de répartition mais ... cela rend la fonction modèle pas différente (en termes de répartition des appels) des fonctions virtuelles des bases virtuelles, rendant ainsi le modèle de performance pour devenir similaire au dispatching POO classique (bien que cela puisse limiter les ballonnements de code ... le compromis n'est pas toujours évident)

Pour le moment, il semble qu'il n'y ait aucun intérêt entre les fabricants de compilateurs à se mettre d'accord sur une norme commune car cela sacrifiera toutes les différences de performances que chaque fabricant peut avoir avec sa propre optimisation.

Answer 2

Les modèles C ++ sont du code généré à la compilation.
Cela signifie que si vous souhaitez utiliser une classe basée sur un modèle, vous devez inclure son en-tête (déclaration) afin que le compilateur puisse générer le bon code pour la classe basée sur un modèle dont vous avez besoin.

Ainsi, les modèles ne peuvent pas être pré-compilés en fichiers binaires.

Ce que les autres bibliothèques vous offrent, ce sont des classes d'utilitaires de base pré-compilées qui ne sont pas basées sur un modèle.

Les génériques C # par exemple sont compilés en code IL sous la forme de DLL ou d'exécutables.
Mais le code IL est comme un autre langage de programmation, ce qui permet au compilateur de lire les informations génériques de la bibliothèque incluse.

Le code .Net IL est compilé en code binaire réel au moment de l'exécution, de sorte que le compilateur au moment de l'exécution a toutes les définitions dont il a besoin en IL pour générer le bon code pour les génériques.

Answer 3

Je suis curieux de savoir si quelqu'un travaille sur une interface compatible couches d'objets STL sur plusieurs compilateurs et plates-formes pour C ++.

Oui, je le suis. Je travaille sur une couche d'interfaces standardisées que vous pouvez (entre autres) utiliser pour passer des références binaires "gérées" à des instances de STL, Boost ou d'autres types C ++ à travers les limites des composants. La bibliothèque (appelée 'Vex') fournira des implémentations de ces interfaces ainsi que des usines appropriées pour encapsuler et dérouler les types std :: ou boost :: populaires. De plus, la bibliothèque fournit des opérateurs de requête de type LINQ pour filtrer et manipuler le contenu de ce que j'appelle Range et RangeSource. La bibliothèque n'est pas encore prête à «devenir publique» mais j'ai l'intention de publier une première version «d'aperçu» dès que possible ...

Exemple:

com1 passe une référence à std::vector<uint32_t> à com2:

com1:

class Com2 : public ICom1 {
    std::vector<int> mVector;

    virtual void Com2::SendDataTo(ICom1* pI)
    {
        pI->ReceiveData(Vex::Query::From(mVector) | Vex::Query::ToInterface());
    }
};

com2:

class Com2 : public ICom2 {
    virtual void Com2::ReceiveData(Vex::Ranges::IRandomAccessRange<uint32_t>* pItf)
    {
        std::deque<uint32_t> tTmp;
        // filter even numbers, reverse order and process data with STL or Boost algorithms
        Vex::Query::From(pItf)
            | Vex::Query::Where([](uint32_t _) -> { return _ % 2 == 0; })
            | Vex::Query::Reverse
            | Vex::ToStlSequence(std::back_inserter(tTmp));
        // use tTmp...
    }
};

Vous reconnaîtrez la relation avec divers concepts familiers: LINQ, Boost.Range, any_iterator et D's Ranges ... L'une des intentions de base de 'Vex' n'est pas de réinventer la roue - il ajoute seulement cette couche d'interface plus certaines requises infrastructures et sucre syntaxique pour les requêtes.

Salutations,

Paul