[C++-sig] Re: IntWrapper.hpp in indexing_suite

[Niall Douglas]

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

> I've used IntWrapper in a number of different test cases, and ISTR one
> of them needed a conversion to shared pointer. I suspect that test
> didn't make it into the CVS, so the shared pointer conversion is
> currently redundant.

Right, sorry, as I mentioned before I don't quite get how all this 
works ...

> I don't think the shared pointer conversion has anything to do with
> this. The really important bit is this:
> 
>   boost::python::class_<IntWrapper> ("IntWrapper",
>   boost::python::init<int>())
>     .def ("increment", &IntWrapper::increment)
>     .def ("__repr__", repr)
>     .def ("__cmp__", compare)
>     ;
> 
> which turns IntWrapper into a Python class, with enough support to
> convert it to a string and compare two IntWrapper objects. There is
> also an implicit conversion from int, which means that code like this
> will work:

Hang on, back up a way bit. Firstly, you appear to be implying that 
the sequence in python is actually of IntWrapper's, not real int's. 
Actually, now that looks obvious, but I hadn't realised that before.

Therefore the down conversion from an IntWrapper to an int is 
happening when python pulls a value /from/ the sequence eg; 
repr(sequence).

Ok, I now get why there's the __cmp__ and __repr__. But why the 
increment()? Surely that should be __inc__ or something? (I can't 
find __inc__ anywhere in the python docs. But it can't be a reference 
count as there's no way of reading it, decrementing it and besides, 
it's incrementing the value, not a refCount).

Actually, how the hell is bpl converting an IntWrapper to an int? I 
understand how int becomes IntWrapper (the explicit copy 
constructor), but not vice versa!

> > 	CArrayMember<std::string> 
> > *data=static_cast<CArrayMember<std::string> *>(l.getData());
> 
> Wow. This is almost certainly undefined behaviour.

Might be according to the standard, but if CArrayMember<> contains no 
data members, there's no chance of copy slicing and thus no problem.

> > 	return 
> > boost::python::indexing::iterator_pair<CArrayMember<std::string> *>
> > 		(data, data+100000); // Issue if l is near the 4Gb mark
> > }
> 
> The bounds checking code will still be compiled, of course, so lying
> about the bound doesn't actually gain you anything (unless you have no
> way of figuring out the real bound). You should be able to provide the
> correct bound without too much trouble in this example.

Yeah twas temporary code I'll fix later. I was going to have a 
template parameter take an address to a function which when called, 
returns the length of the array (seeing as that function varies 
between classes). And a template specialisation taking arrays with 
length attached.

> OK, so CArrayMember<std::string> is-a std::string. You still haven't
> exposed it to Python though. You will need something like this:
> 
> class_<CArrayMember<std::string>, bases<std::string> >
>    ("CArrayMember_string");
> 
> I don't know exactly what else you'll have to do here - maybe define
> implicit conversions to/from std::string, maybe make it no_init. The
> container suite doesn't attempt to expose the container's value type
> to Python - it assumes that you will do that yourself. I would suggest
> first trying to get CArrayMember<...> working in Python before trying
> to expose a container of CArrayMembers.

I had been assuming that std::string already has a registered 
converter converting it to a python string.

But what's *very* important to understand here is that soon I'll make 
the std::string a template parameter as I want it to be generically 
applicable ie; you can wrap any C++ object with the necessary gumph 
to make it a member of a sequence.

Ideally however I'd like to somehow divorce the conversion of the 
types in the array from the accessing of the array. The conversions 
are already registered and mapped to python types - my CArray code 
should merely index the array and return a type (often pointer to 
type) to the array member which then BPL converts as it would 
normally do (when returned from a method) to its corresponding python 
type.

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/20031011/5f7d3105/attachment.pgp>