2016-04-30 35 views
7

ricerca di specifiche C++ ambienti (compilatori, sistemi operativi, hardware, etc.) per i quali non c'è alcuna libreria standard (ad esempio, "x versione di gcc per il Nintendo 3DS")Quali ambienti C++ attivamente utilizzati mancano di supporto (la maggior parte, se non tutti) della libreria standard?

Alcune librerie C++, come Box2D o TinyXML2 che mirano essere uber-portatile usa pochissimo della libreria standard, se non del tutto. Tuttavia, non comprendo pienamente questo approccio. Quali ambienti C++ attivamente utilizzati mancano di supporto (la maggior parte, se non tutti) della libreria standard?

+1

Le persone che progettano ambienti embedded a volte evitano l'STL. Rilevante: http://stackoverflow.com/questions/2226252/embedded-c-to-use-stl-or-not – computerfreaker

+0

@computerfreaker Vero, ma sono preoccupato per le librerie che mirano a * supportare * i sistemi incorporati, ma non a scapito delle piattaforme desktop di supporto o simili. – JesseTG

+0

L'industria dei giochi è preoccupata per le regressioni di prestazioni causate dall'allocazione dell'heap. Evitano spesso l'utilizzo della libreria standard. E stiamo parlando di minuscoli overheads come quello dell'allocazione nel puntatore condiviso per il conteggio ref. – Alex

risposta

-3

La risposta semplice è, quando si sceglie di non includere i pacchetti STL.

Con la maggior parte degli IDE se il progetto non ha elementi che stanno chiamando all'STL, quindi lo STL non è incluso in fase di compilazione.

Anche se ci possono essere casi in cui si deve escludere specificamente STL attraverso l'IDE/compilatore

Uno dei grandi motivi per evitare lo STL è quello di ridurre la dimensione finale del file compilato.

+1

Chiedo informazioni su specifici ambienti C++ (compilatori, sistemi operativi, hardware, ecc.) Per i quali non esiste una libreria standard (ad esempio "versione x di gcc per Nintendo 3DS"). – JesseTG

5

Il supporto della libreria standard C++ può variare tra diversi produttori di compilatori e anche tra diverse versioni dello stesso compilatore. Questo è particolarmente vero per i sistemi embedded e le varie console.

Con "Varia" intendo che possono esserci bug, funzionalità implementate in modo diverso o anche funzionalità mancanti. Ad esempio, Android ha un'implementazione della libreria standard C++ molto minimal.

Ci sono molti compilatori C++ strani e meravigliosi là fuori; non è solo GCC e Visual Studio. Nintendo ad esempio utilizza il compilatore Green Hills.

Quindi, a causa della varietà di compilatori disponibili, il modo migliore per supportarne un numero elevato è quello di attenersi solo alle funzionalità fornite dalla libreria standard C. Molte librerie portatili evitano persino l'uso di funzionalità C++ più moderne.

1

Gli unici ambienti che posso pensare sono quelli indipendenti (sistema operativo e programmi incorporati a processo singolo). Certo, alcuni sviluppatori evitano attivamente di usare l'STL, ma questa è più una decisione progettuale che una mancanza di supporto nell'ambiente. Credo che il più grande ostacolo in questi ambienti vincolati sia il supporto alle eccezioni (che molte funzioni STL generano). Per ottenere supporto per questi è necessario effettuare il porting di un ABI C++ e una libreria di unwind (per eseguire lo stack unwinding e goto alla dichiarazione catch). Non c'è nulla che impedisca di implementare questi bit richiesti, ma sono più dipendenze che ovviamente risultano gonfiate solo per il supporto di base per qualcosa come le liste concatenate. Per portare l'ABI vedere the OSDEV wiki entry.

Esistono altre dipendenze per i nuovi standard C++ (da C++ 11 in poi). Posso immaginare che std::thread richieda un'implementazione di threading come pthreads. std::chrono probabilmente avrà bisogno di un livello intermedio implementato tra esso e il tempo di libreria standard C. Probabilmente ci sono più funzionalità STL che richiedono il supporto del sistema operativo.

La parte modello parte di STL è anche abbastanza importante. I modelli spesso aumentano notevolmente le dimensioni binarie finali. Nel caso di un std::list ad esempio, std::list<MyClass1> e std::list<MyClass2> si otterrà la specializzazione di due diversi contenitori. Il codice apparirà molto simile ma verrà duplicato per gestire in modo specifico il loro tipo di elemento.Altre implementazioni di liste collegate spesso usano un puntatore void per collegare i nodi e quindi lanciarlo nella classe appropriata quando richiesto. In questo modo, esiste una classe di lista istanziata per ints, char *, MyClass1, ecc. La maggiore dimensione binaria è spesso inaccettabile negli ambienti incorporati, ma si deve notare che diventa anche un problema quando LibA implementa LibA :: LinkedList e LibB LibB :: LinkedList.

Attualmente la qualità delle implementazioni è diventata meno problematica. È inoltre utile che GCC si rivolga a molte architetture in modo che i nuovi standard del compilatore siano disponibili (come sopra, è ancora necessario portare alcune funzionalità dell'STL). Il GCC più vecchio che ho usato era GCC v4.3 o qualcosa del genere per un dispositivo PowerPC incorporato. Questo è stato rilasciato nel 2010 e aveva pieno supporto STL.

In sintesi, la necessità di librerie con un set di funzionalità molto focalizzato può ancora aiutare, ma a mio parere riducono il numero di piattaforme a cui il progetto si rivolge se forniscono funzionalità che avvolgono il comportamento dipendente dal sistema operativo. Per la struttura dei dati grezzi e il supporto dell'algoritmo non puoi sbagliare. Alla fine, devi indirizzare alcuni sottoinsiemi di piattaforme. In C++ 11 credo che tu abbia come target il 99% dei sistemi operativi desktop/server usati e il 99% dei dispositivi Linux incorporati. Come evidenziato in un'altra risposta, Android è stato un problema, ma il this page sembra evidenziare per ottenere tutti i bit necessari per ottenere un ambiente davvero moderno.