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

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-08-15 13:58:45

----- Original Message -----
From: "Peter Dimov" <pdimov_at_[hidden]>
To: "Boost List" <boost_at_[hidden]>
Sent: Thursday, August 15, 2002 2:13 PM
Subject: [boost] std::exception problems on Borland with -ps

> On Borland, <exception> defines std::exception::what() (among other
things)
> as having C calling convention, regardless of the default (specified on
the
> command line.)
>
> When code tries to derive from std::exception (boost::use_count_is_zero is
> an example), it defines ::what() with the default calling convention, and
> the compiler issues an error when the default is, for example, stdcall
(-ps)
> and not C (-pc).
>
> It is possible to work around the problem by surrounding the class
> definition with
>
> #ifdef __BORLANDC__
> # pragma option push -pc
> #endif
>
> // ...
>
> #ifdef __BORLANDC__
> # pragma option pop
> #endif
>
> but is this the "correct" fix? Opinions? (Incidentally, the test framework
> has the same problem with -ps on Borland; it is possible that other places
> in Boost are also affected.)
>
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!)

Here's a description of each option:

-b Make enums always integer-sized (Default: -b makes enums integer size)
-an Align data on "n" boundaries, where 8=quad word (8 bytes)
-Vx Zero-length empty class member functions (notice that the pragma turns
this option off)
-Ve Zero-length empty base classes (notice that the pragma turns this option
off)
-w-xxx Disable xxx warning message

Most of them affect data layouts, so it's hard to know how the std
components will interact with boost code compiled with different options.

It is clear that some sort of compiler-option-synchronization will be
required or that, at least for Borland, only a specific set of compiler
options could be used.

If we go for the syncro route:

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

{note: BCB6 uses STLport by default, were I guess this isn't a problem, so
the fix should check if RW is used}

One approach is to manually identify those boost components which interact
with std components in a way that these compiler options must be
synchronized and wrap it accordingly.
Another more conservative approach, but also quite intrusive, could be to
add to each and every boost header 'pre.hpp' and 'post.hpp'.
This second approach could leave the door open to resolve other global
issues that may arise.

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