changes for C++ constructors on psim

[Ralf Corsepius]

On Fri, 2004-05-07 at 08:20, Chris Johns wrote:
> Ralf Corsepius wrote:
> > 
> > Sorry, no. We had been using <iostream.h> on purpose, because <iostream>
> > is a feature having been added by newer C++ standards, not being
> > supported by older C++ compilers.
> > 
> 
> This is to bring the test in line with the current standard which seems 
> like a good idea.

No problem with me ;)

> > * <iostream> is not supported by older compilers (e.g. gcc < 3.0)
> > => using <iostream> means giving up gcc < 3.0

> > => Trying to use <iostream> will make further steps inevitable.
> > Possible steps:
> > * Rely on <iostream> and let building fail otherwise (I.e. abandon gcc <
> > 3.0)
> 
> Seems ok with me. Can you build RTEMS with older versions of GCC (<3.0) 
> now ?
I don't know ;)

I am pretty certain the C-parts build. I am quite sure C++ builds for
most targets, but I would not bet if C++ works. 

> My understanding is you could not for other reasons such as movement of 
> system header files.
Well, this isn't the real problem with RTEMS and C++.

Off hand, IIRC, the only c++ system header the RTEMS source-tree uses is
the <iostream> inclusion in cdtest, we are discussing here. cdtest is
"just an application" and not part of the actual OS. So this doesn't
have much impact on "The RTEMS OS" and the "RTEMS API"

The actual C++ problems are elsewhere:
* Interfacing RTEMS memory management to libstdc++/g++ (The static
constructors issues)
* Interfacing RTEMS to libstdc++/g++ (libstdc++/config/*)
* Frequent general changes to internal of libstdc++ in GCC (E.g.
remember the atomic locks).
* Interfacing GCC's c++ to its target low level backends (Most of the
problematic parts we are discussing here, actually are implemented at
the lowest level in gcc).

I.e. the actual problem with C++ and RTEMS is not C++ code but the C++
implementation details in GCC itself and implicit assumptions BSPs make
on compilers' behaviors.

ATM, it's static constructors again (Yes, we've had this issue before,
IIRC, between gcc-2.95.x and gcc-3.0), it had been RTEMS thread support
and architecture specific locks in libstdc++, and I would not be too
much astounded if resolving the libstdc++/config/* warnings in gcc >=
3.4.0 might have one or more surprise lurking ;)

> > * Stay with <iostream.h> and live with the warning. Confusing to users,
> > the least problematic approach until somebody wants to use a compiler
> > without it (i.e. until gcc abandons "backward" headers - AFAICT, even
> > gcc-3.5 still has them, and I don't recall having read about a
> > time-frame to finally abandon them)
> 
> Not too concerned which way this one goes.

OK, I'll look into this.

Ralf