[C++-sig] How about class_<...>.enable_copy() ?

[Hans Meine]

Hi again!

Anyone cares to comment on my older posting?

On Montag 23 Juli 2007, Hans Meine wrote:
> On Montag 23 Juli 2007, Hans Meine wrote:
> > foo = Foo(other) # copy constructor as in C++ (1)
> > foo = copy.copy(other) # pythonic copying (2)
> > foo = copy.deepcopy(other) # deepcopying (3)
> >
> > (1) is easy to do by exporting the copy constructor
> >
> > (2) could be implemented by setting __copy__ to the above copy
> > constructor, but one would assume __dict__ to be (non-deep)copied, too.
> >
> > (3) definitely needs its own implementation, which needs to call deepcopy
> > recursively.
> >
> > I would still believe that an .enable_copy() would be very handy.  It
> > could possibly be controlled by an enum arg which of the above methods
> > should be exported.

Here is the updated, perfectly working code for (2) and (3), which I propose 
to be included in BPL.  Also, some things appear hackish to me -- I would be 
glad to get feedback on how to do this in a more "standard" way:

a) wrap a pointer to a newly created object in a bp::object -- there must be a 
shorter/better way than
  bp::detail::new_reference(typename manage_new_object::apply<T *>::type()(p)
no?

b) shouldn't a 64bit-safe version of
   inline id(object) { return (int)(copyable.ptr()); }
be added to boost::python?

c) is my solution of accessing copy/deepcopy improvable?  (I guess not - it 
looks already quite OK to me.)

d) would you use the visitor pattern, i.e. class_<T>::enable_copy for the 
above code?  AFAICS, there are two small advantages:
* both functions can be def'd in one line
* the type does not have to be repeated, but is fetched from the class_<> 
template instance

> Maybe someone is interested in turning my code into a standard BPL
> facility? (BTW: Is __dict__ created on demand?  Then one should probably
> add a guard to both my __copy__ and __deepcopy__.)

I'd like to get an authoritive answer on this - do BPL-exported objects always 
have a __dict__, or is it only created on demand/access?

> On Montag 23 Juli 2007, Hans Meine wrote:
> > Probably I should use PyImport_ImportModule or the new
> > boost::python::import.
>
> Speaking of the latter, shouldn't the python:: prefix be removed from the
> code within boost_1_34_0/libs/python/src/import.cpp ?  I recently had
> syntax errors from GCC-4.1.2 within kdelibs-3.5.7 with a similar case:
> > namespace KABC {
> >
> > class KABC_EXPORT Field
> > {
> > public:
> >   virtual QString value( const KABC::Addressee & );
>
> Here, I had to remove KABC:: in order to let it compile.  (Which I found
> surprising, but anyways.)

This is not very much related, but interesting.

-- 
Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/cplusplus-sig/attachments/20071016/c8d7f284/attachment.pgp>