|
Boost : |
From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-25 08:08:51
(complete message copied below)
From: "Ralf W. Grosse-Kunstleve" <rwgk_at_[hidden]>
> I would appreciate your advise about the best strategy for introducing
> a constructor like UnitCell(py::Tuple PyLen, py::Tuple PyAng). Do I
> just have to learn more about inheritance to arrive at an elegant
> solution, or are there better alternatives that are not based on
> inheritance?
>
> I hope my questions are not just a distraction but help in pin-pointing
> where the py_cpp documentation needs to be extended.
They have been very helpful, and I intend to copy-and-paste heavily from my
answers for the next documentation update ;->
> I would be happy
> to summarize my experiences as a "py_cpp user who is also new to C++"
> in a way that could be useful for the py_cpp documentation.
That might be helpful. Let me know what you see room for after I update the
documentation again.
------
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>());
...
-Dave
----- Original Message -----
From: "Ralf W. Grosse-Kunstleve" <rwgk_at_[hidden]>
To: <abrahams_at_[hidden]>
Cc: <rwgk_at_[hidden]>
Sent: Tuesday, October 24, 2000 5:55 PM
Subject: py::Tuple in Constructor
> David,
>
> I am exploring the basics of using py_cpp by way of trying to expose
> an interface like this:
>
> namespace UCTbx {
> class UnitCell {
> public:
> void Set(const double Len[3], const double Ang[3]);
> UnitCell();
> UnitCell(const double a, const double b, const double c,
> const double alpha, const double beta, const double gamma);
> UnitCell(const double Len[3], const double Ang[3]);
> double get_a();
> };
> }
>
> In your egroups posting you showed how to write a wrapper for the Set()
> member function. But what about using tuples in a constructor?
>
> I got it to work by introducing a new constructor:
>
> UnitCell(py::Tuple PyLen, py::Tuple PyAng);
>
> The way I understand C++, this constructor must be part of the public
> interface and therefore the py_cpp header files need to be included.
> Unfortunately, this makes it harder to use my class independently of
> py_cpp.
>
> So my next idea was to create a new class in the extension module which
> inherits from UCTbx::UnitCell:
>
> class PyUnitCell: public UCTbx::UnitCell {
> public:
> void Set(py::Tuple PyLen, py::Tuple PyAng);
> PyUnitCell(py::Tuple PyLen, py::Tuple PyAng);
> PyUnitCell() { }
> PyUnitCell(const double a, const double b, const double c,
> const double alpha, const double beta, const double gamma)
{
> UCTbx::UnitCell::Set(a, b, c, alpha, beta, gamma);
> }
> double get_a() { return UCTbx::UnitCell::get_a(); }
> };
>
> The original idea was that I only need the first two declarations
> (Set() and the additional constructor). I was hoping that overloading
> with the base-class constructors and regular member functions would
> work automatically. However, I only got, e.g., this hook...
>
> UnitCell_class.def(&PyUnitCell::get_a, "get_a");
>
> to work after redefining get_a(). Again, this does not seem ideal.
>
> I would appreciate your advise about the best strategy for introducing
> a constructor like UnitCell(py::Tuple PyLen, py::Tuple PyAng). Do I
> just have to learn more about inheritance to arrive at an elegant
> solution, or are there better alternatives that are not based on
> inheritance?
>
> I hope my questions are not just a distraction but help in pin-pointing
> where the py_cpp documentation needs to be extended. I would be happy
> to summarize my experiences as a "py_cpp user who is also new to C++"
> in a way that could be useful for the py_cpp documentation.
>
> Thank you in advance!
> Ralf
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk