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