Thread: "Big" Objects and STL Containers

  1. #1
    Use this: dudeomanodude's Avatar
    Join Date
    Jan 2008
    Location
    Hampton, VA
    Posts
    391

    "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?
    Ubuntu Desktop
    GCC/G++
    Geany (for quick projects)
    Anjuta (for larger things)

  2. #2
    Registered User
    Join Date
    Jun 2007
    Posts
    41
    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();
    Last edited by HyperShadow; 02-27-2008 at 11:04 PM.

  3. #3
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    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.
    Last edited by VirtualAce; 02-27-2008 at 11:49 PM.

  4. #4
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Objects or pointers in STL containers?
    By zacs7 in forum C++ Programming
    Replies: 7
    Last Post: 06-23-2009, 10:25 AM
  2. im extreamly new help
    By rigo305 in forum C++ Programming
    Replies: 27
    Last Post: 04-23-2004, 11:22 PM
  3. Prime Number Generator... Help !?!!
    By Halo in forum C++ Programming
    Replies: 9
    Last Post: 10-20-2003, 07:26 PM
  4. include question
    By Wanted420 in forum C++ Programming
    Replies: 8
    Last Post: 10-17-2003, 03:49 AM
  5. Pointer Elements & STL Containers :: STL
    By kuphryn in forum C++ Programming
    Replies: 2
    Last Post: 09-30-2002, 08:13 PM