David Abrahams wrote:
By arranging things so that the serialize(..) template was allways called from within the boost::serialization namespace I thought I had fixed the problem by permiting the overloads to be found via ordinary lookup.
Ordinary lookup doesn't look forward from the template's point of definition. But I guess you know that by now.
I would call your attention to the code in serialization.hpp - line 108 "layer 3". I believe that this code actually considered this problem. By using an argument from the boost::serialzation namespace It guarenteed that the correct overload would be found on the second phase of two phase lookup on compilers supporting ADL (all those that implement two-phase lookup). If I remember correctly, I also studied the rules that governed the conversion from boost::serialization::version_type to const unsigned integer and this information was used to make the process work. I left the note you see in the documentation. This resolved the compilation errors I was having with compilers which implement two-phase lookup so naturally I took this a confirmation that I understood the details. Unfortunately it was some time ago and and after I thought I resolved the problems generated by two-phase lookup I moved on to other problems. So I thought I understood it. Of course now I'm not so sure. I forgot the details of my solution but did remember the amount of detail I had to plow through.
It's hard for me to feel very sympathetic. You have the online compiler.
I don't think its practical to use the online compiler to compile code that requires scores of files.
You could find out what the switches are (--no-microsoft and/or --no-microsoft-bugs) to turn on 2-phase lookup on your local installation of comeau and do some experiments.
I can and I will. I had no reason to suppose that it was turned off for boost (presumably in the toolset). I just assumed that build tools would be setup to maximize compiler conformance with the standard. Perhaps presumptuous on my part but I have to make some reasonable assumptions or I'll never get anything done.
Maybe there is a real simple solution here.
That's what I've been trying to tell you. As I wrote,
Not much more than a small tweak in emphasis would be required.
The relevent passage in the documentation currently states: Namespaces for Free Function Overrides For maximum portability, include any free functions templates and definitions in the namespace boost::serialization. If portability is not a concern and the compiler being used supports ADL (Argument Dependent Lookup) the free functions and templates can be in any of the following namespaces: a.. boost::serialization b.. namespace of the archive class c.. namespace of the type being serialized So if I were to change it to the following would that be satisfactory? Namespaces for Free Function Overrides
If your compiler supports two-phase lookup and ADL (Argument Dependent Lookup) the free functions and templates can be in any of the following namespaces:
namespace of the archive class namespace of the type being serialized
Good, but you should be specific about which free functions and templates you're talking about.
If your compiler doesn't support two-phase lookup but it does support ADL free functions and templates can be in any of the following namespaces a.. boost::serialization b.. namespace of the archive class c.. namespace of the type being serialized If your compiler doesn't support ADL free functions and templates must be in the boost::serialization namespace.
well, at least that's almost correct. The associated namespaces of a type can be more than the one its defined in, but that's OK. I think it's more complicated than it needs to be; I'd say
if your compiler supports argument dependent lookup, overload serialize in the namespace of the type being serialized; otherwise, overload serialize in boost::serialization
Of course that begs the main question I set out to answer. How to make ones code work on all boost platforms
I showed you how in this very message. And that's a repetition of something I showed you earlier.
- but we can just leave that to the judgement of the library user.
That would still be a big improvement on the status quo.
OK I'll just make this alteration in that section. Halleluhuh Robert Ramey.