Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-12-15 22:13:52

David Abrahams wrote:
> "Emil Dotchevski" <emildotchevski_at_[hidden]> writes:
>> Or did I completely misunderstand the documentation? Robert, was the
>> intended meaning that *if* you explicitly call a function from
>> foo.cpp, then using the class export macro guarantees that class foo
>> is properly registered with the serialization library?

My intention is and was that proper registration will occur whether or not
the type is explicitly referred to. That was my goal and I believe it has
been achieved for all compilers that boost supports. In order to accomplish
this I resorted to compiler specific syntax not described by the standard.

Now it seems the question being raised is whether this is/was the right
thing to do.

For me the answer was easy. The comments in the first review made it clear
that this was a feature considered necessary by a significant number of
users. Given that I had set the goal of getting this library into boost, I
felt I had to find a way to do it. This is re-inforced by my feeling that
using the export macro is the way that most users prefer to address this
issue. This permits better scalabilty and automatic registration of those
and only those types included.

So the question is - what do you tell those users who want this?

Its not really a C++ question but a more general and interesting one. What
is a library writer to do when the language standard conflicts with the way
you and/or your target audience want to do things? In some cases, you stick
to the standard and suffer some inconvience in order to guarentee
portability. In other cases - portability is not a requirement. In this
case I "squared the circle" by "solving the issue" for each compiler in a
different way so that its "portable" between this subset and still
considered convenient. Was this the wroing decision? Should I have tried
harder to say - You shouldn't want that facility because it's not going to
be guareteed to be portable. I tried that and it didn't fly. Writing a
library that hopes to become the most widely used in its class is about a
lot more than adhering to the standard. This is reflected in some aspects
of the serialization library. I would wager that this is not the only one
that has done this.

> That is certainly the only correct way to document it unless we find
> other means to make that work.

I would say it has been made to work - its just not guarenteed to be
portable to new compilers.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at