Array of pointer to std::vector and memory allocation


H

hapa

Hello,

does the following bear any risk for memory problems?

We are using a construct like the following:

std::vector<data*> *m_vecData[1000][1000]; //array of ptrs to vector

later there will be a memory allocation for some pointers out of array via:

if(condition ==true)
{
m_vecData[?][?] = new std::vector<data*>;
m_vecData1[?][?]->reserve(2000);
}
when finished then:

if( m_vecData1[?][?] !=NULL )
delete m_vecData1[?][?];


While debugging no memory leaks are produced, but randomly the
"reserve(2000)" will not be done correctly or the "new" command failes and
crashes the application.

Thanks for advice!
Hapa
 
Ad

Advertisements

J

Juha Nieminen

hapa said:
does the following bear any risk for memory problems?

When you start writing raw 'new' and 'delete' commands in C++, there
will always be a risk of memory management problems.
We are using a construct like the following:

std::vector<data*> *m_vecData[1000][1000]; //array of ptrs to vector

Is there a reason why the array cannot have std::vector objects as
elements, instead of pointers to std::vector objects? That way you don't
need to allocate the std::vector objects with 'new'.
 
H

hapa

hapa said:
does the following bear any risk for memory problems?

When you start writing raw 'new' and 'delete' commands in C++, there
will always be a risk of memory management problems.
We are using a construct like the following:

std::vector<data*> *m_vecData[1000][1000]; //array of ptrs to vector

Is there a reason why the array cannot have std::vector objects as
elements, instead of pointers to std::vector objects? That way you don't
need to allocate the std::vector objects with 'new'.

hapa>
when taking all the memory for this array of vectors
the stack will overflow, so the decision was to use
only pointers, and create an object when needed.
 
Ö

Öö Tiib

Hmm 1000 * 1000 * 2000 * 8 is ... 16 gigabytes. If your system has 32
gigabytes then half of it goes to fully filled thing of yours. If it
is a problem, squeeze another 32 gigabytes in, then may fit ...
depending how big is that "data".
  When you start writing raw 'new' and 'delete' commands in C++, there
will always be a risk of memory management problems.
We are using a construct like the following:
std::vector<data*> *m_vecData[1000][1000]; //array of ptrs to vector
  Is there a reason why the array cannot have std::vector objects as
elements, instead of pointers to std::vector objects? That way you don't
need to allocate the std::vector objects with 'new'.

when taking all the memory for this array of vectors
the stack will overflow, so the decision was to use
only pointers, and create an object when needed.

Increase stack. Make it one gigabyte. Then vectors should fit.
Seriously, why you need million of vectors of 2000 pointers to "data".
 
Ad

Advertisements

J

Juha Nieminen

hapa said:
when taking all the memory for this array of vectors
the stack will overflow, so the decision was to use
only pointers, and create an object when needed.

Usually you shouldn't abuse the stack for extremely large amounts of
data because stack size is usually limited (and its size may be different
in different systems, so even if the program would work in one system it
might not work in another, at least not without meddling with compiler or
system settings).

Anyways, if sizeof(std::vector<T>) is too large (in some implementations
it can be significantly larger than a pointer), the best alternative is
not to use raw pointers which point to dynamically allocated std::vector
objects (because not only will you get a memory management nightmare, you
will also be wasting memory), but to write your own simplistic 'vector'
implementation where an instantiation of your 'vector' class has the
size of one pointer (which is perfectly possible).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top