Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-05-18 14:14:27


I think if my interpretation is correct (functions declared only as friends
are not found through ordinary lookup, but only through argument-dependent
name lookup), it has the following implications (looking through the code
for "friend"):

conversions.hpp : py_enum_as_int_converters:

It's lucky that the from_python functions take an argument of type
boost::python::type<...>, which causes them to be found. The most
conscientious thing would be to make it the first parameter to avoid
unintentionally picking up functions from the namespace of the first
argument, but that is probably not critical

It looks like the to_python function is a problem, though. We could add a
dummy first paramter to to_python so that it will be found through
argument-dependent lookup. Ick!

Detailed Analysis:
======== ========

[Ralf, I'll leave the analysis of python_import_extension_class_converters
to you on the basis of what I write here.]

detail/extension_class.hpp: python_extension_class_converters:

py_extension_class_converters() - OK: takes initial boost::python::type<>
arg
non_null_from_python() - OK, but the boost::python::type<> arg should
probably come first
from_python(...) - ditto
all to_python functions need an extra argument so that koening lookup can
find them. We can still have a one-argument template version accessible to
callers which adds the dummy argument and dispatches to the two-argument
version.

reference.hpp: py_ptr_conversions() - all issues previously explored for
from_python/to_python.

-Dave

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

> Attached is another response from Compaq.
> What are the implications for Boost.Python?
> Ralf
>
>
> Date: Fri, 18 May 2001 12:29:16 -0400
> From: cxxc_bugs_at_[hidden]
> To: rwgk_at_c...
> Subject: Re: CPP#5241: Subj: cxx_bugreport: problem with friend
> functions
>
> ----------------------------------------------------------------------
> ----------
> Bjarne Stroustrup's "C++ Programming Language", third
> edition, section 11.5.1, explains the behaviour:
>
> "Like a member declaration, a friend declaration does
> not introduce a name into an enclosing scope.
> ...
> For large programs and classes, it is nice that
> a class doesn't "quietly" add names to its enclosing
> scope.
> ...
> A friend function can be explicitly declared just
> like the friend classes, or it can be found
> through its argument types as if it was declared
> in the non-class scope immediately enclosing its
> class.
>
> If follows that a friend function should either
> be explicitly declared in an enclosing scope
> or take an argument of its class. If not
> the friend cannot be called. For example:
>
> // no f() here
>
> void g(); // X's friend
>
> class X {
> friend void f(); // useless
> friend void g();
> friend void f(const X&); // can be found through its argument
> }
>
>
> Please send all Compaq C/C++ Support requests to
> cxxc_bugs_at_[hidden]
> Reply to this message for further correspondence regarding THIS
> support
> request. Thank you for choosing Compaq C/C++.
>
>
>
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk