Re: Re: Re: Re: boost::signals build and C++Builder 6 Pro in 1.29.0

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-03-06 17:50:04

Peter Dimov wrote:
> Edward Diener wrote:
> [...]
>> Again John Maddock has used these #pragmas extensively in Regex++ to
>> avoid data layout problems and I have used them in my libraries for
>> the same reason, including my own components built on top of Regex++,
>> and I have never encountered problems with them.
>
> The issue is less clear-cut than you make it seem.
>
> What we have here is a static library (Signals) that uses several
> header-only libraries (shared_ptr, Function, maybe others.)

OK, I do see this problem.

>
> To "fix" the "alignment problem", we need not only #pragmify Signals,
> but those other header-only libraries as well. Furthermore, we need
> to be careful to not miss a header-only library that is used,
> directly or indirectly, by Signals, or any other static library.

I view it this way. The people who create libraries, whether header-only or
implementation, should be responsible for setting reasonable data layout
details. After all, as I have previously mentioned, Borland sets data layout
#pragmas for all of their RTL code even when the header is a class template,
and therefore likely to be a header-only implementation.

>
> This impacts not only Signals users; it also affects those that only
> use header libraries. They don't need the "fix", and some of them may
> legitimately object to the binary compatibility settings that the
> headers have inflicted on them, especially if these settings lead to
> slower or larger code.

Yes, I agree in theory. But compiler implementors do do this and I don't
think they really get complaints saying "Gee, I don't like your pack
alignment for your XXX class. It's really slowing me down."

>
> The alternative is simple: always build libraries and applications
> using the _exact same_ settings. This is a good general advice, and
> it also applies to settings that we cannot "fix" using the #pragma
> method.

I don't think the alternative is simple.

Do you feel good forcing end-users of Boost to build their applications
according to what settings you specify ? And what happens if another 3rd
party developer tells their end-users that they must build their
applications to settings they specify and it is not the same as the Boost
settings ? And what if the end-user needs to change from the Boost settings
for their own purposes ?

Dictating to the end-user what you insist his settings must be in order to
use libraries effectively is not my idea of a simple or good alternative.

I recognize that you have brought up valid points, but I would still much
rather protect the end-user against inadvertent data layout problems if they
change their own global settings than worry that they might not like the
data layout I set for my own classes.