Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc - C++

[David Brown]

Ruddick Lawrence wrote:
> This conversation is continued from the avrfreaks forum posting here:
> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=84072.
> Basically, we were talking about how best to create a maintained version of
> the functionality in the Procyon AVRlib, and whether there's a place for
> such code in avr-libc.

Another branch for another question...

Has there been much thought given to C++ support?

There are some people who believe C++ is evil, and sneaks in all sorts 
of inefficiencies and code bloat behind your back.  It is certainly very 
easy to write bloated C++ code with class hierarchies so complex they 
defy understanding, and each class does nothing except pass 
responsibility on to other classes.

However, there is also a certain proportion of embedded developers who 
see C++ as an essential, and there is little doubt that avr-gcc is a 
good and solid C++ compiler (though it doesn't have library support for 
exceptions or RTTI, AFAIK, and does not have an official maintainer). 
The beauty of gcc is that avr-gcc gets most of C++ support for free.

There are not many avr-gcc C++ users at the moment - certainly not 
compared to C users (I am a mere C++ dabbler myself).   However, I 
wonder if the time has come to start looking at it more closely.  With 
care (and it does take a lot of care), it is possible to put together 
C++ classes and templates that will give at least as good generated code 
as C functions while keeping neat APIs.

For example, consider an SPI interface as discussed earlier.  With C, we 
are faced with a choice between including an "spi bus number" parameter 
in every function (leading to more verbose, larger and slower code on 
AVRs with 1 SPI bus) or having different APIs for single-bus AVRs and 
multiple-SPI-bus AVRs.  As a compromise, some macros and inline 
functions could be used as wrappers, along with conditional compilation 
to end up with optimal code in each case.  With C++, these macros and 
conditional compilation can be templates and classes, and the API stays 
neat and consistent.

Obviously I would not want to see C++ modules instead of C modules - any 
C++ support would be in addition, and somewhat of a side project.

However, we should at least have the traditional "extern C" wrappers in 
header files:

#ifdef __cplusplus
extern "C" {
#endif

And modules should compile cleanly with the -Wc++-compat flag to make 
mixing languages easier.

Any thoughts or opinions?  Is there anyone out there who actually uses 
C++ for real work and might be interested in this?

mvh.,

David