I'm always advocating the use of C++ for type saftety, often recommending the <iostream> library. I knew there was a memory (flash and RAM) cost to this but my main platform is the 5272 and I've never run out of resources. Nonetheless, I was curious as to what the actual costs were, so I ran some tests (and need to run some more) but I blogged up the results and was somewhat surprised at what a heavyweight <iostream> is. I thought others might be interested in the results. If you don't want to bother with the full data the summary is: <iostream> will cost you 6.79% of your flash and 3.47% or your RAM on a 5272.
(As an afterthought for those that don't go to the results, it's misleading to single out <iostream> once <iostream> was brought in it seems a lot of the C++ library is brought in. As other libraries like <sstream> and <vector> were used, the memory hits were relatively small. Just bringing in <sstream> looks the same as just brining in <iostream>.)
The cost (in memory) of type safety
Re: The cost (in memory) of type safety
Also note that I believe these require exception handling and this requires run time type identification.
RTTI, is a really big hit.
I really like C++, I use it a lot, but I rarely use the standard C++ template or I/O libraries, as I fnd them to be too bloated for
good code.
Fundamentally if you remove all the extra "Stuff" that is in the c++ standard library streams could be small
and useful.
My "would like to do someday list" has a light weight streams library on the list and a set of nice C++ wrappers for the RTOS features.
RTTI, is a really big hit.
I really like C++, I use it a lot, but I rarely use the standard C++ template or I/O libraries, as I fnd them to be too bloated for
good code.
Fundamentally if you remove all the extra "Stuff" that is in the c++ standard library streams could be small
and useful.
My "would like to do someday list" has a light weight streams library on the list and a set of nice C++ wrappers for the RTOS features.
Re: The cost (in memory) of type safety
As you probably expected, and as I've been warned before, you can't do anything useful with iostream on the MOD5213. By simply including it in my current project, I went from 32% of flash to a 150K overflow.
Re: The cost (in memory) of type safety
Paul,
Just so you know I did not clear the misc. setting for NoRTTI handling. It could be I'm paying most of the cost for it anyway. For the tests without exceptions I had the No exceptions handling checked, but when i added the exception testing I unchecked it.
I also wonder about Templates, they get a bad rep for code bloat but whenever I've used them I haven't seen much RAM or Flash increase (assuming I'm using the C++ lib already) and they can be really really convenient and make for easier maintenance of code. Everything I read says the STL and C++ libraries are extremely efficient and should be used whenever possible. Of course most literature assumes you aren't in a limited memory environment.
It would be nice to have lightweight output streams it it meant we could use those features on chips like the 5213, but I'd vote for RTOS C++ wrappers first. (and second I'd vote for classes for the SerialPort, TCP etc, even though I already have my own).
Just so you know I did not clear the misc. setting for NoRTTI handling. It could be I'm paying most of the cost for it anyway. For the tests without exceptions I had the No exceptions handling checked, but when i added the exception testing I unchecked it.
I also wonder about Templates, they get a bad rep for code bloat but whenever I've used them I haven't seen much RAM or Flash increase (assuming I'm using the C++ lib already) and they can be really really convenient and make for easier maintenance of code. Everything I read says the STL and C++ libraries are extremely efficient and should be used whenever possible. Of course most literature assumes you aren't in a limited memory environment.
It would be nice to have lightweight output streams it it meant we could use those features on chips like the 5213, but I'd vote for RTOS C++ wrappers first. (and second I'd vote for classes for the SerialPort, TCP etc, even though I already have my own).