Creating dynamically allocating abjects with "new"keyword

[conceptualtechnologist]

Is it OK to create dynamically allocating objects with new keyword ? for example consider std::vector i.e. pointer = new std::vector
if I add many objects to vector, then it may need to copy itself to another location of RAM. then pointer value is no longer correct. how can I access the object then ?

 

[Goran]

Is it OK to create dynamically allocating objects with new keyword ? for example consider std::vector i.e. pointer = new std::vector

This is OK. You have to eventually call delete on "pointer".

if I add many objects to vector, then it may need to copy itself to another location of RAM. then pointer value is no longer correct. how can I access the object then ?

There's no such thing as a pointed-to object (like your vector)
"moving itself" to another location. You might be thinking about
vector moving it's (internal) contents to another location. That will
invalidate pointers to objects __inside__ the vector that you might
hold, but not the pointer to the vector itself.

It would be best that you show exact, compilable code snippet that
somehow represents your doubts.

Goran.

 

[Victor Bazarov]

Is it OK to create dynamically allocating objects with new keyword ?
for example consider std::vector i.e. pointer = new std::vector if I
add many objects to vector

Yes, there is no special provision about that in the Standard.

A nitpick: there is no type 'std::vector', it's a template. If you need
to create an object, you need a concrete type. For instance, to create

, then it may need to copy itself to
another location of RAM.

Objects cannot copy themselves. 'this' pointer is non-assignable.

then pointer value is no longer correct.

I don't understand what you're trying to say.

Standard containers manage their own dynamic memory. It does not matter
where the object itself lives. The two locations (of the container
object and of its contained items) are independent. Standard vector
keeps its elements in an array allocated in the freestore (using new[]
operator).

how
can I access the object then ?

The same way you always access the object.

If you're experiencing some kind of a problem, get to it. If you're
trying to theorise about what would happen to a vector's storage if the
vector itself moves from one place in memory to another, which is OK if
it's dynamically allocated, then there is nothing to worry about. As I
said before, the storage for the vector's elements and the storage for
the vector itself are *independent*. Moving one does not invalidate the
other. That's how you can have vectors or vectors.

V

 

[conceptualtechnologist]

Thank Goran and Leigh and Victor

Well my codes are in MFC(VC++) not stdlib and it is very big. actually std:vector was just an example and I have a class that I want to store its instances in a map(more exactly CMap). the class is very big(has lots of CArrays(counterpart of std::vector) and accepts data from a device and amount ofdata can be really high(maybe some 10s MB after some time). so I thought is it a good way to store them in CMap. I have used map because I want to find objects very fast by their key, because packets may come from device with high speed and I need to dispatch them to the right object.
Your explanations was very helpful and almost made me sure that there is nothing to worry. only one thing if a class like std::vector has an internal array that stores address or value of its objects, what happens when that internal array grows so much that it needs to be relocated. I mean will the std::vector breaks the internal array in parts or can move even internal array to another location ( <b> in addition to moving the contents of internal array </b>) and keeps the base object in the place first returned by the "new" keyword ?

 

[Victor Bazarov]

[..]
explanations was very helpful and almost made me sure that there is
nothing to worry. only one thing if a class like std::vector has an
internal array that stores address or value of its objects, what
happens when that internal array grows so much that it needs to be
relocated.

It gets reallocated.

I mean will the std::vector breaks the internal array in
parts
No.

or can move even internal array to another location (<b> in
addition to moving the contents of internal array</b>) and keeps the
base object in the place first returned by the "new" keyword ?

I don't know what you mean by 'base object', sorry. Yes, the [internal]
array is fully reallocated in another place, just to keep being
contiguous, which is a requirement.

There are several implementations of 'std::vector' that are available on
the 'net. Just take a look how they work, and many questions are going
to be answered. Even your compiler's implementation is likely fully
open for studying.

Also, find a decent book on Standard Library (Nicolai Josuttis has
written a wonderful, albeit rather large, one), and read it.

V

 

[none]

value is no longer correct. how can I access the object then ?

There is no need to allocate a std::vector object with new as the vector
itself contains its own pointer to the allocated elements also called
the "controlled sequence".

Well, if you want to std::vector object lifetime to goes beyond
current scope, you probably should allocate the std::vector object
with new.

However, you do not need to allocate the std::vector with new if you
just don't want to put a lot of data on the stack. As Leigh describe,
the std::vector will own a controlled sequence and the data will be in
freestore (often referred to as "heap" although this is not the
official word used in the C++ standard)

A vector does not copy "itself" when you add
many elements; it may however need to reallocate the controlled sequence
depending on what the current capacity() of the vector is.

Exactly, the vector is perfectly allowed to move the location of its
controlled sequence (where the data is) but it will never move itself
of its free-will

Yannick

 

[Juha Nieminen]

std::vector can be passed around by value, which is fine most of the times;
if performance suffers, one can replace passing-by-value by swap()-ing out
the vector content from the current scope, or use C++0x move constructors.
No need to use any pointers or dynamic allocation here.

I wish there were official versions of all containers that explicitly
use reference counting instead of deep copying. They could be named like
std::shared_vector, std::shared_list, std::shared_map and so on (in the
same vein as std::shared_ptr).

 

[gwowen]

std::vector can be passed around by value, which is fine most of the times;

[citation needed]

 

[Juha Nieminen]

std::vector can be passed around by value, which is fine most of the times;

[citation needed]

Citation to what? That it can be passed by value, or that it's "fine
most of the times"? (The former is a fact, the latter is an opinion.)

 

[gwowen]

Paavo Helde wrote:

[citation needed]

  Citation to what? That it can be passed by value, or that it's "fine
most of the times"? (The former is a fact, the latter is an opinion.)

Well, you know, some sort of evidence or measurements that caused you
to form the opinion that its "fine most of the times". Do common
implementations reference count, or are you claiming that deep copies
are fine "most of the times"?

 

[Victor Bazarov]

Paavo Helde wrote:

std::vector can be passed around by value, which is fine most of the times;

[citation needed]

Citation to what? That it can be passed by value, or that it's "fine
most of the times"? (The former is a fact, the latter is an opinion.)

Well, you know, some sort of evidence or measurements that caused you
to form the opinion that its "fine most of the times". Do common
implementations reference count, or are you claiming that deep copies
are fine "most of the times"?

If we set aside your mutual desire to have your daily sparring match,
then the original claim about passing "around" by value is bogus, of
course, unless only one side of it is considered - returning by value -
which is often "fine" if RVO is in effect. Passing *into* a function
should be done by ref to const to *avoid* performance problems, of course.

V