From: Robert Ramey (ramey_at_[hidden])
Date: 2005-09-15 11:47:29
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.