Re: vectors and user-defined objects
On Jan 14, 6:19 pm, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article
<ea77bb89-125d-4d44-b447-de6cae4a6...@j78g2000hsd.googlegroups.com>,
Jim <j...@astro.livjm.ac.uk> wrote:
On Jan 14, 1:56 pm, jkherci...@gmx.net wrote:
Jim wrote:
Just wondering which is better
vector<record *> r;
r.push_back(new record(x,y));
Although Kai-uwe talks about it in his point (b), I think this
needs to be highlighted as this is fundamentally wrong: the
above is a memory leak.
It depends.
Unless you are using a very complex class, in C++ a "new"'ed object
can't own itself and can't free itself.
A lot do.
The only way this code can be used is if before r goes out of
scope, you individually read each of the stored pointers and
delete them.
In most cases where I've seen this, r would either have static
lifetime or be a singleton, never destructed. The constructor
of record would insert it into r, and the destructor removes it.
It's actually a very, very common idiom for entity objects.
The above code should never exist in isolation of its deleting
loop. If attempting to compare the two approaches, you must
include the deleting loop in the comparaison.
STL containers have value semantic and may copy their own
content freely around. STL containers do not know if they are
holding pointers or object and will never call "delete" on
their content.
And? That's usually exactly what is wanted. If the container
owns the objects, you'd usually use values (and the objects
cannot have identity, because the container copies them). If
the container doesn't own the objects, and the objects have
identity, then you need pointers. There are cases where you'd
want to delete the objects because the container is going out of
scope, but they are fairly rare.
vector<record> r;
r.push_back(record(x,y));
where record is just an object with a simple constructor.
I prefer the latter as it means I don't have to use
pointers, but am I taking a hit somewhere else?
IMNSHO, that should be your default solution. I.e. unless you
know that this is not suitable for this particular case, use
this form.
Let me see if I've got that straight. You should use this form
except when you shouldn't use it:-). (I'm being a bit facetious
there---I basically agree with you. But fundamentally, at least
in a number of domains, the first thing you should do is define
the semantics of your types. If the type has value semantics,
you copy it---everywhere, not just when it is in a container.
And if the type has entity semantics, you usually can't copy it,
so the question doesn't arise.)
[...]
There is no "better" in the abstract for this problem. The
following considerations may enter the picture:
That's correct, both approach have + and -. However, the
question seemed asked from the perspective of a inexperience
C++ programmer and I think RAII and storing values in standard
containers should be the initial approach until one knows
about all the issues listed below.
I think that learning the various "standard" categories of
objects should have precedence. Until you understand the
difference between value types and entity types, it doesn't make
sense to discuss the question.
(a) If you need the records in the vector to be
polymorphic, then you have to go with the first way (or
some smart-pointer based variation).
Just a note: most (but not all) polymorphic types are entity
types, which means that you would normally just use raw
pointers. The vector is a simple tool used for navigation.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34