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

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.

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.

Originally Posted by zacs7

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.

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

Agreed, I was just addressing the memory mgmt concern.

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.