title: Embedded C++ : to use STL or not?
body: <p>I have always been an embedded software engineer, but usually at Layer 3 or 2 of the OSI stack. I am not really a hardware guy. I have generally always done telecoms products, usually hand/cell-phones, which generally means something like an ARM 7 processor.</p>
  
  <p>Now I find myself in a more generic embedded world, in a small start-up, where I might move to "not so powerful" processors (there's the subjective bit) - I cannot predict which.</p>
  
  <p>I have read quite a bit about debate about using STL in C++ in embedded systems and there is no clear cut answer. There are some small worries about portability, and a few about code size or run-time, but I have two major concerns:<br>
    1 - exception handling; I am still not sure whether to use it (see <a href="https://stackoverflow.com/questions/2226227/embeeded-c-to-use-exceptions-or-not">Embedded C++ : to use exceptions or not?</a>)<br>
    2 - I strongly dislike dynamic memory allocation in embedded systems, because of the problems it can introduce. I generally have a buffer pool which is statically allocated at compile time and which serves up only fixed size buffers (if no buffers, system reset). The STL, of course, does a lot of dynamic allocation.</p>
  
  <p>Now I have to make the decision whether to use or forego the STL - for the whole company, for ever (it's going into some very core s/w).</p>
  
  <p>Which way do I jump? Super-safe &amp; lose much of what constitutes C++ (imo, it's more than just the language definition) and maybe run into problems later or have to add lots of exception handling &amp; maybe some other code now?</p>
  
  <p>I am tempted to just go with <a href="http://www.boost.org/" rel="noreferrer">Boost</a>, but 1) I am not sure if it will port to every embedded processor I might want to use and 2) on their website, they say that they doesn't guarantee/recommend certain parts of it for embedded systems (especially FSMs, which seems weird). If I go for Boost &amp; we find a problem later ....</p>