Objects or pointers in STL containers?

This is a discussion on Objects or pointers in STL containers? within the C++ Programming forums, part of the General Programming Boards category; G'day, Doing a little input manager for a project of mine. Basically I have an input event (InputEvent), which is ...

  1. #1
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459

    Objects or pointers in STL containers?

    G'day,

    Doing a little input manager for a project of mine. Basically I have an input event (InputEvent), which is a simple, small class. And then a user-defined function which takes an std::queue<InputEvent>.

    The user-defined function is called about 100 times a second. With say a max of 10 input events per-call. Is it wise to be storing InputEvent objects in the queue or should I be storing pointers?

    Basically I don't want to make the user free the InputEvent pointers themselves.

    Secondly, should I specifically make my InputEvent copyable (ie override operator=)?

    In short I have,

    My library
    Code:
    // ...
    
    std::queue<InputEvent> events_;
    
    // ... add the events to the queue
    
    events_.push(InputEvent(x, y));
    events_.push(InputEvent(x, y));
    events_.push(InputEvent(x, y));
    
    client->frame(&events_);
    
    // ...
    User's code
    Code:
    void frame(std::queue<InputEvent> * events)
    {
        // the InputEvents are removed from the queue
    }
    Thanks!
    Zac
    Last edited by zacs7; 06-21-2009 at 07:47 PM.

  2. #2
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,738
    Is it wise to be storing InputEvent objects in the queue or should I be storing pointers?

    Basically I don't want to make the user free the InputEvent pointers themselves.
    I don't see how using pointers would buy you anything. If at all, it would be wiser to specify another underlying container type for queue (going by the spec here: Dinkumware, Ltd. - Compleat Libraries Reference) and solve any bottleneck caused by deque that way. I guess you would use a memory pool.

    Secondly, should I specifically make my InputEvent copyable (ie override operator=)?
    The queue copies itself by copying the container sequence, so you could safely delegate responsibilities to that type. If deque is sufficient, then you must make InputEvents copyable.

  3. #3
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,894
    Quote Originally Posted by zacs7
    Secondly, should I specifically make my InputEvent copyable (ie override operator=)?
    If your InputEvent is not copyable, you should not be storing objects of that type in a std::queue (though it does depend on the underlying container). Whether you need to implement the copy constructor, copy assignment operator and destructor yourself depends on whether the class contains only members that already manage their own memory, or if you need to implement memory management yourself (or resource management in general).

    By the way, make the parameter a reference rather than pointer, unless it makes sense to pass a null pointer as an argument.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #4
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Ah thank-you, that does shed some light on it :-)

    > By the way, make the parameter a reference rather than pointer, unless it makes sense to pass a null pointer as an argument.
    Will do, that was left in there from a poor design to pass NULL if there weren't any input events... rather than an empty queue.

    Thanks again.

  5. #5
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by zacs7 View Post
    Basically I don't want to make the user free the InputEvent pointers themselves.
    If you use shared_ptr, they don't have to delete them.

  6. #6
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    True, but a shared_ptr for InputEvent sounds like massive overkill.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  7. #7
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Agreed, I was just addressing the memory mgmt concern.

  8. #8
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,248
    1) Are the input event objects dynamically allocated in the first place? Then you have already paid the costs of doing that and there's no reason to copy the objects in order to store them. Does copying an event even make sense?

    2) Are you really using the correct data structure? The copy-constructor expense is completely removed if you use std::list, since individual container elements never have to move in memory.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. "Big" Objects and STL Containers
    By dudeomanodude in forum C++ Programming
    Replies: 3
    Last Post: 02-27-2008, 11:13 PM
  2. pointers in arrays... Declaring objects in a loop.
    By Guest852 in forum C++ Programming
    Replies: 10
    Last Post: 04-05-2005, 06:57 AM
  3. stl - searching for elements in containers
    By Raven Arkadon in forum C++ Programming
    Replies: 4
    Last Post: 03-24-2005, 10:10 AM
  4. array of pointers to objects
    By xion in forum C++ Programming
    Replies: 6
    Last Post: 02-07-2005, 06:14 PM
  5. pointers
    By InvariantLoop in forum C Programming
    Replies: 13
    Last Post: 02-04-2005, 08:32 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21