[C++-sig] make tupel/list convertible to class

David Abrahams dave at boost-consulting.com
Sun Dec 15 21:20:51 CET 2002


"Achim Domma" <achim.domma at syynx.de> writes:

>> How does the following interface seem to you?
>
> This looks exactly like the solution I was looking for, but it's not quite
> clear to me why it works.

It doesn't, yet (not yet implemented).

>>     class_<Color>("Color", init<int,int,int>())
>>           .def("__init__", init_color)
>>           ...
>>           ;
>
> If init_color would be defined as void init_color(PyObject*,int,int,int),
> what would be called? The orginal ctor or init_color? 

I guess init_color would shadow the original ctor, since later
overloads get precedence over earlier ones.

> Is it in general ok to mix init<...> and def("__init__",...)?

Yes, but you probably wouldn't want them to have the same signatures ;-)

>> This example might be a little misleading because it appears to be
>> somewhat limited.  In fact, I'm suggesting that you could write
>> init_color so that it accepted any C++ arguments desired after the
>> obligatory "self" argument.  So this would give us a general way to
>> extend the __init__ interface of any wrapped C++ class beyond what's
>> provided by its constructors.
>
> Do you mean something like that:
>
> class_<Color>("Color", init<int,int,int>())
> 	.def(init_from_tuple<
> 		init<int,int,int>(),
> 		init<int,int,int,int>(),
> 		init<...>
> 		>()
> 	)
> 	;

No, I mean that you can use other functions like "init_color" which
accept arguments other than boost::python::tuple.

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution





More information about the Cplusplus-sig mailing list