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

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-30 09:01:41

Toni,

I can see that my suggested approach doesn't work. The problem is that
there's a function in your interface somewhere that takes a
TextRecordIterator& argument, and we've only exposed
TextRecordIteratorWrapper. I suppose you'll have to revert to using the
technique I suggested to Ralf Grosse-Kunstleve in the excerpt below:

------

Hi Ralf,

First of all, I can see that this is a usage for which I need to arrange
better support. Although you can mutate the signature of any member function
by wrapping it in another function, I don't have a similar provision for
constructors. That said, I thinkyou could hijack some of the functionality
described in the section on Overridable Virtual Functions (even though you
don't have any virtual functions). I suggest this workaround:

struct UnitCellWrapper : UnitCell
{
    UnitCellWrapper(PyObject* self, py::Tuple x, py::Tuple y)
        : UnitCell(from_python(x[1], py::Type<double>()),
                        from_python(x[2], py::Type<double>()),
                        from_python(x[3], py::Type<double>()),
                        from_python(y[1], py::Type<double>()),
                        from_python(y[2], py::Type<double>()),
                        from_python(y[3], py::Type<double>()))
    {}
}

py::ClassWrapper<UnitCell, UnitCellWrapper> unit_cell_class;
unit_cell_class.def(py::Constructor<py::Tuple, py::Tuple>());
...
-------

The key is to use the optional 2nd template parameter to ClassWrapper.
-Dave

----- Original Message -----
From: "Anton Gluck" <gluc_at_[hidden]>
>
> 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.