Re: [avr-gcc-list] using exceptions

[David Brown]

On 01/05/2012 15:04, Georg-Johann Lay wrote:
> Gabriel Dos Reis schrieb:
> > Georg-Johann Lay wrote:
> > > Kövesdi György schrieb:
> > >
> > > > I am using avr-g++ for building my projects for avr and i am
> > > > happy with it. :-)
> > > > But i would need exception support, and could not find how to
> > > > get it work. I found some mails in the archive (dated many
> > > > years ago) about possibilityof building libstdc++ or libsupc++
> > > > with exception support, but could not find how to do it.
> > > > Reportedly it uses 10...20 kbytes of text, which would be acceptable.
> > > >
> > > > Currently i have gcc 4.6.2 sources, and have tried the options
> > > > --enable-sjlj-exceptions,
> > > > --with-exceptions, --with-rtti, --enable-libstdc++, etc... no one
> > > > helped.
> > >
> > > libstdc++ is turned off in configury, for example configure.ac reads
> > >
> > > # Disable libstdc++-v3 for some systems.
> > > case "${target}" in
> > > [...]
> > > avr-*-*)
> > > noconfigdirs="$noconfigdirs target-libstdc++-v3"
> > > ;;
> > > esac
> > >
> > > This is current trunk. There were some changes not very long ago.
> >
> > Would it be reasonable to expect at least libsupc++?
> > That would be a useful start...
>
> IMHO extending what avr-gcc/avr-g++ can do is reasonable and
> appreciated.
>
> However, avr notoriously is short of developers, and if some
> problems pop up, there is nobody who would fix it.
>
> For example, PR50925 could block a build, or it might be the
> case that unwinding does not work properly.
>
> I am not familiar with C++, it's a dreaded language I always
> avoided. If I need to operate on a "big" system, I use Java
> or Python, and I am in the happy situation not to have to
> program big GUIs that base on C++.

I would not go so far as to say that C++ is a "dreaded" language - it 
all depends on how you use it.  If you want to use exceptions, multiple 
inheritance, virtual functions, RTTI, STL, and modern "design patterns" 
for factory functions, singletons, etc., then (assuming someone writes 
the support libraries) your AVR would crawl like a drunken snail.

However, there is a lot of C++ that works without extra overhead.  Basic 
class usage without multiple inheritance and without virtual functions 
is pretty much just syntactic sugar for code you could write in C.  The 
same applies to many other C++ features such as overloading, default 
values, namespaces, templates (which will often replace C macros), etc. 
 C++ was designed with the aim that you don't pay for features you 
don't use.  And the use of C++ structuring can lead to more modular 
programs with less overhead than trying to do the equivalent abstraction 
in C - as well as having better typechecking and static error checking 
than macros.

The kind of C++ that needs the libraries, however, is to deal with 
exceptions, RTTI, and dynamic memory handling - and all of these are of 
questionable value on a small device.  Personally, I think exceptions 
are often of questionable value in /any/ program - it makes it hard to 
see the control flow, as exceptions are a "hidden goto".  They also 
constrict the optimiser - as the compiler has to assume that exceptions 
can occur at lots of different places in the code, causing jumps, 
stack-unwinds, etc., it has far less freedom to re-organise the code for 
better efficiency.

mvh.,

David


> Presumably, exception/unwind support could be made much more
> efficient with avr-specific unwind info, but obviously
> noone ever tried to get it to work.
>
> Johann