4 ms·

How much is this space increase because of dependences upon the STL library that is included to do the exception handling versus the actual exception hanlding i

How much is this space increase because of dependences upon the STL library that is included to do the exception handling versus the actual exception hanlding itself. I would like to see a comparison that doesn't use STL for the exceptions in C++ and then measure that difference. I find that the use of STL increases the size of the resulting binary significantly by itself. (Now maybe since STL is the official C++ library maybe this is still a fair comparison, but STL is known for bloating the size of binaries.)

tacos 11y ago
I realize we're talking embedded here, but what is "bloat" in the context of 2016? I have a suite of 35 command line apps with header-only dependencies on Boost and the whole shebang builds in under ten seconds on 2012 MacBook. Many of the binaries (64-bit) are under 200k. EDIT: I've hand-coded 68xx, 56xxx and 8051 when 4K RAM was a luxury. But this "C++ is bloat" and "exceptions are universally wrong" discussion feels a little 1995 to me. It's 2016: if you have software it's not that hard to find a $5 system to run it on. And people who actually write embedded code know how to pick their tools. And at least one of them isn't necessarily afraid of STL or exceptions... me. EDIT 2: jotux comment below nails it.
- TickleSteve 11y ago
  200KB is way too large for a lot of embedded micros.
- jotux 11y ago
  >but what is "bloat" in the context of 2016? I've recently (last 3 years) moved my bare-metal embedded software development from C to C++ so I've actually run into issues of STL adding too much to the binary size. To give a real-world example, I'm working on a custom device that is a type of data cartridge. I have a "big" ARM-A5(Atmel SAMA5D36) processor running embedded linux that does all the heavy lifting but goes down when main power is removed. I have a small ARM-Cortex-M0(LPC824) that is always running on a battery and manages power, watches for button-presses, and a few other janitorial items on the device. The small processor has 32kB of program space and 8kB of RAM, and my project is mostly C++. Here are some specific examples of how using any STL will bloat program size: Using std::string, and touching any of the STL string handling immediately adds 20kB to my binary. Using stl::list is 6-10kB of program space (actually not that bad and std::vector is pretty efficient). Adding exception handling adds 5kB of code and a single exception adds 6kB of code (not stl but just an example). I've worked on a lot of embedded projects and my general rule of thumb for, "How big of a part do I need to use fully-featured C++?" is 256kB of program space -- something most bare-metal embedded software engineers would call a large amount of program memory. On projects where I have less than that I don't use STL and basically use C++ as C with classes, function/operator overloading and templates.
- noonespecial 11y ago
  Just to add to what jotux already pointed out. $5 is an order of magnitude too much for the systems I work on. Calling a string handler can mean $0.35 more per unit cost for the extra space needed. Across 10k units, this matters enough to care.
- euyyn 11y ago
  I'm sorry you got downvoted. You sparked a conversation with very interesting information I didn't know myself.
- Paul_S 11y ago
  I think we have different ideas about what an embedded environment is if a macbook is your reference platform.
  - tacos 11y ago
    "64-bit" and "using Boost" are the clues that I was making a contrasting, not supporting, argument.
haberman 11y ago
> I would like to see a comparison that doesn't use STL for the exceptions in C++ and then measure that difference. Even better, how about getting info directly from the binary about how much of the code was inlined from STL headers? If you compile with debugging info, this info exists already. It's put there so that the debugger knows what source to show you when the code breaks on a particular instruction. I'm working on a tool right now that would offer this information.

tacos 11y ago

I realize we're talking embedded here, but what is "bloat" in the context of 2016? I have a suite of 35 command line apps with header-only dependencies on Boost and the whole shebang builds in under ten seconds on 2012 MacBook. Many of the binaries (64-bit) are under 200k. EDIT: I've hand-coded 68xx, 56xxx and 8051 when 4K RAM was a luxury. But this "C++ is bloat" and "exceptions are universally wrong" discussion feels a little 1995 to me. It's 2016: if you have software it's not that hard to find a $5 system to run it on. And people who actually write embedded code know how to pick their tools. And at least one of them isn't necessarily afraid of STL or exceptions... me. EDIT 2: jotux comment below nails it.

TickleSteve 11y ago
200KB is way too large for a lot of embedded micros.
jotux 11y ago
>but what is "bloat" in the context of 2016? I've recently (last 3 years) moved my bare-metal embedded software development from C to C++ so I've actually run into issues of STL adding too much to the binary size. To give a real-world example, I'm working on a custom device that is a type of data cartridge. I have a "big" ARM-A5(Atmel SAMA5D36) processor running embedded linux that does all the heavy lifting but goes down when main power is removed. I have a small ARM-Cortex-M0(LPC824) that is always running on a battery and manages power, watches for button-presses, and a few other janitorial items on the device. The small processor has 32kB of program space and 8kB of RAM, and my project is mostly C++. Here are some specific examples of how using any STL will bloat program size: Using std::string, and touching any of the STL string handling immediately adds 20kB to my binary. Using stl::list is 6-10kB of program space (actually not that bad and std::vector is pretty efficient). Adding exception handling adds 5kB of code and a single exception adds 6kB of code (not stl but just an example). I've worked on a lot of embedded projects and my general rule of thumb for, "How big of a part do I need to use fully-featured C++?" is 256kB of program space -- something most bare-metal embedded software engineers would call a large amount of program memory. On projects where I have less than that I don't use STL and basically use C++ as C with classes, function/operator overloading and templates.
noonespecial 11y ago
Just to add to what jotux already pointed out. $5 is an order of magnitude too much for the systems I work on. Calling a string handler can mean $0.35 more per unit cost for the extra space needed. Across 10k units, this matters enough to care.
euyyn 11y ago
I'm sorry you got downvoted. You sparked a conversation with very interesting information I didn't know myself.
Paul_S 11y ago
I think we have different ideas about what an embedded environment is if a macbook is your reference platform.
- tacos 11y ago
  "64-bit" and "using Boost" are the clues that I was making a contrasting, not supporting, argument.

haberman 11y ago

> I would like to see a comparison that doesn't use STL for the exceptions in C++ and then measure that difference. Even better, how about getting info directly from the binary about how much of the code was inlined from STL headers? If you compile with debugging info, this info exists already. It's put there so that the debugger knows what source to show you when the code breaks on a particular instruction. I'm working on a tool right now that would offer this information.