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

From: David Abrahams (dave_at_[hidden])
Date: 2006-12-16 17:13:34

"Robert Ramey" <ramey_at_[hidden]> writes:

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

"Whether the type is explicitly referred to" is completely irrelevant.
The question is whether any objects or functions from the translation
unit containing the EXPORT are used.

Did you intend that proper registration occur even if no objects or
functions from the translation unit containing the EXPORT are used?

> That was my goal and I believe it has been achieved for all
> compilers that boost supports.  

I would be very surprised if that were the case for Metrowerks; as
pointed out by Emil, that compiler is very good at optimizing out
unused translation units.

> In order to accomplish this I resorted to compiler specific syntax
> not described by the standard.

Not for every compiler... and there is no guarantee that the next
version of GCC or MSVC won't apply the optimization more aggressively.

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

No, I don't think that is the question at all, at least, not mine.  My
question is what promises you can legitimately make to users about
what will happen, and whether you have made your promises sufficiently
explicit.

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

That's a legitimate thing to do, but I think you need to be very
explicit about what you're doing.

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

I would be very surprised.  Do any of your tests actually exercise the
case where the EXPORT is in a TU with no used functions or objects?

> - its just not guarenteed to be portable to new compilers.

Or new versions of existing compilers.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com