Home/ Questions/Q 593481
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T15:51:02+00:00

I have always been an embedded software engineer, but usually at Layer 3 or

  • 0

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.

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.

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:
1 – exception handling; I am still not sure whether to use it (see Embedded C++ : to use exceptions or not?)
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.

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).

Which way do I jump? Super-safe & 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 & maybe some other code now?

I am tempted to just go with Boost, 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 & we find a problem later ….

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Super-safe & 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 &
    maybe some other code now?

    We have a similar debate in the game world and people come down on both sides. Regarding the quoted part, why would you be concerned about losing “much of what constitutes C++”? If it’s not pragmatic, don’t use it. It shouldn’t matter if it’s “C++” or not.

    Run some tests. Can you get around STL’s memory management in ways that satisfy you? If so, was it worth the effort? A lot of problems STL and boost are designed to solve just plain don’t come up if you design to avoid haphazard dynamic memory allocation… does STL solve a specific problem you face?

    Lots of people have tackled STL in tight environments and been happy with it. Lots of people just avoid it. Some people propose entirely new standards. I don’t think there’s one right answer.

    • 0