clarification on pointer use

[Ruby Stevenson]

All -

I have a newbie question. Let me try to use an example to illustrate:
I have some Event class defined, and I could save a collection of
event objects in two ways:

method 1:
vector<Event*> event_vec;
....

Event * event = new Event();
event_vec.push_back(event);

method 2:
vector<Event> event_vec;
....
Event event;
event_vec.push_back(event)

So one is store a pointer to event; the other store a copy of the
event in a container.
what are the implications between the two choices? when would be the
proper use of one instead of the other?

Thanks

Ruby

 

[Victor Bazarov]

I have a newbie question. Let me try to use an example to illustrate:
I have some Event class defined, and I could save a collection of
event objects in two ways:

method 1:
vector<Event*> event_vec;
....

Event * event = new Event();
event_vec.push_back(event);

method 2:
vector<Event> event_vec;
....
Event event;
event_vec.push_back(event)

So one is store a pointer to event; the other store a copy of the
event in a container.
what are the implications between the two choices? when would be the
proper use of one instead of the other?

Implications are the same as storing a copy versus storing a pointer to
the original object anywhere else. Changing the copy has no effect on
the original object, so if you expect to pass it around, the changes
have to be carefully tracked. Storing a pointer puts the responsibility
of maintaining the lifetime on you, whereas a copy lives its own life
under the control of the container in which it's stored. Storing a copy
could require more memory and be generally slower than storing a
pointer... I am sure there are other differences, and you can probably
find lots of interesting stuff about those in any decent book on C++.
What book are you currently reading?

V

 

[Juha Nieminen]

So one is store a pointer to event; the other store a copy of the
event in a container.
what are the implications between the two choices? when would be the
proper use of one instead of the other?

Storing the Event objects by value is much safer (and depending on
its size, often more efficient) than storing pointers to dynamically
allocated Event objects.

However, storing them by value requires that Event objects can be
copied (which means that if Even contains any dynamically allocated
resources, those have to be handled properly in its copy constructor
and assignment operator). If Event contains only basic (non-pointer)
types and class objects (which themselves have working copy constructors)
as members then you don't need to do anything special about it, and it
will work just fine. However, as said, if Event contains dynamically
allocated resources (in most cases having a pointer as member is usually
an indication of this).

Also take into account that if Event is very large (eg. it could contain
things like large std::vectors as members) copying will be a heavy
operation.

Storing dynamically allocated Event objects is error-prone because it
requires you to delete them appropriately (or else you'll get a memory
leak). Usually, if this is required, it's better to use a smart pointer
instead of a raw pointer.

Storing them as pointers allows runtime polymorphism (which storing by
value does not allow). In other words, you could store in the vector
objects of type Event or any object derived from it. This is about the
only advantage of storing pointers instead of objects. (The other is,
as said, if the objects are very large and are heavy to copy.)

 

[Christopher]

All -

I have a newbie question. Let me try to use an example to illustrate:
I have some Event class defined, and I could save a collection of
event objects in two ways:

method 1:
    vector<Event*> event_vec;
    ....

    Event * event = new Event();
    event_vec.push_back(event);

method 2:
   vector<Event> event_vec;
   ....
   Event event;
   event_vec.push_back(event)

So one is store a pointer to event; the other store a copy of the
event in a container.
what are the implications between the two choices? when would be the
proper use of one instead of the other?

Thanks

Ruby

A little ranting on the side, since the main question has been
answered. It's a pet peave of mine to use such generic names as
"event". Try to get into the habit of naming the class for what it
really is and the variable for what it really is. Unless of course,
you are designing it to be a truly generic event.

Example: KeyPressed keyPress;

 

[Jorgen Grahn]

....

A little ranting on the side, since the main question has been
answered. It's a pet peave of mine to use such generic names as
"event". Try to get into the habit of naming the class for what it
really is and the variable for what it really is. Unless of course,
you are designing it to be a truly generic event.

Example: KeyPressed keyPress;

Wouldn't that be obvious from context in a real program, though? For
all we know, Event may be local to keypress.cc, to class Keyboard, or
in some appropriate namespace.

It's a pet peeve of /mine/ when people duplicate context information;
for example I find it easier to read keyboard.event than
keyboard.keyboardEvent (or keyboard.keyboardEvent.keyCode).

/Jorgen