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

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-01-03 15:35:05

Emil Dotchevski wrote:
>>>   Did you intend that proper registration occur even if no objects
>>>   or functions from the translation unit containing the EXPORT are
>>> used?
>>
>> Hmmm - there are a couple of things going on which are a little
>> confusing:
>>
>> a) instantiation of code to serialize data type T with archive A.
>> This may include
>> (I forget the exact names) basic_archive_serializer<A, T>.  It was my
>> intention that
>> this code be instantiated for all combinations of archive types and
>> data types
>> actually used and no others.  This the fundamental function of
>> BOOST_CLASS_EXPORT
>
> How does BOOST_CLASS_EXPORT help me if I have my own archive
> serializer?
> Even if I'm using one of the archives the library provides for me, I
> think that it is unreasonable to automatically register all
> combinations of archivers and types because it introduces physical
> coupling between translation units which don't depend on each other
> (in a program where only one archive type is used, which is typical.)

All combinations of A and T actually used - and only those combinations -
are used to instantiate code.  That is, there is not dead code generated
all required code IS instantiated.  Daves implementation of this facility
(unlike my previous one) does NOT depend on knowing in advance
which archives classes might be used. It just works.

>> b) construction of an instance void_caster for each pair of types B
>> and D where
>> D is B is a base class of D.  This is the function of ..
>> BOOST_SERIALIZATION_BASE_OBJECT_NVP
>>
>> c) construction of an instance of extended_type_info for type T
>> which is used to support
>> the above.
>>
>> So, if I make a program which loads objects of derived class D
>> through a pointer to
>> base class B  I will need the above described code to be
>> instantiated even though
>> no calls the the functions in the header containing EXPORT are
>> explicitly made.
>
> This discussion is not about whether or not we need those templates
> to be instantiated; of course we do.

>
>>>> So the extended type info table has to be initialized with all the
>>>> types that might be in the archive.  This is what export attempts
>>>> to do.
>>>
>>> It doesn't do enough, and there is no portable thing it can do that
>>> would be enough.
>>
>> Hmmm - well it does work.  But I DID have to include "_export" - non
>> portable construct to make it work - that is the function of the
>> "force_include.hpp"
>> header.
>
> It does work until it doesn't. In several projects I have worked on,
> I have seen similar systems relying on "auto registration" to fail
> due to seemingly unrelated changes in the code base, or when the code
> is ported to another operating system or platform. The only compiler
> I have observed to not deadstrip such code consistently is MSVC.

That's what I found when I tested it.  I addressed it in the only way
I could figure out how to do it.  Now it turns out that its not portable
according to the standard - and can't be made so.  So you have two
choices - use an alternate facility (explicit registration) which is 
provided
or not.

> I still think that whether it works or not is irrelevant if the
> documented behavior can not be delivered within the limits of the C++
> standard. In my mind it only works because the compiler is not smart
> enough.

> I don't think it is a
> good idea to rely on implementation-defined behavior.

Not everyone shares that opinion.  For example, anyone using dynamic
loading of DLLS can't be sharing that opinion.

> If we insist
> that we rely on it, we should clearly state that the behavior is not
> portable and has only been tested on such and such
> compilers/platforms.

We've agreed to do this.

> In my opinion the "auto registration" should be removed from the
> serialization library altogether, and replaced with an example
> demonstrating how it could be done, provided that your compiler
> doesn't dead strip this kind of code even though it is allowed to.

LOL - remember the only reason EXPORT is even in there is because
it's absense was considered a "show stopper" to getting the library
approved.  So your idea is wildly unrealistic.

Of course there's nothing to prevent you from stripping the EXPORT
functionality from your own copy.  But then, that would be the same
as just not using it.  So it's wierd to me that you think we should
prohibit other users for using parts of the library for things that
the C++ doesn't address.  How does this prevent you from
using the library in the way you feel is appropriate?

Robert Ramey