Storing object references in a simple container

Question

I am looking for a way to insert multiple objects of type A inside a container object, without making copies of each A object during insertion. One way would be to pass the A objects by reference to the container, but, unfortunately, as far as I've read, the STL containers only accept passing objects by value for insertions (for many good reasons). Normally, this would not be a problem, but in my case, I DO NOT want the copy constructor to be called and the original object to get destroyed, because A is a wrapper for a C library, with some C-style pointers to structs inside, which will get deleted along with the original object...

I only require a container that can return one of it's objects, given a particular index, and store a certain number of items which is determined at runtime, so I thought that maybe I could write my own container class, but I have no idea how to do this properly.

Another approach would be to store pointers to A inside the container, but since I don't have a lot of knowledge on this subject, what would be a proper way to insert pointers to objects in an STL container? For example this:

std::vector<A *> myVector;
for (unsigned int i = 0; i < n; ++i)
{
    A *myObj = new myObj();
    myVector.pushBack(myObj);
}

might work, but I'm not sure how to handle it properly and how to dispose of it in a clean way. Should I rely solely on the destructor of the class which contains myVector as a member to dispose of it? What happens if this destructor throws an exception while deleting one of the contained objects?

Also, some people suggest using stuff like shared_ptr or auto_ptr or unique_ptr, but I am getting confused with so many options. Which one would be the best choice for my scenario?

Either `boost::scoped_ptr` or `std::unique_ptr` will work - `std::vector>` — Captain Obvlious, Jun 19 '12 at 15:35
take a look either at `vector< shared_ptr >` or `boost::flyweight`. — Keynslug, Jun 19 '12 at 15:35
@pmr I do not ether. But depending on the context in which this container would be used, it may be a chance that `flyweight` will solve the whole problem. — Keynslug, Jun 20 '12 at 07:01

score 5 · Answer 1 · edited Mar 28 '14 at 03:54

5

You can use boost or std reference_wrapper.

#include <boost/ref.hpp>
#include <vector>

struct A {};


int main()
{
  A a, b, c, d;
  std::vector< boost::reference_wrapper<A> > v;
  v.push_back(boost::ref(a)); v.push_back(boost::ref(b)); 
  v.push_back(boost::ref(c)); v.push_back(boost::ref(d));
  return 0;
}

You need to be aware of object lifetimes when using reference_wrapper to not get dangling references.

int main()
{
  std::vector< boost::reference_wrapper<A> > v;
  {
    A a, b, c, d;
    v.push_back(boost::ref(a)); v.push_back(boost::ref(b)); 
    v.push_back(boost::ref(c)); v.push_back(boost::ref(d));
    // a, b, c, d get destroyed by the end of the scope
  }
  // now you have a vector full of dangling references, which is a very bad situation
  return 0;
}

If you need to handle such situations you need a smart pointer.

Smart pointers are also an option but it is crucial to know which one to use. If your data is actually shared, use shared_ptr if the container owns the data use unique_ptr.

Anyway, I don't see what the wrapper part of A would change. If it contains pointers internally and obeys the rule of three, nothing can go wrong. The destructor will take care of cleaning up. This is the typical way to handle resources in C++: acquire them when your object is initialized, delete them when the lifetime of your object ends.

If you purely want to avoid the overhead of construction and deletion, you might want to use vector::emplace_back.

edited Mar 28 '14 at 03:54

allyourcode

21,871
18
78
106

answered Jun 19 '12 at 15:35

pmr

58,701
10
113
156

`std::reference_wrapper` seems to be the best choice, because VS2010 does not have the proper `emplace_back` functionality implemented, yet. So, if I'll use `std::reference_wrapper`, do I still need to take care of memory deallocation manually or is it all done behind the hood? – Mihai Todor Jun 19 '12 at 16:09
@MihaiTodor Be careful. You always need to be aware of the life time of your objects when using reference wrapper. I'll add an example. – pmr Jun 19 '12 at 16:32
So, let's say I skip `std::reference_wrapper` and use `std::vector< std::unique_ptr > v;` instead. Will the issue that you described above still occur? I'm not sure I understand how this works. I mean, I am fully aware that `A a, b, c, d;` will get destroyed at the end of the block, and, thus, will mess up my vector, which is not what I want... – Mihai Todor Jun 19 '12 at 16:39
@MihaiTodor You have to ask yourself why you would need to manully allocate in the first place. It seems useless from what I have gathered. Otherwise the issue would go away with a `unique_ptr`. – pmr Jun 19 '12 at 21:19
I'm afraid that I don't understand what you mean. If I have `std::vector< std::unique_ptr > v;` as a class member, and in one of the class methods I do `this->v.push_back(std::unique_ptr (new A(x, y)));`, will the destructor of `A` get called after this statement executes (or even sooner)? – Mihai Todor Jun 19 '12 at 23:14
My tests show that it does work nicely and it does not mess up the vector in VS2010, but I'm trying to make sure that I'm doing this properly... – Mihai Todor Jun 19 '12 at 23:30
1

@MihaiTodor When using `unique_ptr` the destructors of all `A`s will be called when the vector goes out of scope or when you manually reset one of the pointers. – pmr Jun 20 '12 at 08:34
Yes, after reading more on this subject, I'm convinced now that it really works well for my requirements. Thanks for your help! – Mihai Todor Jun 20 '12 at 08:39

Mike Seymour · Accepted Answer · 2012-06-19T16:14:51.460

4

In C++11, you can construct container elements in place using emplace functions, avoiding the costs and hassle of managing a container of pointers to allocated objects:

std::vector<A> myVector;
for (unsigned int i = 0; i < n; ++i)
{
    myVector.emplace_back();
}

If the objects' constructor takes arguments, then pass them to the emplace function, which will forward them.

However, objects can only be stored in a vector if they are either copyable or movable, since they have to be moved when the vector's storage is reallocated. You might consider making your objects movable, transferring ownership of the managed resources, or using a container like deque or list that doesn't move objects as it grows.

UPDATE: Since this won't work on your compiler, the best option is probably std::unique_ptr - that has no overhead compared to a normal pointer, will automatically delete the objects when erased from the vector, and allows you to move ownership out of the vector if you want.

If that's not available, then std::shared_ptr (or std::tr1::shared_ptr or boost::shared_ptr, if that's not available) will also give you automatic deletion, for a (probably small) cost in efficiency.

Whatever you do, don't try to store std::auto_ptr in a standard container. It's destructive copying behaviour makes it easy to accidentally delete the objects when you don't expect it.

If none of these are available, then use a pointer as in your example, and make sure you remember to delete the objects once you've finished with them.

edited Jun 19 '12 at 16:14

answered Jun 19 '12 at 15:52

Mike Seymour

249,747
28
448
644

That's really neat Mike, but unfortunately, I am using VS 2010, which, at the moment, provides just a redundant emplace_back as noted here http://stackoverflow.com/a/4306581/1174378 so it seems that I'm unable to use this feature, because the object's constructor takes some arguments :( – Mihai Todor Jun 19 '12 at 16:01
@MihaiTodor: That's a shame. I've updated the answer with some alternatives. – Mike Seymour Jun 19 '12 at 16:11
Ok, neat! But if I use `std::unique_ptr` or `std::shared_ptr`, does the memory get deallocated automagically? How would I dispose of the vector? – Mihai Todor Jun 19 '12 at 16:11
1

@MihaiTodor: Yes, they both delete the managed object when they're destroyed (in the case of `shared_ptr`, when the last copy of the pointer is destroyed). In your example, the vector has automatic storage, so it will be destroyed automatically when it goes out of scope. – Mike Seymour Jun 19 '12 at 16:13
That's really nice. In this case, I can definitely use `std::unique_ptr`, but, just out of curiosity, I want to compare this approach to using `std::reference_wrapper`. I'm not sure which one is better, as noted in @pmr's answer. – Mihai Todor Jun 19 '12 at 16:17
@MihaiTodor: `reference_wrapper` doesn't manage the object's lifetime; in that example, the objects are all automatic variables scoped inside `main`. It doesn't really give you anything that a simple pointer doesn't, except that it makes the vector look like it contains objects rather than pointers. – Mike Seymour Jun 19 '12 at 16:20
So that means that I have to take care of deallocating the vector myself? Nasty. I will stick to `std::unique_ptr` in this case. Thanks a million! – Mihai Todor Jun 19 '12 at 16:24

Storing object references in a simple container

2 Answers2