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.
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.
Free the weed!! Class B to class C is not good enough!!
And the FAQ is here :- http://faq.cprogramming.com/cgi-bin/smartfaq.cgi
Oh, I see. Well, I'll look into it tomorrow, gotta sleep now.
Just Google It. √
(\ /)
( . .)
c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.
Ok; someone else gave examples of smart pointers. Some examples of design restrictions are;Originally Posted by Hunter2
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.
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.
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?
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.
These are just examples, there are other constraints as well to be traded off in some system designs. If you look at the design rationale behind various smart pointers, you will find that different smart pointers are designed to meet specific sets of design criteria.
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.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.
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.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.
[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.
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.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.
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.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law