C++ compiler on Embeded Platform

If you read the faq on McDonald's website, they probably won't tell you that living off hamburgers is bad for your health. Stroustrup wrote C++

- he's not exactly an unbiased and independent source! (Actually, he does write some interesting stuff, and his C++ books are some of the very few that really get the point of the language.)

"Embedded" can mean very different things to different people. If you are talking about "embedded pc", then C++ would be a good choice, although a higher-level language such as Python might be better. If you are talking about an 8-bit microcontroller, then you must be much more careful.

Features like classes, strong typing, overloading and namespaces are basically "free" with a good compiler. Templates can be good, or can quickly lead to a great waste of space if you are not careful. Virtual thingies (inheritance, methods, whatever) involve a number of layers of indirection and often cripple a compiler's optimiser, and are thus very costly, as are RTTI and exceptions for related reasons. Heap memory - in particular, freeing memory - is also often a big problem on small systems.

If you are running on a small cpu, you have to think about how the compiler will actually implement the software you write. When you do that, you can see what parts of C++ (and C as well - most small embedded systems avoid things like printf and malloc) make sense to use, and what parts are too costly.

As a general rule, much of what you find in ready-made C++ code is aimed at "big" systems. The STL is fine if you have oodles of megabytes of code space and a processor with an MMU (to avoid memory fragmentation issues). Your 2KB "Hello world" can quickly turn into a 200 KB monster just because you've used an STL vector, bringing in exceptions, input/output formatting, etc, etc. If you are expecting a final program measured in MB, then that's okay - you get a lot of code reuse here. But if you are aiming for a small embedded system, it's probably not the way to go.

Nitpick - g++ is part of gcc, not a separate compiler. You compile a C++ program with "gcc main.cpp".

I should probably have read that paragraph first... but I'll leave my comments above about small embedded systems for interest and argument among other c.a.e. readers.

Once you are at the size of something *nix based, you are using a "big" embedded system and the extra cost of C++ features is a minor issue. The reason you must use C and not C++ is thus "because the boss said so", rather than because the language is unsuitable for the platform, or because of tools (gcc handles both languages).

The question then is why the powers that be have decided on C. If you are doing very low-level work, such as working with Linux kernel modules or on hardware drivers, then C is typically a better fit with the existing software - and as you are trying to keep your code as small and fast as possible, C++ brings you very little benefit.

One good reason for avoiding C++ is that it is very hard to write truly good C++ programs, and very easy to write truly hideous C++ programs. And the majority of C++ programmers are very bad at C++ - they either think of OO as a sort of add-on to C rather than a way to structure their software, or they go totally overboard with their templates, classes, multiple inheritance and virtual thingies so that the code is full of hundreds of classes which do nothing but pass responsibility on to other classes.

Well, I don't have much idea about that except that a few moments ago I was told that the embedded platform my company is targeting may not have any C++ compiler available. They will definitely have gcc.

Actually, I will never ever write OOP based code. My opinion may be biased, I don't like OOP and I don't see how it is useful in majority of problems. In case of C++, I always worked with either Procedural style or the Generic one (the templates).

aha... here is what I have been told:

(1) Use as much printf()s as you can for debugging purposes but code will be shipped with no printf()s.

(2) don't use malloc() unless it is absolutely necessary.

(3) The RAM available will be around 64-128 MB.

(2) The final executable should be less than 1 MB

It never worked with me.

I am working mostly in Socket Programming, all of those TCP/IP things. My work does not include kernels or device drivers (they are at much lower level than Sockets ?)

So true, it has been my experience too.

What's the target? I don't know off-hand of any gcc target that does not support C++. There are some that do not have the necessary libraries for full C++ support (for example, avr-gcc does not have the C++ libraries - you can use things like classes and templates, but not exceptions or RTTI without the library).

However, it is quite possible, and not uncommon, to build binaries of gcc without supporting C++. When you build the binaries, you can choose the languages to support (C, C++, ObjectC, Fortran, Ada and Java are standard options these days).

C++ can be used in many different ways - that's part of its power, and also the source of a great deal of confusion and mixed up programs (especially if there are several developers involved).

I avoid printfs entirely. Sometimes you can make use of printf-style debugging, but remember that it will significantly affect the performance of your code, and that is often a big factor in small systems. You have to test and debug your *actual* code, not just test code (though test code is useful too).

That's often important in small embedded systems, although it's really "free" that must be avoided most.

That's a factor of about 10000 beyond what I'd call "small" embedded systems. I personally would not shy away from a malloc if I had 64 MB free.

You can have 64 MB ram, but only 1 MB code? That's a little bit odd, but you know your requirements better than I!

Calling "g++" will treat ".c" files as C++, while "gcc" will treat files as C++ only if they have an extension like ".cpp", ".cc" or ".cxx". It's possible that using "g++" will pick slightly different libraries or include directories by default.

As soon as you make a 'struct stack' along with a function 'push' and a function 'pop', that's already OOP. Now just wrap it into a (template) class, done. OOP doesn't mean virtual functions, and lots of useful things can be done without those (and those that need virtual functions are probably more elegant in C++ than in C).

C++ makes it easy to produce bloat by accident. In C, you have to actually write the bloat by hand, so your program binary probably will be smaller.

I avoid 'malloc' mainly for the reason to be able to make any well-founded claim about my memory usage. If everything links correctly and the program starts up, I can be sure it runs. If it uses 'malloc', I can never be sure that it will always succeed.

Unfortunately, avoiding 'malloc' also rules out most of the C++ library. Hence, I'm generally using own statically-sized containers, for example a 'template class Queue' for a ring-buffer- style queue containing at most Count items of type T.

Depends. For critical stuff like device drivers, file systems, etc? No malloc. For application layer? When it needs dynamic things, use malloc as you please. But if it's easy to do without malloc in the application, I'll take that extra bit of robustness as well.

Could be a result of flash or startup time requirements. My requirements are similar. But I'm allowed to use C++ :-)

I'm quite certain that "g++" links different libraries, but details depend upon the version.

Stefan

obviously you will need a macro wrapped printf to get rid of it easily

plenty of RAM

this limits you somewhat

What is the target CPU?

Good luck trying to use a C++ compiler without the libraries I think that would be a lot of work in the long run trying to satisfy the link dependencies.