Re: [boost] [serialization docs] Ping?

From: David Abrahams (dave_at_[hidden])
Date: 2005-09-22 14:33:23

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

> David Abrahams wrote:
>
>> That's a context in which Allocator is a dependent type.  Let me be
>> perfectly clear.  Try compiling this:
>>
>>       struct foo {};
>>       void f()
>>       {
>>          boost::serialization::text_oarchive<std::ofstream> ar;
>>          ar.template register_type<foo>();
>>       }
>>
>>
>> On a conforming compiler, it will fail.  Now remove the template
>> keyword and try again.
>
> OK, I see this now.  But I don't think the example above represents
> common or useful usage.
>
> But it turns out there are several places within
> the library where the ar really is a template.  

Irrelevant, as I've said many times.  ar is a template in the example
I gave above.  I did that specifically to dispel this misconception.

> There are examples and tests and I'm sure user programs which
> do the following.
>
> struct X {};
> struct Y : public X {};
>
> template<class Archive>
> void serialize(Archive & ar, X & x, const unsigned int version){
>     ar.register_type<Y>();    // will fail on any conforming compiler
>     ar.template register_type<Y>();    // will compile on a conforming 
> compler - will fail on others
>     ar.register_type(static_cast<Y *>(NULL));    // works everywhere.
> }

Yes.

> Of course a user could do
>
> void serialize(boost::serialization::text_oarchive<std::ofstream>  & ar, X & 
> x, const unsigned int version){
>     ar.register_type<Y>();    // compiles fine
>     ar.template register_type<Y>();    // fails to compile
>     ar.register_type(static_cast<Y *>(NULL));    // works everywhere.
> }
>
> But I would argue that he is needlessly giving up generality.

Yes.

> So my advice to user it to always use the third choice above so that
> he can just forget about it an move on.

I think (Y*)0 would be a lot cleaner, but it's up to you what you want
to recommend.

>>>> Maybe I've been too hasty, but it seemed to me, from the lack of any
>>>> requirement that the archive do something that interacts with the
>>>> Serializable concept (and produce sensible semantics) and your
>>>> reference to a separate section describing how to implement an
>>>> archive, that you had been trying to make the "Archive Concept"
>>>> section a "user-only" document, and had put the real requirements
>>>> elsewhere.
>>>
>>> correct. But I didn't think of them as "real requirements", I
>>> thought of them as "implementation details" from the perspective of
>>> the user.
>>
>> Are they requirements or aren't they?  It would be conceptually purer
>> if a model of the Archive concept wasn't required to be derived from a
>> library-provided class template, but I could live with that derivation
>> requirement if the other requirements you specified were complete and
>> meaningful.
>
> Again here is the crux of the problem.  The information in the
> section is not "real requirements".  

Okay, then they're not requirements.  This isn't complicated.  It's
not even a problem with a crux. :)

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