[C++-sig] Re: Allocating objects on the heap by default.

[David Abrahams]

Prabhu Ramachandran <prabhu at aero.iitm.ernet.in> writes:

> Hi David,
>
> Thanks for the response!  Makes many things clear.
>
>>>>>> "DA" == David Abrahams <dave at boost-consulting.com> writes:
>
>     >> Perhaps the design is totally stupid, but its used consistently
>     >> everywhere and quite simple once you know you can't delete an
>     >> object you created and passed to a manager.  Juas as the user
>     >> has to manage and remember to invoke delete for every new he
>     >> has to remember that the manager manages memory as well.  I
>     >> don't see that as a bad decision but I guess purists would not
>     >> agree with me.
>
>     DA> Nor pragmatists.  You should use std::vector<shared_ptr<Obj> >
>     DA> and handle only shared_ptr<Obj> everywhere and then users
>     DA> don't need to remember to delete anything, ever.
>
> Hmm, so you are saying none of the functions should have ever been
> written to deal with raw pointers at all and should all have used
> shared_ptr?  

Raw pointers are low-level.  High-level interfaces are easier to use
correctly and much easier to wrap.

> But at some point using shared_ptr requires one to handle
> reference cycles and figure how to break them

So does manual new/delete.

>  (using weak_ptrs).  I'll admit that this is probably rare (although
> I can think of a few candidates in my code) and a lot easier to deal
> with.  It also requires that the users generate shared_ptrs when
> they create a new object.  

I'm not sure what you mean by that.

> Am I correct?  There are also performance issues I'll need to worry
> about.  The boost "smart pointer" docs should prove useful here.  If
> this is what it takes perhaps I'll clean up my library to do this
> correctly in the future.  For now I'll stick to the existing impure
> and non-pragmatic approach. :)

OK.

>     DA> You need to write thin wrappers for functions such as Mgr::add
>     DA> which take auto_ptr<Obj> instead of Obj* if you want to
>     DA> transfer ownership in this way.  When we get luabind
>     DA> integration you won't have to do that, though.
>
> Well, I was considering adding auto_ptr support to the library itself
> by overloading the add type of methods to accept an auto_ptr also.
> This will fix the issue.

Yep.

> Many thanks!  For now I'll add overloads to handle an auto_ptr<T> and
> later consider moving to shared_ptr.  I still need to get a handle on
> the performance of shared_ptr though.
>
> The only issue that I need clarification is on how Pyste should do
> handle this.  When use_auto_ptr(Obj) is specified should it register
> both the to_python converter and also pass the HeldType as auto_ptr or
> should the HeldType parameter be handled by something like
> handle_with_auto_ptr(Obj)?  I think the latter is better but am not
> quite sure.  I can submit a patch to handle this if this its OK.

I'm not fond of the idea of hard-coding auto_ptr and shared_ptr into
Pyste; there are other important smart pointers.  It would be better
to write:

        A.held_by('std::auto_ptr<A>')

If Pyste wants to supply auto_ptr and shared_ptr objects so that

        A.held_by(auto_ptr)
or
        A.held_by(shared_ptr)

could work as well, that would be good.  Another possibility is to
get rid of the first option altogether and ask people to write:

    def my_smart_ptr(pointee):
         return 'my_smart_ptr<' + str(pointee) + '>'

so that

    A.held_by(my_smart_ptr)

will work.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com