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

[Nicodemus]

Niall Douglas wrote:

>On 28 Oct 2003 at 19:05, Nicodemus wrote:
>
>  
>
>>>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.
>>    
>>
>
>You can alter it like an long integer - add and subtract offsets, set 
>to fixed locations etc. I'm not saying it's all that common, but it 
>would offer the ability for python to use pointers*
>
>(*: Many would consider adding pointers to python a real retrograde 
>step. I'm not saying it's a good idea, but it is useful in selected 
>instances)
>  
>

Hmm... I don't think that supporting pointer arithmetic in Python is a 
compelling reason the let the user access the void* in Python... I think 
the user-cases for this are very limited, and not very Pythonic at all... 8/

>>>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?
>>    
>>
>
>Sorry, I wasn't being clear. If you declare a type (can't be void *) 
>to be opaque under BPL, then you don't define it. You just do:
>
>struct void_ptr;
>
>... and that's it. Best to leave it undefined because then failing to 
>set return_opaque_pointer policy causes a compile-time error and 
>until you add the array-indexed policy setting, we need errors where 
>at least one overload returns void *.
>

I still don't understand you, sorry. 8(

You said (in the quote above) that if you declare a type to be opaque 
under BPL, it's better that you don't define it, because if you forget 
to set return_opaque_pointer it will cause compile-time errors. What I 
don't understand is how can you declare it "to be opaque under BPL" 
*without* setting its policy...

>>>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?
>>    
>>
>
>More that some classes either (a) don't implement copying and worse 
>(b) their copy constructor does a destructive copy. Especially in the 
>latter case a copy construction is *fatal* to continued program 
>operation as it alters the semantics of the C++ ABI.
>  
>

You're right about that...

>See the multithreading patch to invoke.hpp I posted here a week or so 
>ago. You'll note the care I went to to avoid copy construction in the 
>parameters (returns may need it too, though that's rare).
>

Hmm, can you help then with the implementation of this wrappers then? 8) 
It would be greatly appreciated.

Regards,
Nicodemus.