[boost] Re: Updated guidelines for libraries with source

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-11-13 13:10:56

John Maddock wrote:
> I've placed a revised version of this document at:
>
> http://freespace.virgin.net/boost.regex/library-guidelines.html
>
> I've added a new section on writing library-build Jamfiles to go
> after the existing text, as well as the suggested changes (thanks).

First, let me make a correction to the file. Under the first paragraph of
Supporting Windows Dlls, you have __declarspec(dllimport) in the last line
instead of __declspec(dllimport).

Secondly, regarding "Counter Argument #2" to the "Preventing Compiler ABI
Clashes", it should be pointed out that if the boost non-library class is
private to the library implementation, there is no problem. However if it is
not, there is a real problem as the counter-example points out.

I think even non-library classes should have ABI requirements, enforced by
using the necessary #pragmas when necessary. I know that many people will
argue that the end user might want, for instance, their own alignment to
prevail when using boost::shared_ptr, but doing this causes endless problems
in the "Counter Argument #2" case unless one wants to specifically tell the
end-user that he must manually set a particular alignment wrapped around a
particular header file. Ugh ! This will not only be something that the
end-user might forget, if let's say his default alignment is different, but
also entails setting a wrapped alignment for headers included by that
header, and the headaches caused by all this are endless, and just not worth
it.

These headaches can be so bad that they virtually eliminate having a
non-library boost construct in the public or protected section of a class
which itself makes up a 3rd party library unless one wants to distribute the
source and let the end-user compile it all with whatever ABI they want. It
will still be a headache for the end-user if he uses a different ABI setting
in a DLL than an EXE, let's say. But not everyone feels obliged to
distribute the source to everything they do.

Because of these problems, I would like to once again suggest ABI for
non-library implementations. If that is not acceptable, because of the
philosophy of allowing the end-user to choose their own ABI in those cases,
I would like to suggest an ABI which gets turned on through the use of a
macro for each non-library system. Then a 3rd party system, whether a Boost
library or otherwise, can tell the end-user to use the macro when
interfacing with their public or protected ( in the case of other
developers' derivation ) implementation which has an instance of that
non-library implementation. In the current way of doing things, I feel I
have to avoid using non-library boost functionality externally for my own
3rd party implementations because of these problems, despite vast admiration
for a great number of boost implementations. This is because my own
philosophy is to take away the end-user's freedom for determining ABI of my
own implementations ( equivalent, in its own way, to Boost non-library
implementors doing the same ), but in turn creating as little headaches and
mischances for the end-user in using my constructs.