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

From: John Maddock (jm_at_[hidden])
Date: 2002-08-21 05:31:16

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

The standard libs contain proprietry code, Borland doesn't want to let you
rebuild them - it's a trade secret not open source code.  BTW the IDE
defaults and the values used by the standard lib are exactly the same, the
#pragma's are in the headers so that if you change the defaults for your
code, it won't then go and crash due to a binary incompatible standard lib.

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

Not true, STLport also does a:

# pragma pack(push,8)

for VC6 and Intel C++

These compilers have these pragma's in place, not because they do anything
"wrong", but because the compiler has options that effect binary
compatibility, *and* pragma's that allow you to control that in code.  Many
compilers have the former, but not the latter, so the "fix" isn't possible
for them.  There is also a difference in expectations here: most Win32
compiler users expect the libraries they are using to be automatically
selected for linking based on the headers included, and for these libraries
to work regardless of what compiler options they select.  The same is not
true for Unix compilers, which tend to be a little more primitive in this
area IMO.

Anyway, we're getting off topic :-)

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