[C++-sig] bpl_utils explained

[Ralf W. Grosse-Kunstleve]

--- David Abrahams <dave at boost-consulting.com> wrote:
> If each one exposes a sequence interface, and if the presence of a sequence
> interface and convertible elements is enough for your from_python converter
> to report convertibility, then I think there is ambiguity. Although there
> is a crude priority system for converter matching (rvalue converters that
> have been "pushed back" are considered last for arguments for which rvalue
> conversions are eligible -- T, T const&), the system for function overload
> matching is still first-come, first-served.

Sorry, you lost me here.
Let's call the "inserted" converters class 1 converters, and the
"pushed back" converters class 2 converters.
Isn't it that all converters generated via class_<> are class 1
converters?
Isn't it that overload resolution /always/ tests /all/ class 1
converters before resorting to class 2 converters?

Now let's say overload resolution is trying to match

void foo(std::vector<int> const& v)

Say there is only this one foo() (IOW no other overloads).
For the conversion to succeed there has to be at least one registered
std::vector<int> converter, either class 1 or class 2. If there is only
a class 2, the Python object to be converted cannot be a wrapped
std::vector<int> .
Right?
If there is a class1 converter, the Python object to be converted could
be a std::vector<int>, and if it is, it will be converted with the class 1
converter.
Right?
If the Python object to be converted is not a std::vector<int> but
it is a sequence (measurable or not measurable, depending on
"check_convertibility_per_element"), it will be converted by the
class 2 converter.
Right?

Now lets look at this:

void foo(std::vector<int> const& v)
void foo(std::vector<double> const& v)

If both vector types have a class 1 converter there is no ambiguity.
Right?
If both have only a class 2 converter the ambiguity is exactly
equivalent to this situation:

void foo(int)
void foo(double)

The overload that is tried first during overload resolution is used.
Right?

Now say std::vector<int> is class 1 & 2 convertible, and
std::vector<double> only class 2. If the object to be converted
is a wrapped std::vector<int> it will be converted class 1,
otherwise the overload tried first will be used.

If this is all correct, then I conclude that there is nothing new to
learn for Boost Python users. Just as we cannot be sure if we get
foo(int) or foo(double) until we know the order in which the converters
were registered we cannot be sure if we get foo(std::vector<int>) or
foo(std::vector<double>) if the class 1 vector containers are missing.
Other than that the conversions are "predictable" without having to know the
order of registration.
Correct?

> IOW, function overloads are considered in sequence, and the first one for
> which all arguments find converters is called.

Is my conclusion above what you mean?

> I'm not sure I'm looking in the right place.
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cctbx/cctbx/misc/?only_with_
> tag=boost_python_v2_transition shows the most recent change 27 hours ago...

cvs -z3 -d:pserver:anonymous at cvs.cctbx.sourceforge.net:/cvsroot/cctbx co -r
boost_python_v2_transition cctbx

cctbx/include/cctbx/bpl_utils.h
cctbx/misc

cctbx/include/cctbx/array_family/shared_bpl.h
cctbx/arraytbx/shared*.cpp

> >   static bool check_convertibility_per_element() { return true; }
> 
> Hmm, wouldn't it be better to do this with something that could be
> evaluated at compile time? That would guarantee avoiding generating code
> for the check in the case where it was false.

After you move my stuff to the library I will check how you get this
to work without compile-time warnings ("unreachable code").

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com