Thread: delete objects

Read the docs. Each pointer has different tradeoffs. With loki, read the code and see whats going on or read the book for a fuller explanation. Loki expresses some of the different tradeoffs as policy classes. Take a look.

Oh, I see. Well, I'll look into it tomorrow, gotta sleep now.

1) Overall performance constraints. The time to dynamically allocate and release memory is, in general, unpredictable. Particularly if memory is fragmented due to lots of previous allocations and deallocations. Couple this with code that has very tight performance performance requirements, and there is a possibility of code not meeting it's requirements.

This is a limitation inherent to dynamic allocation, not to smart pointers. All I asked in my original post is to always use smart pointers when using dynamic allocation.

2) Time for particular operations. For example, if a smart pointer has to check a reference count, the operations involved increase time to (effectively) dereference a pointer.

I have never heard of a strong smart pointer that checks a reference count before derefencing. Weak smart pointers might do - but the Boost weak_ptr, for example, cannot be derefenced but instead forces you to temporarily upgrade it to a strong pointer, which can then be dereferenced quickly. Weak references are special cases, though, and the speed impairment they have are inherent to their nature.

[quot€e]3) Objects with long lifetime. If a system design specifies that a particular object may exist for days, why should it be necessary to check if the object exists every time it is used?[/quote]
Indeed. But what smart pointer does? The point of strong references, such as scoped_ptr, auto_ptr and shared_ptr, is that their existence implies the existence of the pointed-to object.

4) Requirements for reuse and quality assurance. If it is necessary (in system A) for a class to be derived from a specific base class to satisfy needs of a smart pointer, the ability to reuse that class in system B without working via that smart pointer becomes limited. Consider the impact of a design restriction that every class be derived from the DetectOnHeap class I gave as an example earlier in this thread. It might be valid in one application, but means unnecessary overhead to reuse that class for other purposes (eg systems that are designed so all objects are created on the stack). Dead code in a new application (eg if the test that an object is on the heap is never invoked) means more effort to satisfy an independent review that the code works as intended.

But this is a very special case. Again, I've never heard of a smart pointer that required the pointed-to object to adapt to it. Even Boost's intrusive_ptr (I think that's its name) adapts to the object, not the other way round.

I still don't see an inherent limitation to the concept of smart pointers in general that would prevent their use for every dynamic allocation in a program.