Re: C++ compiler on Embeded Platform

arnuld wrote:
On Tue, 06 Oct 2009 08:56:09 +0200, David Brown wrote:

..SNIP...

"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.

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.


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).

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.

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).


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).


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.

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.


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).

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


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

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


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.

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


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!


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

It never worked with me.


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.


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.

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 ?)
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++ -

So true, it has been my experience too.



.

Quantcast