Shared ownership:
The shared_ptr
and weak_ptr
the standard adopted are pretty much the same as their Boost counterparts. Use them when you need to share a resource and don't know which one will be the last to be alive. Use weak_ptr
to observe the shared resource without influencing its lifetime, not to break cycles. Cycles with shared_ptr
shouldn't normally happen - two resources can't own each other.
Note that Boost additionally offers shared_array
, which might be a suitable alternative to shared_ptr<std::vector<T> const>
.
Next, Boost offers intrusive_ptr
, which are a lightweight solution if your resource offers reference-counted management already and you want to adopt it to the RAII principle. This one was not adopted by the standard.
Unique ownership:
Boost also has a scoped_ptr
, which is not copyable and for which you can not specify a deleter. std::unique_ptr
is boost::scoped_ptr
on steroids and should be your default choice when you need a smart pointer. It allows you to specify a deleter in its template arguments and is movable, unlike boost::scoped_ptr
. It is also fully usable in STL containers as long as you don't use operations that need copyable types (obviously).
Note again, that Boost has an array version: scoped_array
, which the standard unified by requiring std::unique_ptr<T[]>
partial specialization that will delete[]
the pointer instead of delete
ing it (with the default_delete
r). std::unique_ptr<T[]>
also offers operator[]
instead of operator*
and operator->
.
Note that std::auto_ptr
is still in the standard, but it is deprecated.
§D.10 [depr.auto.ptr]
The class template auto_ptr
is deprecated. [ Note: The class template unique_ptr
(20.7.1) provides a better solution. —end note ]
No ownership:
Use dumb pointers (raw pointers) or references for non-owning references to resources and when you know that the resource will outlive the referencing object / scope. Prefer references and use raw pointers when you need either nullability or resettability.
If you want a non-owning reference to a resource, but you don't know if the resource will outlive the object that references it, pack the resource in a shared_ptr
and use a weak_ptr
- you can test if the parent shared_ptr
is alive with lock
, which will return a shared_ptr
that is non-null if the resource still exists. If want to test whether the resource is dead, use expired
. The two may sound similar, but are very different in the face of concurrent execution, as expired
only guarantees its return value for that single statement. A seemingly innocent test like
if(!wptr.expired())
something_assuming_the_resource_is_still_alive();
is a potential race condition.
Always use a smart pointer wherever you own resources (memory, files etc). Owning them manually is extremely error prone and violates many good practices, like DRY.
Which one to use depends on what ownership semantics you need. unique_ptr
is best for single ownership, and shared_ptr
shared ownership.
As children do not own their parents, a raw parent pointer is fine. However, if the parents own their children, unique_ptr
works best here.
It's also notable that what on earth, a linked list of pointers? That makes no sense. Why not a linked list of values?
Best Answer
Here you specified that the precondition is that
Element
andFace
objects are created in aGrid
object with the elements of the container referring to the sameGrid
containers, therefore the lifetime of all three containers (points
,elms
andfaces
) is the same.Now you have to consider two cases.
Semi-immutable
points
In this case,
points
is guaranteed to never invalidate references to its elements (eg. it's never modified). Here you don't need any smart pointers, you can just use a simplestd::reference_wrapper
as follows:Another solution, non equivalent to your example (
elms
andfaces
don't have direct access to theVector3
object) might be to use indexes:That is, you store the indices of
points
.Mutable
points
If the operations performed on
points
can invalidate references, then you might want to consider another container that does not invalidate references/pointers/iterators to the element.For example
std::deque
guarantees the validity of references for deletion/insertion at the beginning and end of the container.Once you have chosen the correct container you can just apply the same ideas as above.