Re: Simple const-related question
On Feb 19, 6:57 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
James Kanze wrote:
On Feb 19, 3:26 am, Jeff Schwab <j...@schwabcenter.com> wrote:
If I have dynamically allocated objects, I generally have to
store pointers to them somewhere anyway, so I let standard
containers deal with managing their lifetimes.
Except that if the standard container contains pointers, it
won't (and usually shouldn't) manage their lifetime.
Yes, it should. It shouldn't manage the lifetimes of the objects
pointed to by those pointers.
Yes. I should have been more precise. That's what I meant, of
course.
But anyway, I didn't mean that I store pointers in the
containers, I meant that I store the objects directly in the
containers.
Which is where you loose me, since generally, if you can copy an
object, there's no need to allocate it dynamically. And if you
cannot copy it, you can't store it directly in the container.
For example, if I'll need an unknown quantity of Foos, I just
create a std::list<Foo> and use its elements. Inserting or
deleting list elements does not invalidate pointers to the
other elements.
In my experience, most dynamically allocated objects are entity
objects. That means that they don't support copy, and so cannot
be put into a list.
The abstract (interface) type can't be copied, but the
concrete type generally can.
Since when? Identity is identity.
And of course, they're often polymorphic as
well.
If a factory may need to generate any of ten different concrete types
implementing a particular interface, then it can use ten different lists:
Which does what, other than make the code more complicated?
(And of course, the derived types may be derived by the
application.)
--
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