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

[David Brown]

Mike Perks wrote:
> David,
> > 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.
> It is not just that. Some C++ compilers/linkers include a large
> runtime for essentially doing hello world. I have never tried avr-g++
> so this may not be true for this compiler. On the other hand the
> Arduino platform uses C++ for its library but I don't know if this
> translates well to smaller devices.
The biggest problem here is often the standard libraries with C++.  They 
are often very intertwined - a simple "Hello world" can pull in all 
sorts of library code for dynamic memory, printf-like functionality, 
RTTI, exception handlers, and even standard template library stuff.  If 
you are lucky, your compiler/linker can avoid some of this.
Fortunately, avr-gcc does not have a C++ standard library - thus 
avoiding the problem!
> > 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.
> My view also is that we should cater the majority of users first. The
>  C++ crowd can verify that the library works in that environment..
> > However, we should at least have the traditional "extern C"
> > wrappers in header files:
> Yep
> > And modules should compile cleanly with the -Wc++-compat flag to
> > make mixing languages easier.
> Agreed. We should at least make sure the code builds and runs with
> the C++ compiler.
> > Any thoughts or opinions?  Is there anyone out there who actually
> > uses C++ for real work and might be interested in this?
> Regards, Mike
It sounds like there is a reasonable consensus, with corelib 
concentrating on C but with clean compiles for C++.  I think a space for 
C++ modules would be nice (such as for Ron Kreymborg's C++ interrupt 
handlers), but it would be a minor part of the project and not an 
initial priority.