[C++-sig] Pyste suggestion: handling void * arguments

[Nicodemus]

Niall Douglas wrote:

>On 27 Oct 2003 at 17:14, Nicodemus wrote:
>
>  
>
>>void* foo(void *x) { return x; }
>>
>>generated:
>>
>>struct void_ptr{
>>    void_ptr(void* it_): it(it_) {}
>>    void* it;   
>>};
>>
>>
>>void_ptr* foo_w(void_ptr* x) { return new void_ptr(foo(x->it)); }
>>
>>BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(void_ptr);
>>
>>BOOST_PYTHON_MODULE(test)
>>{
>>    def("foo", foo_w, return_value_policy<return_opaque_pointer>()); }
>>    
>>
>
>You're nearly there. I foresee two options here - either make void * 
>a container where python can access the pointer or make it an opaque 
>type. Mixing the two creates confusion IMHO.
>

Acess void* in Python? What for? You won't be able to do anything with 
it, except pass it to other C++ functions that accept void* too. And 
then the code above would take care of that, creating automatic wrappers 
for this functions too.

>If you're going for opaque, you don't define void_ptr at all. This 
>lets you catch when you're returning void * but have forgotten to 
>specify return_opaque_pointer. Even better if pyste does this for you 
>automagically.
>

Sorry, I didn't understand you. You mean that when a function returns 
void*, Pyste could automatically set its default policy for 
return_opaque_pointer? That would be the optimal solution, but 
return_opaque_pointer doesn't work with void*, or am I wrong?

>I went ahead with a solution here which inserts casts to void_ptr * 
>wherever pyste sees void *. And it works fine, except for overloaded 
>methods because BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS() isn't aware 
>of what I'm doing (yet, about to add another cast there too).
>
>Your problem with generating wrappers is passing parameters in a 
>fashion which doesn't cause problems. Most specifically, you must 
>avoid copy construction when parameters are entering any C++ code. 
>I've found call_traits::param_type to be useful here, but I'd imagine 
>pyste would know when it can pass by reference and when not without 
>that.
>

Hmm, I see. But what's the problem with extra copy construction? You 
mean performance, or some other problem?

>If however you choose the casting route (which is technically 
>undefined behaviour, but I can't see many modern systems 
>differentiating between types of pointers) I can send you my altered 
>pyste. Remember that virtual method overrides in wrapper classes will 
>have to cast anyway no matter what.
>

I don't know, "undefined behaviour" is never good. Dave, what's your 
opinion on this?

>BTW, what happened to being able to distinguish between overloads by 
>array index?
>

Sorry, just responded to that post.

Regards,
Nicodemus.