[C++-sig] Re: C arrays solution

[Niall Douglas]

On 14 Oct 2003 at 11:43, Raoul Gough wrote:

> > Already thought of that and they do vary in name from container to
> > container.
> 
> Do you mean they just vary from container type to container type? Or
> from one instance of a container type to another? For instance, the
> standard library can use char_traits::eq to compare chars, because the
> comparison function doesn't vary from one char object to another (just
> from one *type* of char to another).

No, they're fixed per container.

> > That's interesting, but wouldn't it require a separate declaration
> > of the required functions somewhere beforehand? The solution I chose
> > means very minimal manual editing of pyste's output - in fact, I'm
> > going to make it a diff file applied by scons after calling pyste.
> 
> Yes it would. However, I would assume that the number of different
> types of containers within the library is more or less fixed, so you
> could just put this sort of thing in a separate header:
> [snip]
> 
> Basically, you've somewhere got to say "use getArray here" and "use
> get_array" there. If that is invariant on the container type, why mess
> around with storing pointers to member functions in every object?
> Things would be a bit different if you have a single type that
> contains two or more different sequences and you want to select from
> any of them at run-time.

Your approach looks better. If that really does work as easily as 
sticking those little bits of code in, I'll go for that instead.

> > For example, there's now no reason why a bitmap's contents cannot be
> > directly manipulated by python eg; bitmapdata[4]=0xff puts a white
> > pixel at (4,0) on the screen.
> 
> Of course, this particular example wouldn't be very fast. That
> expression results in a whole bunch of Boost.Python code being
> executed to figure out which C++ functions to call and how to extract
> the C++ objects from the Python ones. Where you really get performance
> is if you can do one call from Python to C++ that then performs a
> whole lot of processing.

That's cool with me. I just want to provide as full a toolset as 
possible and let the users decide what's best for them.

> > Once I'm done with the overloads, you won't even need a container
> > object. I have several static global arrays I need to provide to
> > python.
> 
> Maybe something like this would be useful to have in the library?
> 
>   template<typename T, std::size_t N>
>   iterator_pair<T *> make_iterator_pair (T (&array)[N])
>   {
>     return iterator_pair<T *>(array, array + N);
>   }

Well I'll find this out tonight, but if that little bit of code like 
the above is all I need, I'll go for that.

Why aren't useful things like that in the docs? What I'm doing is 
surely a common problem to a lot of people wrapping C++ (ie; wrapping 
C arrays) - though I'll admit I've never seen anyone ask about it 
before in the archives.

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20031014/27d84143/attachment.pgp>