[C++-sig] Pyste suggestion: handling void * arguments
nicodemus at esss.com.br
Sat Nov 1 19:49:11 CET 2003
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
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
>>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:
>... 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
>>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.
More information about the Cplusplus-sig