Container STL e compatibilità dell'interfaccia binaria

Question

Interfacce binarie STL

Sono curioso di sapere se qualcuno sta lavorando a livelli di interfaccia compatibili per oggetti STL su più compilatori e piattaforme per C ++.

L'obiettivo sarebbe quello di supportare i tipi STL come tipi di dati di prima classe o intrinseci.

Esiste una limitazione di progettazione intrinseca imposta dal modello in generale che lo impedisce? Questa sembra una grande limitazione dell'utilizzo della STL per la distribuzione binaria.

Teoria - forse la risposta è pragmatica

1. Microsoft ha fatto sforzi in .NET e non si preoccupa davvero del supporto STL C ++ essere "Prima classe".

2. Open-Source non vuole promuovere la distribuzione solo binaria e si concentra su come ottenere le cose bene con un singolo compilatore anziché una mancata corrispondenza di 10 versioni diverse.

Questo sembra essere supportato dalla mia esperienza con QT e altre librerie: generalmente forniscono una build per l'ambiente che stai utilizzando. Qt 4.6 e VS2008 per esempio.

Riferimenti:

• http://code.google.com/p/stabi/
• Compatibilità binaria dei contenitori STL

Answer 1

Penso che il problema Preceeds La tua teoria: C ++ non specifica l'ABI (Interfaccia binaria dell'applicazione).

In effetti anche C no, ma essendo una biblioteca C solo una raccolta di funzioni (e può essere variabili globali) l'ABI è solo il nome delle funzioni stesse. A seconda della piattaforma, i nomi possono essere mangrati in qualche modo, ma, poiché ogni compilatore deve essere in grado di posizionare i CALS del sistema, tutto finisce per utilizzare la stessa convenzione del costruttore di sistemi operativi (in Windows, _cdecl solo provocare la preparazione di un file _ al nome della funzione.

Ma C ++ ha un sovraccarico, quindi sono richiesti schemi di mangling più complesso. Per quanto riguarda oggi, non esiste alcun accordo tra i produttori di compilatori su come tale mangusta deve essere fatto. È tecnicamente impossibile compilare una libreria statica C ++ e collegarla a un OBJ C ++ proveniente da un altro compilatore. Lo stesso è per le DLL.

E poiché i compilatori sono tutti diversi anche per le funzioni dei membri sovraccaricate compilate, nessuno offre effettivamente il problema dei modelli.

Può essere tecnicamente offerto introducendo un reindirizzamento per ogni tipo parametrico e introducendo tabelle di spedizione, ma ... ciò rende la funzione modello non diversa (in termini di spedizione di chiamate) rispetto alle funzioni virtuali delle basi virtuali, rendendo così le prestazioni del modello per diventare simili al classico spedizione OOP (anche se può limitare il gonfiore del codice ... il compromesso non è sempre ovvio)

In questo momento, sembra che non vi sia alcun interesse tra i produttori di compilatore accettare uno standard comune poiché sacrificherà tutte le differenze di prestazione che ogni produttore può avere con la propria ottimizzazione.

Answer 2

I modelli C ++ sono un codice generato a tempo di compilazione.
Ciò significa che se si desidera utilizzare una classe modello, è necessario includere la sua intestazione (dichiarazione) in modo che il compilatore possa generare il codice giusto per la classe modello di cui hai bisogno.

Quindi, i modelli non possono essere pre-compilati ai file binari.

Ciò che le altre biblioteche ti danno sono le classi di utilità di base pre-riempite che non sono modellate.

C# Generici, ad esempio, sono compilati nel codice IL sotto forma di DLL o eseguibili.
Ma il codice IL è proprio come un altro linguaggio di programmazione, quindi questo consente al compilatore di leggere le informazioni generiche dalla libreria inclusa.

Il codice .NET IL viene compilato nel codice binario effettivo in fase di esecuzione, quindi il compilatore in fase di esecuzione ha tutte le definizioni di cui ha bisogno in IL per generare il codice giusto per i generici.

Answer 3

Sono curioso di sapere se qualcuno sta lavorando a livelli di interfaccia compatibili per oggetti STL su più compilatori e piattaforme per C ++.

Sì, lo sono. Sto lavorando su un livello di interfacce standardizzate che puoi (tra le altre cose) utilizzare per superare i riferimenti binari "gestiti" al sicuro a istanze di STL, boost o altri tipi C ++ attraverso i confini dei componenti. La biblioteca (chiamata "Vex") fornirà implementazioni di queste interfacce più fabbriche adeguate per avvolgere e scartare le famose Std :: o Boost :: Tipi. Inoltre, la libreria fornisce operatori di query a forma di LINQ per filtrare e manipolare i contenuti di ciò che chiamo Range e RangeSource. La biblioteca non è ancora pronta a "diventare pubblico", ma ho intenzione di pubblicare una versione iniziale "Anteprima" il prima possibile ...

Esempio:

com1 passa un riferimento a std::vector<uint32_t> a 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...
    }
};

Riconoscerai la relazione con vari concetti familiari: Linq, Boost.Range, Any_iterator e D'S Ranges ... Uno degli intenti di base di "Vex" non è reinventare la ruota - aggiunge solo quel livello di interfaccia più alcune infrastrutture richieste e sintattica zucchero per le domande.

Saluti,

Paolo