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

[David Brown]

Weddington, Eric wrote:
> > -----Original Message----- From: 
> > address@hidden 
> > [mailto:address@hidden org]
> > On Behalf Of David Brown Sent: Monday, September 21, 2009 1:40 AM 
> > To: address@hidden Subject: Re: [avr-libc-dev] Adding
> > (some) Procyon AVRlib functionality toavr-libc - C++
> >
> > Ruddick Lawrence wrote:
> > > This conversation is continued from the avrfreaks forum
> > posting here: 
> > http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopi 
> > c&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?
>
> If you go to the Help Wanted section on avr-libc, you'll see that
> we've posted an ad for a C++ maintainer: 
> https://savannah.nongnu.org/people/?group=avr-libc This was posted in
> December 2004 and we still haven't had anyone interested in helping.
> At least yet.
>
> C++ is not Joerg's nor I's strong suit. Hence our request for
> additional help in this area.

It's not my strong suit either - I've just been trying it out.  I've got 
very mixed feelings about C++ - on the one hand, I see potential for 
making some types of code much clearer and neater at source, as well as 
having smaller and faster generated code.  On the other hand, there is a 
high potential for making truly awful code, with source code that is 
impossible to understand and object code that takes tens of KB to do 
virtually nothing (pun intended).  I've seen both types of C++ code. 
And whoever thought of the C++ syntax for templates and "new-style" 
casts should be forced to use a 300 baud DECWriter so that can understand C.

> > However, we should at least have the traditional "extern C" 
> > wrappers in header files:
> >
> > #ifdef __cplusplus extern "C" { #endif
>
> Yes, definitely.
>
>
> > And modules should compile cleanly with the -Wc++-compat flag to
> > make mixing languages easier.
>
> I have no objection to this.

I also think there should be a lot more warning flags used, but that 
should maybe be another branch of the thread...

> I don't think that we're quite ready to build the corelib in C++. At
> least we should stick to C in the short term just to get a product
> out. However, I have no objections to doing things now that will make
> it easier for future C++ work (like the 2 items above).

Sounds good.  I certainly don't think (at this stage, anyway) C++ should 
be required for corelib most functionality.  But if there are people 
interested in writing and using C++ modules, it will be nice to have a 
place for them, at least in the longer term.