Re: Another Koenig lookup thread, yes, kill me now
on Fri Jul 25 2008, JoshuaMaurice-AT-gmail.com wrote:
Now, I don't want to start a flame thread, and I apologize for
bringing this up. However, I do have a couple things I would like
clarified. To start, here's one of the well known problems with Koenig
lookup.
// **** main problem
namespace A
{ class foo {};
template <typename T> void helper (T) {}
The really bad version of this problem occurs when this helper takes
T&...
}
namespace B
{ template <typename T> void helper(T ) {}
.....and this one take T const&
template <typename T>
class set
{
public:
set()
{ T tmp;
helper(tmp);
}
};
}
int main() { B::set<A::foo *> s; }
// ****
I actually had this happen to me in production code. I ended up
changing
int main() { B::set<A::foo *> s; }
to
int main() { B::set<void *> s; }
to get around Koenig lookup, and static_cast'ing on each use. I really
disliked how I had to abandon type safety. I was in a no win
situation. namespace B was the compiler's STL, and namespace A was a
company-wide header which was not going to change.
Yep, this is the well-known "global name reservation" problem that can
make two independently-developed pieces of code incompatible.
I post this to make sure I understand all of the problems Koenig
lookup is supposed to solve. Here are the two big examples of which I
know.
// **** ex 1
#include <iostream>
int main() { std::cout << "foo\n"; }
// **** ex 2
namespace A { class foo {}; void bar(foo ) {} }
int main() { A::foo x; bar(x); }
// ****
I view those as illustrating exactly the same scenario, but if you want to
distinguish
operators from other names you might use:
namespace Math
{
class rational {};
rational abs( rational ) {}
}
template <class Number>
void generic_algorithm(Number x)
{
Number y = abs(x);
};
which is both realistic and demonstrates that sometimes (e.g. in
templates) you don't know the name of the namespace even if you *were*
willing to use explicit qualification.
Solution #1 - As it stands now without Koenig lookup.
Without Koenig lookup, the first problem of finding the function
operator << can be solved with the ever dreaded "using namespace std;"
or a more limited "using std::operator <<;".
Yeah, but not in a generic printing function (once again, you don't know
the name of the namespace).
The second example can be
made to compile without Koenig lookup with "using namespace A;",
"using A::bar;", or explicitly specifying which bar "int main()
{ A::foo x; A::bar(x); }".
Solution #2
One alternative already proposed in a thread on this newsgroup is to
make each operator function into a member function or into a global
scope global function. (I don't know how lookup would work without
Koenig lookup for infix operator notation, so if necessary change the
lookup rules to consider a member function of the left operand when
using infix operator notation.) This is polluting the global
namespace, but not in a meaningful way. Moving these operators to
global scope does not change the space of functions which the user can
declare and use. With Koenig lookup and the original function in
namespace scope, defining and using another produces an ambiguous call
error. With the original function at global scope, a second ser-
defined function will run afoul of the One Definition Rule. (Arguably
though, solution #2 can be a link time ODR violation, which is not
required to be diagnosed IIRC, whereas as it stands now it's a compile
time error.)
Now, if it was just this simple,
Oh, how I wish...
I would be for removing Koenig lookup
entirely. However, Koenig lookup may allow, and/or may have been
intended to allow, supplying your own function for another library to
use. You define some function at namespace A for your type in
namespace A, and then you call another library algorithm in namespace
B expecting it to use your function with your type. Was this intended?
Is this desirable? Are there alternatives?
http://www.boostpro.com/writing/n1691.html
It didn't get lots of traction in the committee. Actually I think there
might be some support for combining this approach with C++ module
support if we can ever get the time and/or funding to complete that
project:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2006.pdf
--
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! ]