Thread: 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

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.

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.

True, but a shared_ptr for InputEvent sounds like massive overkill.

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.