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
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
