Re: [boost] [Serliazation] Thread-safety again

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