Re: [boost] std::exception problems on Borland with -ps

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-08-20 10:44:07

----- Original Message -----
From: "John Maddock" <jm_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, August 17, 2002 7:17 AM
Subject: Re: [boost] std::exception problems on Borland with -ps

> > Hmmmm... I'm afraid that you've discovered a potentially bigger problem
> with
> > Borland:
> >
> > Looking at every (or almost every) header in the RougeWave SCL
> > implementation that ships with Borland, you can see that they all start
> > with:
> >
> > #pragma option push -b -a8 -pc -Vx- -Ve- -w-inl -w-aus -w-sig
> >
> > This pragma is beyond any conditional compilation, so it is **forcing**
a
> > lot of global compiler settings, beyond the calling convetion.
> > (What were the RW guys thinking when they wrote this?!!!! At least they
> > could have factored it out in a separate header!)
>
> You are overstating the case here: Borland had to add these options and
they
> are correct, and are present in the STLport lib that ships with Builder 6
as
> well.
>
> These options are scoped with:
>
> #pragma option push
>
> // code here
>
> #pragma option pop
>
> and only affect declarations in *that header* (they do not effect boost
code
> or change the defaults).  They are necessary in order to ensure that the
> objects defined in the standard lib headers have the same object layout
and
> calling convention as the standard lib archive being linked to.  Possibly
> those boost libs that are compiled into .lib files should do the same as
> this (regex does BTW).
>
OK. I overreacted; but I still think that there is something wrong here,
though on second thought, the fault is not on RW but on Borland.
IMO, ensuring *general* binary compatibility should not be done by fixing
data-layout options in source code. This should be the case only for
extraordinary cases, like data which must be externally managed (by other
languages).
Therefore, the IDE defaults should have been made to reflect standard
library requirements.
I know that this is not the case becasue of the VCL, but then, I would have
liked if Borland would have made VCL compatibilty the alternative, not the
default.
Then I understand that this is a problem with the incorrect choice of IDE
defaults, not with RW implementation.
In any case, If *I*, the user, need a different layout (say -a4) I should be
able to rebuild the SCL libs accordingly.

> On the issue of exception classes: why would you think that the derived
> class could possibly use a different calling convention to the base class
> for a virtual function?
>
Can't tell because I didn't say anything about it. :-)

 > It is also clear that this synchronization would be required in more than
> > once place, so I suggest to factor this out in 'pre.hpp' and 'post.hpp'
> > headers (or some names like that).
> >
> > pre.hpp
> > ~~~~~
> > #if defined( __BORLANDC__) && defined(_RWSTD_VER)
> > # pragma option push -b -a8 -pc -Vx- -Ve-
> > #endif
> >
> > post.hpp
> > ~~~~~~
> > #if defined( __BORLANDC__) && defined(_RWSTD_VER)
> > # pragma option pop
> > #endif
>
> That usually generates a whole slew of warnings, that's why Borland put
the
> options directly in the headers :-)
>
Aha... I see.
Isn't the *need* for turning warnings off a clear indication that there is
something wrong?

>
> > {note: BCB6 uses STLport by default, were I guess this isn't a problem,
so
>
> > the fix should check if RW is used}
>
> The standard lib used is irrelevent in this context (honestly)...
>
You are right.

BTW, I've looked at STLport's "_prolog.h". You can see that the fixed layout
options are used *only* for Borland.
I take this as an indication that fixing those options in source code is
wrong, and that the SCL implementers had to do it because of Borland's
fault.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com