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

From: Edward Diener (eddielee_at_[hidden])
Date: 2002-08-17 11:23:01

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:002901c2447f$0b993300$1d00a8c0_at_pdimov2...
> 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.)

Yes, this is the "correct" fix and should be used with Borland and all Boost
libraries which need to set an option for that particular library. This
ensures that no matter what options the end-user sets when using a library,
the binary image in a library will correspond to the object which the
end-user instantiates no matter what options the end-user sets from the IDE
or command-line when using that library.

Borland uses this technique for all of their RTL headers ( and VCL headers
but that's irrelevant here ), so that the library is insulated from end-user
changes.

John Maddock already uses this technique in his Boost Regex++
implementation.