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

From: John Maddock (jm_at_[hidden])
Date: 2002-08-17 05:17:37

> 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).

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?

> 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 :-)

> {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)...

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm