On Sep 11, 11:03 pm, werasm <wer...@gmail.com> wrote:
terminator wrote:
I said huge because a container contains data spatered all over the
heap and when it comes to copy(instead of reference) ,then it does not
matter if the data is stored in a contigeous portion of memory or
segmented into peices on different corners of memory.the actual size
of a container is often much larger than its own data structure(one or
two pointers and intrinsic values as well as the vtable in runtime
polymorphic ones).
In that case I don't see how it contributes to your argument of using
a pointer to the container instead of the actual container, if I
understand you correctly, as whether one uses a pointer to
a container, or the container itself, you always going to use the
heap, and in the case of a pointer to the container, slightly more
than in the other case, as now the pointer members are also on
the heap.
only dynamic objects are placed on heap not pointers to objects,also
pointers can simply point to some stack variable in the presenet
thread as well.
The contribution? Very obvious!!! Copying containers is generally both
memory and runtime consuming and should be avoided whenever
possible ,and the simplest way is to use ref/ptr semantics.
As far as inside a container is concerned, it depends on the type
T. Typically, if I want to prevent copying, I use either pointers,
or even a pointer_container aka. boost::ptr_vector. If copying of
the container does not happen often, and T has the relevant
members required, then I use T (by value).
I am talking about the container itself, not the elements.If one
address/refrences a container no element copy is performed but copying
a container is a nightmare sometimes,eventhough elements are pointers.
Yes, what you say is true, but it is a question of semantics. For some