Weddington, Eric wrote:
-----Original Message----- From:
avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org
[mailto:avr-libc-dev-bounces+eric.weddington=atmel....@nongnu. org]
On Behalf Of David Brown Sent: Monday, September 21, 2009 1:40 AM
To: avr-libc-dev@nongnu.org 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.
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
