Re: Another Koenig lookup thread, yes, kill me now
on Sun Jul 27 2008, JoshuaMaurice-AT-gmail.com wrote:
At the very least, as it stands now namespaces don't buy you what most
people think they do.
Yes; I've said the same thing often. Unfortunately in the committee
casual pronouncements about what "most people" want/need/expect without
any backing data are usually viewed at best with mild amusement. So I
try to appeal to stronger arguments if I can find them.
Specifically, would this be a fair assessment?
In all header files, for all function calls,
Source files, too.
you should either:
1- namespace qualify the function call. I expect this to be the
general case.
You can also parenthesize the function name, but that's really horrible.
2- purposefully not namespace qualify the function call. I expect this
to happen mostly in templates (of type T), and the function has an
argument of T. You expect a user to provide this function for type T,
and thus you want Koenig lookup to find the user supplied function.
You forgot about the other side of the bargain. When writing code that
uses ADL, you need to document exactly which functions you'll be calling
without qualification and on what arguments.
Specifically, I was never taught this in school, and absolutely none
of my colleagues know about this either. This is a huge gotcha which
is not known at all.
It's well-known in some circles.
I don't expect it to be as big of a deal when writing .cpp files, as
if you hit some Koenig lookup problem, you have control and can scope
it or not.
You don't have control, because you can't really control what happens
(i.e. what functions are declared) in the header files you're using.
However, anyone writing interface header files must make a
determination for each function call to namespace qualify or
not. Moreover, this seems quite error prone, as during the writing of
the interface file, it may appear to work fine, but it could break in
the field in a small subset of cases.
Yes. It's not that ADL breaks often; it doesn't.
The problem is that
a. when it breaks there may be no way to fix it (library incompability)
b. once you understand the problem you will waste countless valuable
brain cycles thinking about how to avoid it.
On the other hand, as a user of the header file, if you encounter such
a problem, it might be easy enough to just go in and fix it... It's
just a header file.
In general, no. The header may come from a third party and you may not
have the liberty to change it, either because it will break ABI
compability with something else in your program, or because they've
given you precompiled binaries to go with the header and no source, or
any number of other reasons.
If the function call was not namespace qualified and it should have
been, as a user you could just modify the header file to explicitly
qualify the function call, and it should work. Right?
However, it would be ... "inconvenient" ... to ask my entire company
to "fix" a header file in the compiler's STL, though this is more a
problem of company policy and tradition than any real coding problem.
Once we got http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#225
straightened out, I don't know of any standard library implementations
that are calling user-definable names other than swap without
qualification (and unqualified swap calls are now officially
sanctioned). Unfortunately MSVC's standard library still fully
qualifies swap calls.
See also
http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#226
http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#227
http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#229
and
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1296.asc
for more on this.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]