Boost logo

Boost :

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


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


> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at