[C++-sig] Re: Allocating objects on the heap by default.
dave at boost-consulting.com
Mon Jul 7 23:23:24 CEST 2003
Prabhu Ramachandran <prabhu at aero.iitm.ernet.in> writes:
>>>>>> "DA" == David Abrahams <dave at boost-consulting.com> writes:
> >> 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?
> DA> Raw pointers are low-level. High-level interfaces are easier
> DA> 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
> DA> So does manual new/delete.
> Yes, but I've done that already and don't have the time to change all
> my code to use smart pointers now. Essentially, its not a trivial
> change for me to make (since my library is quite large and uses
> pointers quite a bit) so I'll postpone this and update my to-do list.
> >> (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.
> DA> I'm not sure what you mean by that.
> Its nothing important but what I meant was that a user of the library
> has to use 'shared_ptr<A> p(new A());' and not new A().
Not if the library supplies a shared_ptr factory function for A.
I'd tend to hide A's constructor(s) as well.
> DA> If Pyste wants to supply auto_ptr and shared_ptr objects so
> DA> that
> DA> A.held_by(auto_ptr)
> DA> or
> DA> A.held_by(shared_ptr)
> Hmm, I am not sure if the A.held_by approach is easy to do
What could be hard about it?
> but I do know that this can be done easily:
> holder(A, 'std::auto_ptr<test::A>')
> Would that do?
It ain't pretty, but it works.
More information about the Cplusplus-sig