"Robert Ramey" <ramey@rrsd.com> 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