Re: [boost] Re: Question about interpretation of ISO C++ standard

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-05-18 19:35:36

----- Original Message -----
From: <rwgk_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, May 18, 2001 6:15 PM
Subject: [boost] Re: Question about interpretation of ISO C++ standard

> --- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> > all to_python functions need an extra argument so that koening
> lookup can
> > find them.
>
> Do all compiler support Koenig lookup?
> For some reason I believe that VC6 does not.

Close: it only supports koenig lookup for operators.

> Will the proposed changes still work with VC6?

Hmm. Yes, I think so...

> Is this because that compiler supports the non-conforming
> lookup of friend functions?

Exactly.

> Would this be a valid summary:
>   - A fully conforming compiler will find the friend functions
>     through Koenig lookup, and only through Koenig lookup.

...unless they are also declared separately.

>   - Less than fully conforming compilers (all but the latest
>     Compaq compiler)

I wouldn't jump to that conclusion; Compaq uses an EDG front-end, just like
many other compilers. Still others may enforce this rule correctly.

> will find the friend functions through
>     normal lookup (because the friend functions are implicitly
>     declared in the namespace that encloses their class).

The less-than-fully-conforming compilers fall into at least 3 categories:

1. koenig lookup unsupported (MSVC)
2. koenig lookup supported, but also non-conforming friend function lookup.
3. koenig lookup supported, but bugs in the generation of friend functions
cause them to break unless they're in the global namespace (GCC 2.95.2 - and
.3?)

For GCC, we are currently generating these functions in the global namespace
and calling them either unqualified or explicitly qualified in the global
namespace (using the BOOST_PYTHON_CONVERSION macro which compiles to nothing
followed by ::) depending on the context.

For everything else, we are generating the functions in boost::python and
calling them either unqualified from boost::python or explicitly qualified
with boost::python using BOOST_PYTHON_CONVERSION::.

It is clear to me that BOOST_PYTHON_CONVERSION must die and all calls to
generated friend functions must be made unqualified. This only requires that
compilers without koening lookup do the same thing as GCC and generate the
friend functions in the global namespace.

Does this make sense to everybody else?

> P.S.: An anecdotal remark: when trying to understand (bits of)
> the Boost.Python code I had real trouble because I was not
> aware of the fact that the friend functions are
> implicitly declared in the namespace that encloses their
> class. When I found this out the hard way I was really
> surprised and I found it very sneaky. This experience
> as a novice to C++ suggests that the standard conforming
> behavior is probably more intuitive.

Well, the standard behavior is even weirder than what Boost.Python relies
on! These functions /are/ generated in the enclosing namespace, but can't be
found there at all by ordinary lookup!

> -- But then again,
> what exactly is Koenig lookup? (no response expected)

That's the same as argument-dependent lookup:

3.4.2 Argument-dependent name lookup

1 When an unqualified name is used as the postfix-expression in a function
call (5.2.2), other namespaces not considered during the usual unqualified
lookup (3.4.1) may be searched, and namespace-scope friend function
declarations (11.4) not otherwise visible may be found. These modifications
to the search depend on the types of the arguments (and for template
template arguments, the namespace of the template argument).

2 For each argument type T in the function call, there is a set of zero or
more associated namespaces and a set of zero or more associated classes to
be considered. The sets of namespaces and classes is determined entirely by
the types of the function arguments (and the namespace of any template
template argument). Typedef names and using-declarations used to specify the
types do not contribute to this set. The sets of namespaces and classes are
determined in the following way:

<snip>

-Dave