Re: Deleting objects obtained from a STL library
From: Jeff Flinn (NONONE_at_nowhere.com)
Date: 08/06/04
- Next message: Daniel T.: "Re: abstract methods and inheritence"
- Previous message: Ryan Mitchley: "Re: Object factory and Intel compiler"
- In reply to: Aguilar, James: "Re: Deleting objects obtained from a STL library"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 6 Aug 2004 08:21:45 -0400
"Aguilar, James" <jfa1@cec.NOBOTSwustl.edu> wrote in message
news:ceusui$9fc$1@newsreader.wustl.edu...
>
> "Aguilar, James" <jfa1@cec.NOBOTSwustl.edu> wrote in message
> news:ceurna$934$1@newsreader.wustl.edu...
> > Hey guys. A new question:
> >
> Are the objects in the container the same objects as the ones that I used
to
> fill the container? Are they references to those objects, or are they
No, STL containers hold copies of the values you inserted into them. You can
not insert references into a container.
> copies of those objects? How did the container know how to make the
copies?
They use the copy constructor for the type passed.
> Are they just shallow copies of the original objects (i.e. all pointers
are
> the same, all other members were copied completely)?
That's up to you when you implement the copy constructor. If you don't
supply one, the compiler provided default is a member wise copy. ie: invokes
the copy constructor of each memeber.
> Secondly, suppose I have a function. There is a type called Object which
I
> use here:
>
> Object& fun1()
> {
> Object a;
> return a;
> }
>
> is not legal but
Because upon exit of fun1 a is destroyed, so you end up with a reference to
a destroyed object.
> Object fun1()
> {
> Object a;
> return a;
> }
>
> is. I think I understand why. However, let me ask you this: is this code
You end up with an Object that is a copy of 'a'.
> going to be inefficient if "Object" is ten kilobytes in size? Is what's
> actually happening in the second example is that the entire object is
being
> copied and returned? Lastly, if this is so, can this overhead be avoided
by
Maybe so, maybe not. Many compilers provide RVO and/or NRVO ( named return
value optimization ). Which would elide the copy. Hence, the rule - avoid
premature optimization.
> only passing ints and assigning all medium or large sized objects to the
> free store?
As another poster suggested, use boost::shared_ptr:
typedef boost::shared_ptr<Object> tObjPtr;
> tObjPtr fun1()
> {
> return tObjPtr( new Object );
> }
> Lastly, is there anything I can do with references that I can't do with
> pointers? Is there anything that is especially inelegant with pointers
that
References can't be reseated, and must be initialized.
[...]
> I guess my question is, on which side should I err: using the free store a
> lot and using pointers a lot, or using references a lot and perhaps paying
> overhead when I return large objects from methods?
You should really get a good C++ book and study the FAQ.
Jeff F
- Next message: Daniel T.: "Re: abstract methods and inheritence"
- Previous message: Ryan Mitchley: "Re: Object factory and Intel compiler"
- In reply to: Aguilar, James: "Re: Deleting objects obtained from a STL library"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
