[C++-sig] make_tuple()?

David Abrahams david.abrahams at rcn.com
Sat Jul 20 03:52:51 CEST 2002


From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> > > return handle<>(borrowed(tuple(result).ptr())).release();
> >
> > Really? That's better than make_tuple(a, b, c)?
>
> Yes, because I had to make tuples three times. The append() solution
really is
> better in my context.

I don't get why the number of times you have to make a tuple has any
bearing.

> (But you are right in your suspicion that my first motivation to start
looking
> for alternative solutions was being scared by the prospect of having to
deal
> with the preprocessor library.)

It's kind of nice, actually.

> > You can always do:
> >
> >     incref(tuple(result).ptr())
> >
> > Doesn't that suit?
>
> Yes, thanks! I will put my patch in the attic for the time being. (But I
must
> add that this solution is even more low level than the hdl() approach; I
was
> hoping that I can completely forget about incref and decref.)

Once you start touching raw PyObject*s, I think incref makes a lot more
sense than handle<>.release()

> > Understood, but I'm not really sure I want to make them look the same.
>
> Sigh.

It's tough living with other peoples' opinions, isn't it?

> On to the next question. I am wondering about the error handling
approaches.
> How does
>
>   object state;
>   tuple(state);
>
> behave if state is not a tuple?

Just like in Python.

> How do you envision api function such as len(object()) to behave if a
Python
> exception is raised? Should it be more like
>
>     int len(object const& obj)
>     {
>         return PyObject_Length(obj.ptr());
>     }
>
> or
>
>     int len(object const& obj)
>     {
>         int result = PyObject_Length(obj.ptr());
>         if (PyErr_Occurred()) boost::python::throw_error_already_set();
>         return result;
>     }

The latter.

> Is there a firm plan already?

Did you look at Dave Hawkes' stuff? I believe it's still in CVS. See
py_interface.[ch]pp

-Dave







More information about the Cplusplus-sig mailing list