News for hackers. Stuff that matters.
Re:Size cost of C++ exception handling on embedded platforms by tacos on Monday May 16, 2016 @10:14AM (#11706352)
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.

Re:Size cost of C++ exception handling on embedded platforms by jotux on Monday May 16, 2016 @11:18AM (#11706840)
>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.

Re:Size cost of C++ exception handling on embedded platforms by noonespecial on Monday May 16, 2016 @12:19PM (#11707332)
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.
Re:Size cost of C++ exception handling on embedded platforms by TickleSteve on Monday May 16, 2016 @10:44AM (#11706593)
200KB is way too large for a lot of embedded micros.
Re:Size cost of C++ exception handling on embedded platforms by euyyn on Monday May 16, 2016 @01:50PM (#11708098)
I'm sorry you got downvoted. You sparked a conversation with very interesting information I didn't know myself.
Re:Size cost of C++ exception handling on embedded platforms by Paul_S on Monday May 16, 2016 @02:59PM (#11708698)
I think we have different ideas about what an embedded environment is if a macbook is your reference platform.
Re:Size cost of C++ exception handling on embedded platforms by tacos on Monday May 16, 2016 @05:24PM (#11709751)
"64-bit" and "using Boost" are the clues that I was making a contrasting, not supporting, argument.