Re:[boost] Re:[serialization] scoped_ptr.hpp broken

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-09-27 14:00:24

Vladimir wrote:

>I think the docs are a bit unclear:

Well, I guess that's no surprise as the whole question is still not totally
clear to me.

>What's the meaning of 'dependent' type? Do you mean 'dependent in context
>of 'serialize'? Then, if I write:

>   template<class Archive>
>   inline void serialize(
>    Archive & ar, 
>    my_class & t, 
>    const unsigned long int file_version) {}

>then the type to be serialized is never dependent type. Or do you refer to
>a case where 'serialize' is templated on saved type? I'd suggest that you
>write that explicitly, as "dependent type" is a bit vague.

>From Vandervoorde and Josuttis book "C++ Templates - A Complete Guide" page
119 I quote:

"A name is a dependent name if it depends in some way on a template
parameter.  For example, std::vector<T>::iterator is a dependent name if T
is a template parameter but it is a nondependent name if T is a known
typedef (for example, of int)."

That is the definition I'm using for "dependant type"

>> Before this change, there is a problem with compilers which implement
>> two-phase lookup. Overrides for templates have to be defined before their
>> usage in another template. 

>It would be great if you could put the explanation to the docs. 

I'll try to expand on this a little.

>BTW, I start
>to wonder if two-phase lookup does any good, for all additional portability
>problems that it has.

I've "wondered" about that as well. I brought this up before and the
rationale was explained to me but I was left unsatisfied.  I have to say
this is the kind of thing that raises doubts in my mind about the
applicability of C++ for programming jobs assigned to people who can't
justify the rigorous parsing of the standard and extremely subtle compiler
variations.  That is - the rest of us.

>> This conflicted with the implementation of 
>> BOOST_CLASS_EXPORT.  To support these compilers, I had to either put
>> non-intrusive serialization functions in the same namespace as the type
>> being serialized or re-organize export.  The latter is non-trivial and
>> couldn't be guaranteed to be ready in time for release (at least at the
>> time the issue came up).

>Is the issue really with BOOST_CLASS_EXPORT? It seems that on compilers
>with two-phase lookup, if 'save' overloads are in boost::serialization,
>they must be seen before any code which uses 'save'. And this requirement
>is not specific to BOOST_CLASS_EXPORT. And also, btw, the table says
>boost::serialization is suitable for 'save' overload if compiler supports
>ADL, two-phase lookup and type is dependent. Why is it so?

Damn - now I have to figure it out all over again.  I honestly don't
remember.  I believe I concluded that the problem could be addressed by
requiring all the serialization headers be specified before all the archive
headers, but that THAT conflicted with the implementation of export which
required the opposite.  It turned out invoking serialization without
namespace qualification delayed lookup until instantiation and that resolved
the solution.  

My current thinking is that I should re-implement export so that all
serializations can be required to be before inclusion of all archive
headers.  Then serializations could be in any of the following namespace (on
conforming compilers:

Boost::serialization
The namespace of T
The namespace of Archive

And that section of the manual could be eliminated.

Robert Ramey