From: David Abrahams (dave_at_[hidden])
Date: 2005-06-28 10:09:45
"Robert Ramey" <ramey_at_[hidden]> writes:
> I did spend a significant amount of time trying dealing with this.
Did you ask for help? We have a lot of experience in this general
area; I think there are better solutions.
> The first effort resulted in the table of rules which can be found
> in the documentation of 1.32. I found this very unsatisfactory. If
> I remember correctly it was one set of requirements for compilers
> supporting partial template specialization and another set for
> compilers that didn't. Given the two alternatives, I found the
> current one much better.
> I understand that I have to live with two-phase lookup. But there's no
> requirement that I have to think its a good idea. I first noticed the
> problem when the meaning of my code silently changed depending upon header
> order. Of course this was compiler dependent.
That's the broken compilers' fault, though, not the conformant ones'.
> So it was huge hassle to find. Sorry, I just can't see how this can
> be a good idea.
It can be a good idea if you like to find as many errors in your code
as early as possible, and it can be an especially good idea if you
want to call functions in a consistent overload context, especially
with exported templates. Without 2-phase lookup, templates are not
usually even parsed until instantiation time. I understand why some
people don't like it, but there are at least as many arguments in its
>> Before you object, I don't think my assessment is unduly harsh: the
>> consequences of using an unqualified call as you have done have
>> already bitten one developer and the library change is, IIUC, not even
>> out the door to the public. Indiscriminate ADL is well-known to cause
>> this sort of problem, and Boost developers are probably more careful
>> than most to insulate themselves from it by isolating their types from
>> functions. It's going to be a much bigger deal once Joe Global
>> Namespace gets his hands on it.
>> I don't know much about the needs of export.hpp, but there are
>> well-known ways to navigate this terrain and I can't believe that the
>> serialization library is unique in this area. Maybe if you ask for
>> help and give some detail about what you're trying to do, someone can
>> suggest a better approach. For example, did you consider using class
>> template partial specialization?
So, did you?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk