Re: [boost] Re: from enumerations to I/O streams

From: Anton Gluck (gluc_at_[hidden])
Date: 2000-10-30 01:40:04

> > > ifstream as a parameter. If you don't want to intrude on your class'
> > > interface, you can do something like this:
> > >
> > > struct TextRecordIteratorWrapper : TextRecordIterator
> > > {
> > >    TextRecordIteratorWrapper(std::ifstream* s) :
> > >       TextRecordIterator(*s) {}
> > > };
> > >
> > > ...
> > > py::ClassWrapper<TextRecordIteratorWrapper>
> > > text_record_class(ClusterForPython, "TextRecordIterator");
> > > text_record_class.def(py::Constructor<std::ifstream*>());
> > > text_record_class.def(&TextRecordIteratorWrapper::function1,
> "function1");
> > > ...
> >
> > Most of this works, except for the last line (exposing a
> > TextRecordIterator function, properly renamed of course).
> 
> Renamed? How? Why?

I meant that I renamed function1 to the actual function names, in this
case HasMore and Next.

> > This being an
> > iterator, I tried exposing its HasMore and Next functions. I got this
> > error:
> 
> not that this is relevant, but I don't get the connection between it being
> an iterator and having HasMore and Next functions...

That's probably my Java background speaking here: in Java an iterator is
expected to have hasMore() and next() methods.

> > d:\py_cpp/caller.h(32) : error C2665: 'from_python' : none of the 134
> > overloads can convert parameter 2 from type 'struct py::Type<class
> > TextRecordIterator &>'
> >         d:\py_cpp/functions.h(54) : see reference to function template
> > instantiation 'struct _object *__cdecl py::Caller<int>::call(int
> > (__thiscall TextRecordIterator::*)(void),struct _object *,struct _object
> > *)' being compiled
> >
> > I suppose the move from TextRecordIteratorWrapper to the underlying
> > TextRecordIterator causes the problem. Another bug?
> 
> I could be wrong, but I think it's not a bug. It looks to me like you wrote
> something like
>     text_record_class.def(&TextRecordIterator::HasMore, "HasMore");
> instead of
>     text_record_class.def(&TextRecordIteratorWrapper::HasMore, "HasMore");
> 
> Am I right?

I had worried about just this mistake myself, but no, it's actually
text_record_class.def(&TextRecordIteratorWrapper::HasMore, "HasMore");

Here is all the code for TextRecordIterator. Except for the name of the
wrapper class and the function names I kept to your suggestions:

struct TextRecordIteratorWrapper : TextRecordIterator
{
        TextRecordIteratorWrapper(std::ifstream* s) :
                TextRecordIterator(*s) {}
};
.
.
.
[within the init function:]
py::ClassWrapper<TextRecordIteratorWrapper> TextRecordIteratorWrapper_class(ClusterForPy, "TextRecordIterator");
TextRecordIteratorWrapper_class.def(py::Constructor<std::ifstream*>());
TextRecordIteratorWrapper_class.def(&TextRecordIteratorWrapper::HasMore, "HasMore");
TextRecordIteratorWrapper_class.def(&TextRecordIteratorWrapper::Next, "Next");

> P.S. I have a bug fix for the non-const-reference-constructor-argument
> problem. I was planning on doing more work on the documentation before
> posting it, but if you'd like I will post an update sooner.

Except for the problem with the wrapping of HasMore and Next I'm happy
with the current solution (I can instantiate a TextRecordIterator in
Python). So there's no need to post an early update for the const and
non-const problem.

Thanks,

Toni