Tag Info

Hot answers tagged

3

Here's my opinion on the matter: consider whether both variants can actually be used in your case. reference_wrapper is, by design, not default-constructible. That means you will not be able, for example, to call container.resize() when using the reference wrapper. A shared_ptr, on the other hand, is default-constructed to an invalid/NULL state. So, for ...


1

The question is one of ownership You make no mention of who owns the objects going into the container. Since the shared_ptr is an option, there is probably some form of shared ownership and dynamic storage allocation. A clear definition of who owns the objects and how they are observed (i.e. who can observe them) will frame much of the implementation. ...


1

It's mostly a question of lifetime and ownership. A container using reference_wrapper doesn't own its objects or manage their lifetime, a container using shared_ptr does. If your container shouldn't own its objects, then use reference_wrapper. If it should own its objects, then I'd take a third option. Boost.Pointer Container has template classes such as ...


1

Java References and C pointers differ in exactly two points: There's no pointer-arithmetic for the former. And you cannot create a Java reference to whatever you want, you can only copy those saved somewhere accessible (static fields, fields of objects, local variables) or returned by function-invocations (like constructor-calls), which thus all refer to ...



Only top voted, non community-wiki answers of a minimum length are eligible