Why koenig lookup?

[Juha Nieminen]

The so-called koenig lookup allows doing odd things like this:

#include <algorithm>
#include <string>

int main()
{
std::string table[10];
sort(table, table+10);
}

(Notice how the 'sort' doesn't have the std:: prefix, yet it's
perfectly valid.)

I understand that the reason for the koenig lookup to exist is so that
you can write things like:

std::cout << 5;

This is actually equivalent to:

operator<<(std: :cout, 5);

The koenig lookup allows the compiler to look for operator<< inside
the std namespace because one of the parameters is from that namespace.

With operators it makes sense. However, why perform the same lookup
for *all* functions? What's the advantage? Couldn't it be simply defined
that the koenig lookup is performed for operators but not for regular
functions?

[Captain Trips]

Juha Nieminen wrote:

The so-called koenig lookup allows doing odd things like this:

#include <algorithm>
#include <string>

int main()
{
std::string table[10];
sort(table, table+10);
}

(Notice how the 'sort' doesn't have the std:: prefix, yet it's
perfectly valid.)

I understand that the reason for the koenig lookup to exist is so that
you can write things like:

std::cout << 5;

This is actually equivalent to:

operator<<(std: :cout, 5);

The koenig lookup allows the compiler to look for operator<< inside
the std namespace because one of the parameters is from that namespace.

With operators it makes sense. However, why perform the same lookup
for *all* functions? What's the advantage? Couldn't it be simply defined
that the koenig lookup is performed for operators but not for regular
functions?

Well it saves a lot of typing, i think that's why it's working for
functions, too. If the function is valid in the namespace std, why
should you type it all the time. If you don't want to use std just don't
type "using namespace std;" at the beginning of your code. The compiler
will demand std:: all the time then.

If you type the line the compiler doesn't need the std:: anymore,
because you are already in the namespace std.

[Juha Nieminen]

Captain Trips wrote:

Well it saves a lot of typing, i think that's why it's working for
functions, too. If the function is valid in the namespace std, why
should you type it all the time. If you don't want to use std just don't
type "using namespace std;" at the beginning of your code. The compiler
will demand std:: all the time then.

If you type the line the compiler doesn't need the std:: anymore,
because you are already in the namespace std.

Uh? I think you are talking about a completely different issue. I was
not talking about "using" at all.

[blargg]

In article <g7**********@s agnix.uni-muenster.de>, Captain Trips
<us*******@un i-muenster.dewrot e:

[Koenig lookup]

Well it saves a lot of typing, i think that's why it's working for
functions, too. If the function is valid in the namespace std, why
should you type it all the time. If you don't want to use std just don't
type "using namespace std;" at the beginning of your code. The compiler
will demand std:: all the time then.

That was his point; it does NOT need std:: here, even though there is no
"sort" in the scope of main, and no using directive bringing namespace std
into scope. Simply because table, one of the arguments to the function
call, was of a type whose definition was in namespace std, the sort
function was chosen.

[James Kanze]

On Aug 9, 5:08 pm, Juha Nieminen <nos...@thanks. invalidwrote:

The so-called koenig lookup allows doing odd things like this:

#include <algorithm>
#include <string>

int main()
{
std::string table[10];
sort(table, table+10);
}

(Notice how the 'sort' doesn't have the std:: prefix, yet it's
perfectly valid.)

I understand that the reason for the koenig lookup to exist is
so that you can write things like:

std::cout << 5;

This is actually equivalent to:

operator<<(std: :cout, 5);

The koenig lookup allows the compiler to look for operator<<
inside the std namespace because one of the parameters is from
that namespace.

With operators it makes sense. However, why perform the same
lookup for *all* functions? What's the advantage? Couldn't it
be simply defined that the koenig lookup is performed for
operators but not for regular functions?

What's the difference between a function and an operator, except
the invocation syntax? Orthogonality, if nothing else, requires
that the same lookup applies. In addition:

#include <BigDecimal.h h>

int
main()
{
using SomeNamespace:: BigDecimal ;
BigDecimal z1 ;
BigDecimal z2 = sin( z1 ) ;
// Do you really think it reasonable to have to write
// SomeNamespace:: sin here?
}

And of course, in a template, you don't really even have the
choice.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Aug 9, 7:46 pm, "Alf P. Steinbach" <[e-mail] wrote:

* Juha Nieminen:

The so-called koenig lookup allows doing odd things like
this:

#include <algorithm>
#include <string>

int main()
{
std::string table[10];
sort(table, table+10);
}

(Notice how the 'sort' doesn't have the std:: prefix, yet
it's perfectly valid.)

I understand that the reason for the koenig lookup to exist
is so that you can write things like:

std::cout << 5;

This is actually equivalent to:

operator<<(std: :cout, 5);

The koenig lookup allows the compiler to look for operator<<
inside the std namespace because one of the parameters is
from that namespace.

With operators it makes sense. However, why perform the same
lookup for *all* functions? What's the advantage? Couldn't
it be simply defined that the koenig lookup is performed for
operators but not for regular functions?

I don't think Andrew Koenig, or /anyone else/, fully grokked
the consequences at the time.

Well, he certainly didn't have any concrete experience with it
before it was standardized. However...

If ADL (argument-dependent lookup) was defined today, now that
we've had some experience with it, then I'm pretty sure it
would be restricted to operators, and perhaps -- but just
perhaps -- extended in another direction, namely for lookup
of arguments in classes, where it's a hassle to have to
qualify things all the time, as opposed to the case
exemplified above, where it just introduces problems and
complexity without conferring any advantage.

A few experimental implementations had been made with namespace,
and I think it was concrete experience with them that led to the
understanding that something had to be done with functions. All
functions, not just overloaded operators. Now, given the time
frame, I personally think that the "correct" solution would have
been to back out of the problem completely, and drop namespaces
from that version of the standard, because of a lack of
knowledge with regards to the real problems that it might
introduce. (And in honesty, I have to admit that my fears were
largely unfounded.)

Off hand, I think if there were anything to do differently
(given namespaces and the way they work), it would be to have
the built in types imply the global namespace, rather than no
namespace.

I guess that goes to show that the job of standardization is
not to innovate. ;-)

I think at least some members of the committee share your
opinion there---at least part of the motivation behind Boost was
to provide a place where innovation would be appropriate, which
could be standardized once concrete experience was established.
(Regretfully, it only applies to libraries.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Aug 10, 3:19 pm, "Alf P. Steinbach" <[e-mail] wrote:

* James Kanze:

[...]

In addition:

#include <BigDecimal.h h>

int
main()
{
using SomeNamespace:: BigDecimal ;
BigDecimal z1 ;
BigDecimal z2 = sin( z1 ) ;
// Do you really think it reasonable to have to write
// SomeNamespace:: sin here?
}

I think this is a good point, that an overload of 'sin' should
not be introduced in a new namespace, but in the original
namespace, namely here the global one.

It doesn't work, because...

And of course, in a template, you don't really even have the
choice.

?

In a template, sin will be a dependent name, and will not be
looked up in the global namespace, only in the namespace where
BigDecimal was defined.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Aug 10, 6:45 pm, "Alf P. Steinbach" <[e-mail] wrote:

* James Kanze:

>And of course, in a template, you don't really even have the
choice.

?

In a template, sin will be a dependent name, and will not be
looked up in the global namespace, only in the namespace where
BigDecimal was defined.

If that was true then it would just reinforce the point that
ADL for named routines has turned out to be too problematic,
too many limiting corner cases.

I don't think the problem here is ADL. The problem is two phase
lookup in general.

However,

<code>
#include <iostream>

namespace james
{
struct BigInt {};
}

double sin( james::BigInt ) { return 0; }

template< typename T >
void foo()
{
sin( james::BigInt() );
}
is good standard C++.

But doesn't use sin in a dependent context in a dependent
context in the template. I was thinking of the classical case,
where the operator<< for std::vector<int defined in global
namespace doesn't get found when it is used in
std::ostream_it erator. Curiously, I can't reproduce the
symptomes in a simple example, but I've definitely had the
problem myself, and people post it here from time to time.

I did say dependent, didn't I, in my first posting. Now, either
two phase lookup is too complicated for even a guru like
yourself to catch onto the subtilities, or you're being
intentionally obtuse. (And regretfully, there's nothing ironic
about that. IMHO, two phase lookup does have enough subtilities
that even an expert can easily overlook them.)

So what you literally write, is incorrect, and argument void.
But still there is a good chance that you had some specific
scenario in mind, that I don't at present grok. And I'm
interested in that, on its own, so please, elaborate. :-)

See above. And the fact that even someone with your level
didn't catch on immediately just confirms my feeling that two
phase lookup, at least in its present form, was a mistake,
because it's just too complicated.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <2a0f00c3-10cd-4b64-8203-57c5e681b565
@k13g2000hse.go oglegroups.com> , ja*********@gma il.com says...

[ ... ]

But doesn't use sin in a dependent context in a dependent
context in the template. I was thinking of the classical case,
where the operator<< for std::vector<int defined in global
namespace doesn't get found when it is used in
std::ostream_it erator. Curiously, I can't reproduce the
symptomes in a simple example, but I've definitely had the
problem myself, and people post it here from time to time.

Here's a fairly simple example:

#include <map>
#include <string>
#include <iostream>
#include <algorithm>

typedef std::map<std::s tring, ints_int;

//namespace std {

std::ostream &operator<<(std ::ostream &os, s_int::value_ty pe const &v)
{
return os << v.first << ": " << v.second;
}

//}

int main() {
s_int m;

m["a"] = 123;
m["b"] = 345;

std::copy(m.beg in(), m.end(),
std::ostream_it erator<s_int::v alue_type>(std: :cout, "\n"));

return 0;
}

As it stands right now, it won't compile -- but remove the two comment
delimiters so operator<< is in namespace std, and it compiles and works
just fine.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[kwikius]

Jerry Coffin wrote:

In article <2a0f00c3-10cd-4b64-8203-57c5e681b565
@k13g2000hse.go oglegroups.com> , ja*********@gma il.com says...

[ ... ]

>But doesn't use sin in a dependent context in a dependent
context in the template. I was thinking of the classical case,
where the operator<< for std::vector<int defined in global
namespace doesn't get found when it is used in
std::ostream_i terator. Curiously, I can't reproduce the
symptomes in a simple example, but I've definitely had the
problem myself, and people post it here from time to time.

Here's a fairly simple example:

#include <map>
#include <string>
#include <iostream>
#include <algorithm>

typedef std::map<std::s tring, ints_int;

//namespace std {

std::ostream &operator<<(std ::ostream &os, s_int::value_ty pe const &v)
{
return os << v.first << ": " << v.second;
}

//}

int main() {
s_int m;

m["a"] = 123;
m["b"] = 345;

std::copy(m.beg in(), m.end(),
std::ostream_it erator<s_int::v alue_type>(std: :cout, "\n"));

return 0;
}

As it stands right now, it won't compile -- but remove the two comment
delimiters so operator<< is in namespace std, and it compiles and works
just fine.

Lemme guess. operator<<(std: :ostream&, int ) is ***NOT*** in global
namespace Right? .. Which is the whole point!

I'm with Alf Steinbach on this one....

regards
Andy Little