Re: Re: new round

Alexander Nasonov wrote:
> Alexander Nasonov wrote:
> 
>> def("member_function", &X::member_function)
>> it's here              ^^^
>>
>> Though, I don't know how to handle this: class_("X")<X,X_impl>[ /* ... 
>> */ ].
> 
> This shouldn't be a problem too. I've just found an example in 
> Boost.Python documentation:
> 
> using namespace boost::python;
> BOOST_PYTHON_MODULE(my_module)
> {
>     def("is_base", is_base);
> 
>     class_<Base,Base_callback, noncopyable>("Base")
>         .def("class_name", &Base_callback::Base_name)
>         ;
> 
> }
> 
> Good sign is that Base_callback is inside def.
> May be you have something else in mind? For example, policies or 
> conversion T Base::* -> T Derived::*?

There are at least two cases where it won't work:

   struct A { void f(); }
   struct B : A {};

   class_<B>("B") [
       def("f", &B::f) // signature is void(A::*)() but A isn't
                       // wrapped.
   ]

and the most trivial..

   class_<A>("A") [
       def(constructor<>()) // Error, we need to explicitly mention
   ]                        // the wrapped type for every constructor

There might be a lot of more cases where it is highly desirable to know
the wrapped type at compile time. There is, IMO, no gain in separating
the def() call from class_.

> My model might look too minimalistic to you. All I need is a way to 
> prepare arguments for a call and then make a call. 

Well, it looks somewhat like the system we have settled on for
langbinding. I do think there might be things you have overlooked, and
again urge you to look at the work done before. There are reasons
behind (most of ;)) the design choices made in libraries like BPL and
luabind.

-- 
Daniel Wallin


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click