C++ STL in embedded systems

std::vector::reserve() only functions to speed things up; it doesn't have an effect on the result of the program. Likewise, I might do this:

void Increment1( int& i ) { const volatile n = 10; i += n; i -= (n-1); }

void Increment2( int& i ) { ++i; }

These two are logically equivalent (i.e., they do the same thing), but the second is almost certainly more efficient.

Cheers! --M

Oops. That should have an "int" thrown in there.

|| std::vector::reserve() only functions to speed things up; it doesn't

|| have an effect on the result of the program. There to speed things up but doesn't affect the result of the program!! Not just bear with me. You're saying that if I opt not use reserve the end result (i.e the benchmarks) would be the same?

're-location' is a constant 'concern/gripe' when viewed from - what seemingly is the most popular container. i.e the Vector. INMHO, it's a much ado about nothing if you have a member function like reserve. That said, if you opt _not_ to reserve, you're faced with the copy/destroy/re-create saga. With your example 'benchmarks' will be - for the most part - comparable. I'm not seeing how the benchmarks will be comparable if he chose to call reserve ahead of time.

Time to pull out the compiler :)

No, I'm saying the sorted output of the program would be identical.

Increment1() and Increment2() are identical in function (i.e. logically the same) but different in implementation, which translates to speed of execution for our current context.

Cheers! --M

I did face few issues when introducing STL in a vxWorks based system.Major problems were:

- significant code bloat

- incomplete STL support by the specific vxWorks version that we were using. There were scores of linking errors whenSTL was used.Had to make modifications to the STL header files to make it work.

- no concept of namespace on vxWorks (Everything happened to be in default namespace)

But probably these issues are specific to vxWorks (and that too to a particular version of it) and may not hold true for embedded system in general. But Code bloat was definitely a problem and I found many resources on Net which confirmed this problem of using STL in embedded systems.

|| But probably these issues are specific to vxWorks || (and that too to a particular version of it) and may not hold || true for embedded system in general

How long ago was this? I'm using vxWorks (Tornado IDE 2.2.1) - STL and all. Doing FFT/IFFTs and Boundary Element Math withough a hitch.

|| But Code bloat was definitely a problem and I found many || resources on Net which confirmed this problem of using STL in embedded || systems. Is this relegated to 'embedded systems'? Furthermore, how do you measure this 'code bloat'? I'm curious.

With all due respect. I think today (my experience) - this notion of issues pertaining to STL usage in embedded systems is much ado about nothing (lots of smoke and mirrors). My _real_ problem, is being stuck with gcc 2.96. Beyond that. I've had no issues. Of course I haven't measured code bloat yet but we'll see.

In general, you can't give a simple answer to such questions. The specifics of how your particular embedded system works are going to, in the extreme cases for various features, be the choke point.

Consider a case where, for hardware reasons, you needed to limit the amount of RAM on your system to the absolute smallest possible amount. Anything that produced an extra temp variable, an extra chunk of something shoved on the stack, etc. etc., would be hard to accomodate. In such a case, it might be easier to get your job done in some other language than C++. Possibly assembler, for example. Though as time goes by, the amount of RAM available on most hardware is increasing. I recall a project from many years ago where an industrial monitor (radiation hand and foot checker) had a very small amount of RAM, like 128 bytes or some silly small number. Trying to fit a C++ prog into such hardware would have been tiresome. RAM is much cheaper these days. The latest version of this device has a huge whack of RAM.

Other considerations: Suppose the system cannot require human intervention, or human intervention is expensive in some way. In such a case, a "bullet proof" implementation that won't crash, won't leak resources, etc., is going to be a big concern. A good implementation of the STL will look pretty good in such cases, as compared to a roll-your-own set of containers. So will reading the series of books "Effective C++", "More Effective C++", and "Effective STL" (though I may have munged the titles).

There are many other possible concerns. For example: You need a compiler that outputs optimized code for your hardware. This is crucial above all else. If the code won't run on your hardware, there's no point worrying about what library to use. So, if your compiler has limits (not unusual in the case of hardware specific compilers, though getting better) you should start with your list of possible compilers, and figure out what is possible from that. If the only compiler available is an older non-compliant one, you may have trouble getting a good STL implementation to work on it. I recall another project from many years ago where the only compiler that would output code for the hardware was a C compiler. And an old (1988 or so) C compiler at that. Tiresome.

What other libraries are required for the project? If it's a specific chunk of hardware, chances are there is an API kit provided by the manufacturer. The advantages of using such a kit may outweigh the advantages of using the STL, supposing you can't use both. Though, again, as time goes by most hardware makers are supporting the STL, and more modern implementations of it.

There are many other possible considerations. For example, if you explore these issues, the client might be convinced that the extra RAM might be worth it in order to be able to shorten the development time. Or to be able to do the development in C++ rather than assembler, and so be able to provide lots of new sexy features in the same development time. Socks

The relocations don't matter from a *logical* standpoint; i.e. from the standpoint of *what* the program will do when executed. Sure, it matters a great deal from a *practical* standpoint, i.e. in terms of real-world performance, but that's not the same thing.

-- Mike Smith

No, but the *output of the program* would be the same. That's what was meant by "logically redundant"; i.e. the difference is a *practical* one, not a *logical* one.

-- Mike Smith

...

It would be nice if there were alternative implementations of the containers (especially map/set) where most of the code was non- templated and used void * and function pointers heavily. The templates would just be a type-safe veneer. Seems like this approach would be a little less fast but could greatly reduce bloat (in those bloat-sensitive situations).

Has anyone tried this?

|| Many embedded C++ compilers ship with this library.

Interesting. Went off and familiarized myself with Dinkum EC++. This in part, because I recalled having a conversation with the vendor and he seemed overly enthused about the fact that the lastest release of their development environment used 'Dinkumware'. To that end, he offered me a trade + extra cash. Trouble is, I tend to be a little skeptical of a sale person who doesn't do a good job of explaining to me the ' embedded ' in the embedded version of the Dinkumware C++ compiler.

Curiousity question. What's in a name - 'Dinkumware'?

Short answer -- we spent a year in Australia. A good friend of mine organized a visiting post for me at University of New South Wales. Besides, we've always liked Oz. "Dinkum" is Aussie slang for genuine, honest, or true. I thought it was a good name for a company that made good software. (The Limited part is to keep us humble.)

Longer answer -- One term I taught a graduate seminar in software engineering. (I called it Remedial Software Engineering.) We had a running case study on Dinkum Swill Pty. Ltd., a company that supplied hog swill for most of NSW. The students found some fascinating, and sometimes gross, uses for computers in the production of hog swill.

A few years later, I found myself negotiating with the likes of Microsoft and IBM for the licensing of the C++ library I'd been developing. My wife Tana did not want me signing contracts with such big players as a sole proprietor (quite rightly). So she founded a company for us. I wanted to call it Dinkum Swill, but she would have none of it. (Imagine sitting at a rosewood conference table explaining to a bunch of suits where the name came from.) She was willing to settle for Dinkumware, Ltd.

That was ten years ago.

HTH,

P.J. Plauger Dinkumware, Ltd.

If you are wondering about microsoft's evc++ 4.0 and above, the simple answer is, they don't provide one due to yada yada reasons. Every platform has its own library, and their MFC has a memory leak. You can possibly get sources for the STL and compile them with each library for each platform that you are working for. But it is not clear if evc++ is truly standards conforming.

If by STL you really mean the Standard Template Library, then most versions of eVC++ contain pretty complete implementations. (Ours, of course.) What Microsoft has managed to do, for mysterious (yada yada?) reasons, is butcher the combined C/C++ library in bizarre and inventively different ways for each release of eVC++. We have a tidy side business replacing the missing bits for those who need better code portability between desktop and embedded versions of the same compiler family.

P.J. Plauger Dinkumware, Ltd.