|
From: | David Brown |
Subject: | Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc - C++ |
Date: | Mon, 21 Sep 2009 09:40:12 +0200 |
User-agent: | Thunderbird 2.0.0.22 (Windows/20090605) |
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" { #endifAnd 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
[Prev in Thread] | Current Thread | [Next in Thread] |