STL all'interno di un sistema embedded con memoria limitata

Question

Attualmente sto nel processo di costruzione di un sistema integrato, che utilizza un processore ARM Cortex M3, con 64 KB di SRAM.Al momento, sto cercando un modo per garantire prestazioni deterministiche con contenitori STL, che include la garanzia che non riesco a terminare fino a esaurimento della memoria a run-time.

Io sono interessato principalmente come contenitori STL eseguire l'allocazione dinamica della memoria.Anche se non è possibile utilizzare un allocatore personalizzato per avere queste strutture di memoria da un pool che ho messo da parte, avrei bisogno di installazione di una piscina separata per ogni struttura al fine di garantire un'istanza di una struttura non può prendere un altro esempio di spazio.

Sto lavorando con altre persone su questo progetto, che non vogliono preoccuparsi con crudo di allocazione di memoria e preferiscono essere in grado di utilizzare il "noto" strutture di dati (stack, code, deque, ecc).Pertanto, attualmente sto pensando di costruire wrapper intorno a C-matrici di fornire queste strutture.Questo consentirebbe di allocazione statica della memoria necessaria per il supporto di questi contenitori e permettere agli altri sviluppatori di conoscere le dimensioni del contenitore sono istanziati prima esecuzione, in base al codice-dimensioni informazioni fornite dal compilatore.A mio parere, questo garantisce che la memoria interruzione problemi possono verificarsi in fase di esecuzione, e semplifica la progettazione del sistema notevolmente.

L'altra opzione comporterebbe l'assegnazione di contenitori STL all'inizializzazione del sistema.Dopo l'inizializzazione periodo, senza ulteriori allocazione dinamica della memoria potrebbe verificarsi.Tuttavia, a mia conoscenza, il C++ standard STL strutture di dati non supportano questo-sarebbe necessario che i contenitori come una pila di essere in grado di essere pre-assegnati (simile a un vettore).

Gradirei qualsiasi commento riguardo la mia proposta di creare classi con lo standard C-array?Inoltre, c'è un modo più semplice per assegnare una dimensione statica STL contenitore, come una dimensione statica di stack o di coda, in fase di compilazione?(So che questo è possibile con il vettore, ma gli altri non sono sicuro)

Nota:Ho letto con un'altra domanda (Embedded C++ utilizzare STL o non), ma l'autore di questa domanda non è chiaro come la quantità di memoria che avevo (altri poi come stavano utilizzando un ARM7 processo) o apparire in considerazione di una soluzione simile alla mia.

Seconda Nota:Sono consapevole del fatto che alcuni sviluppatori, 64 KB di SRAM può sembrare un sacco di memoria.Infatti, io ho fatto lo sviluppo su AVR processori con significativamente meno memoria, quindi non capisco questo punto di vista.Tuttavia, dal mio attuale (forse inconsapevole) vista 64 KB di memoria non è tanto quando si parla di contenitori STL.

Answer 1

Questa domanda è una sorta di confusa e strana.Prima di tutto, bisogna chiarire alcune idee sbagliate.

Parla di "pila, coda, deque" dal nome.Bene, due di questi non sono contenitori. stack e queue un contenitore di schede.Vedi, in realtà non direttamente conservare gli elementi;semplicemente mediare l'interfaccia per loro. stack assicura che è possibile solo push, pop, e di ottenere il top elemento. queue assicura che è possibile solo push-back, pop-anteriore, e ottenere l'elemento frontale (si è pensato inoltre, consente di ottenere l'elemento posteriore).

Il contenitore di schede di prendere effettivamente come uno dei loro parametri del modello attuale tipo di contenitore da utilizzare.Così si potrebbe usare un stack con un std::list se lo si desidera.Non vorrei necessariamente suggeriscono che (a seconda del caso), ma si potrebbe.

Il contenitore di schede non si preoccupano di memoria;si tratta di contenitori che hanno utilizzare l'allocazione di memoria.

Se si esegue in una stretta di memoria di sistema sono limitate, non stai andando a trovare i contenitori standard per essere molto amichevole.Anche se si utilizzano i contatori di dare loro dimensione fissa buffer di memoria, l'unica cosa che coloro i contatori possono fare per fermare il contenitore effettivo da l'allocazione di memoria è generata un'eccezione.

Per esempio, se si dispone di un vector che ha bisogno di lavorare all'interno di 2 kb di memoria, se si ha una dimensione di 1KB, e tenta di allocare 2.5 KB di più, l'allocatore non semplicemente restituire 2KB.È possibile restituire il 2.5 KB, come richiesto, o buttare std::bad_alloc.Quelli sono gli unici due opzioni.Non c'è modo per l'allocatore di raccontare la vector che si può ottenere di più memoria di ciò che ha, ma non tanto quanto si vuole.

Allo stesso modo, l'allocatore è tenuto a fornire nuovo memoria appena allocata memoria che possono essere copiati.Non è che doveva fornire il luogo stesso di memoria solo con più disponibile.In questo modo probabilmente causare problemi in alcune implementazioni.

I contatori sono destinati per fornire diverse regioni di memoria per l'accesso;non sono ben progettati per limitare le dimensioni del contenitore stesso.

Il mio suggerendo è di tenere traccia di una copia di EASTL.È davvero progettato per questo tipo di cose.Il repo Github ho linkato tu ha alcune correzioni di bug e così via, ma è ancora in gran parte la stessa.Non è una cattiva po ' di codice.Loro STL-come contenitori forniscono la maggior parte dell'interfaccia, in modo che essi possono essere la maggior parte drop-in sostituzione.Ma essi forniscono funzionalità speciali di controllare in particolare le allocazioni di memoria.

Answer 2

So che questo è un vecchio thread, ma per qualcuno che è interessato, ho mantenere un STL-come modello di libreria per applicazioni embedded.Nessun cumulo di utilizzo a tutti.

Embedded Template Library (licenza MIT) https://www.etlcpp.com

Answer 3

Oltre EASTL, è inoltre possibile utilizzare static_vector da boost.Condivide la maggior parte delle API con std::vector e può essere utilizzato con contenitore adattatori (code, stack).Invece di buttare std::bad_alloc si può chiamare throw_bad_alloc(), quindi può essere utilizzato in un ambiente di tipo embedded, senza eccezioni troppo.