[C++-sig] Outstanding Jobs for v2 release

[David Abrahams]

From: "Achim Domma" <achim.domma at syynx.de>


> one more question:
>
> I just looked over the str interface again and at some points I'm not
sure
> wether to provide functions with 'fixed' parameter types or template
> functions. For example see 'ljust':
>
> BOOST_PYTHON_DECL str ljust(int width) const;
> BOOST_PYTHON_DECL str ljust(object_cref width) const;
>
> This way one could not pass long_ to ljust

Ah, but isn't long_ derived from object <wink>?

> so I would change it to:
>
> BOOST_PYTHON_DECL str ljust(object_cref width) const;
> template <class T>
> str ljust(T const& width) const
> {
>     return this->ljust(object(width));
> }
>
> Is that the right solution? I would apply this to all functions with
indexes
> (index,rindes,...)

It's always safe to use the second approach, but more-efficient to use the
first approach in case you know that Python supplies an underlying 'C' API
of the Python function which really takes a particular C++ type as its
parameter. If you look at list::insert() for example, you can see it's
implemented in terms of PyList_Insert, which takes an integer index as its
parameter. So it's more-efficient to call that directly with an int than to
conjure up a Python object. If you look at the implementation of
PyList_Insert, you can see that it never builds a Python object around that
int. On the other hand, there doesn't appear to be a corresponding
PyString_LJust() function which takes an int, so there's no point in
providing that overload -- the object will get created anyway. I would go
with the second approach.

Hmm, now that I think of it, the second approach is probably the /only/
right one for types which can be subclassed. Again, if you look at
PyList_Insert(), it doesn't give derived classes of list any chance to
intervene and use their own overrides of insert(). So I'll probably have to
go back and change the way list() works. Stick with the second approach
unless implementing an un-subclassable Python type.

-Dave