"Big" Objects and STL Containers

I just got through reading some of Stroustup's C++ Style and Technique FAQ.

Bjarne says that a "big" object is "Anything larger than a couple of words." and that you should pass such by reference. Cool, I can dig that.

Later on in the FAQ, there's a discussion of why STL containers can be slow when dealing with "huge" objects, and that an easy fix is to make a container of pointers like so:

Code:

---

vector<myHugeObject*> foo;

---

So what's "huge"? A few megabytes like in his example? Should I make all my vecotrs, lists, stacks, queues, etc. that have "big" objects as containers of pointers?

What are your thoughts?

what are you doing with them? Vectors = arrays so if you sort them those large objects will be shifted around in memory if I'm not mistaken while with a list, which is a series of node pointers when sorting the huge objects won't have to be moved in memory they stay put so unless I'm way off my rocker there is no advantage for pointers unless a STL vector is the container.

However, when passing a STL container

Code:

---

list<myHugeObject> foo;

---

into a function as a parameter:

Code:

---

void bob(list<myHugeObject> a)

---

the entire list of your myHugeObjects would be duplicated to the function stack in which case making a copy of all those myHugeObjects would be time consuming whereas a list of pointers would just duplicate the pointers which is fast. However, if you use pointers:

Code:

---

list<myHugeObject*> foo

---

that means you have to dynamically create each object and push it onto the list and upon being done you would have to deallocate each object yourself. An easy way to avoid this problem and an identical method without the need to allocate and deallocate yourself would be to simply pass your list of huge objects to every function by reference

Code:

---

list<myHugeObject> foo;
void bob(list<myHugeObject> &a);

---

essentially equals

Code:

---

list<myHugeObject*> foo;
void bob(list<myHugeObject*> a);

---

Essentially in the terms both are equally as fast, but one requires you handling the memory yourself. Of course the pointer version allows you to sort the list "a" within the function without modifying foo. If you plan on moving these huge objects between your vectors/lists though, pointers would be ideal as an entire copy of your objects wouldn't have to be done.

I'm sure someone will correct any lies I've told you.. :P

Anyways I would say don't go dynamic unless you need to. Just depends what you are up to.

Code:

---

list<myHugeObject*> foo;
...
myHugeObject *obj1 = foo.front();
foo.pop_front();

---

is faster than

Code:

---

list<myHugeObject> foo;
...
myHugeObject obj1 = foo.front();
foo.pop_front();

---

Because of the copying involved the pointer version should be faster. However the added complexity of memory management may or may not outweight the performance benefit. I saw significant slowdowns in my Asteroids game when not using pointers. I tried both ways for quite some time and decided to stay with the pointers. In general, however, either way probably does not matter in most applications. I was passing around some large objects which really signified to me that I needed to re-think my design. But I got lazy and it remains as is for now.

So a better question would be that if you find yourself storing unusually large objects you may want to ask if this is really the best approach? Perhaps a bit more thought on the design could alleviate the issue.

It depends on your situation. As Bubba stated, there is added complexity when storing pointers in a container that is the tradeoff for avoiding the overhead of copying your "huge" object.

There are now options beyond container<object*>, such as container<shared_ptr<object> > or boost::ptr_container that help reduce that added complexity. For any object that is expensive to copy (or that has disabled copying) I would consider using those choices. As to how big is too big, I would imagine it would be more than a few words but much less than a few megabytes. It really depends on your application.