By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,330 Members | 1,438 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,330 IT Pros & Developers. It's quick & easy.

Dynamically allocated array question

P: n/a
Ok, everyone loves to talk about dynamic arrays and ptr's etc, they provide
endless conversation :) so here goes:

Will this leak memory (my intuition says yes):

void foo(vector<int*>& vec)
{
int* pInts = new int[100];
for(int i = 0; i < 100; i++)
vec.push_back(pInts[i]);
}

// It can be assumed that later on in the program vec will have
// delete called on each individual element

This example is to simulate a technique I am using involving more
complicated stuff so yes I realize there are better ways to do the above in
this simple case.

But also I will explain what I am trying to do in the bigger picture in case
anyone wishes to make suggestions.

I want to fill a container (a vector but it shouldnt matter what) with ptr's
to instances of objects. But there will be millions of these objects and I
wish to allocate them all at once and add them to the container. The
calling code doesn't really know the exact type of the object that will go
into the container, it only knows they will at least derive off the type of
the ptr in the container. BUT in reality they will all be the same object,
which is why i want to allocate them all at once... for speed and to avoid
fragmenting memory.

So the obvious solution of something like:

vector<basePtr*> vec;
vec.reserve(1000000);
for(int i = 0; i < 1000000; ++i)
{
basePtr* pOb = CreateObject(); // virtual func
vec.push_back(pOb);
}

isn't the solution I want

Jeff
Jul 19 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
On Mon, 18 Aug 2003 16:30:34 GMT, "Jeff Williams" <no*********************************@mfchelp.com > wrote:
Ok, everyone loves to talk about dynamic arrays and ptr's etc, they provide
endless conversation :) so here goes:

Will this leak memory (my intuition says yes):

void foo(vector<int*>& vec)
{
int* pInts = new int[100];
for(int i = 0; i < 100; i++)
vec.push_back(pInts[i]);
}
You don't need intutition for that: there is an allocation, no
corresponding deallocation, and the pointer value is lost on exit
from the function so there can not be later deallocation either.
// It can be assumed that later on in the program vec will have
// delete called on each individual element
In that case each element must be allocated via 'new'.
I want to fill a container (a vector but it shouldnt matter what) with ptr's
to instances of objects. But there will be millions of these objects and I
wish to allocate them all at once and add them to the container.


std::vector<SmallObject> smallObjectCache( cacheSize );

Also/alternatively check up on the fly-weight pattern, if you haven't.

Jul 19 '05 #2

P: n/a
Jeff Williams wrote:
Ok, everyone loves to talk about dynamic arrays and ptr's etc, they
provide endless conversation :) so here goes:

Will this leak memory (my intuition says yes):

void foo(vector<int*>& vec)
{
int* pInts = new int[100];
for(int i = 0; i < 100; i++)
vec.push_back(pInts[i]);
}

// It can be assumed that later on in the program vec will have
// delete called on each individual element
Actually it cannot be assumed. And even if vec *did* call delete,
"delete"ing every element of a dynamically allocated array is definitely an
error. You must invoke delete[] on pInts, no two ways about it.
This example is to simulate a technique I am using involving more
complicated stuff so yes I realize there are better ways to do the above
in this simple case.

But also I will explain what I am trying to do in the bigger picture in
case anyone wishes to make suggestions.

I want to fill a container (a vector but it shouldnt matter what) with
ptr's
to instances of objects. But there will be millions of these objects and
I
wish to allocate them all at once and add them to the container. The
calling code doesn't really know the exact type of the object that will go
into the container, it only knows they will at least derive off the type
of
the ptr in the container. BUT in reality they will all be the same
object, which is why i want to allocate them all at once... for speed and
to avoid fragmenting memory.


Sorry, I don't understand what you 're trying to do :-(

Jul 19 '05 #3

P: n/a
Dimitris Kamenopoulos wrote:

void foo(vector<int*>& vec)
{
int* pInts = new int[100];
for(int i = 0; i < 100; i++)
vec.push_back(pInts[i]);
}

// It can be assumed that later on in the program vec will have
// delete called on each individual element


Actually it cannot be assumed. And even if vec *did* call delete,
"delete"ing every element of a dynamically allocated array is definitely
an error. You must invoke delete[] on pInts, no two ways about it.


Furthermore, what you would get in the vector if your example compiled (IOW
if vec was vector<int>) is a copy of every int stored in pInts, the
"contents" of pInts[*] themselves live happily ever after and, of course,
are leaked.
[*] more accurately, the contents of the memory pointed to by pInts.
Jul 19 '05 #4

P: n/a
Jeff Williams wrote:
...
Will this leak memory (my intuition says yes):

void foo(vector<int*>& vec)
{
int* pInts = new int[100];
for(int i = 0; i < 100; i++)
vec.push_back(pInts[i]);
}
The code makes no sense. Your vector stores values of type 'int*' and
you are pushing values of type 'int' into it. Please, always try posting
real (or at least compilable) code.

You probably meant something like

vec.push_back(&pInts[i]);

or

vec.push_back(pInts + i);
// It can be assumed that later on in the program vec will have
// delete called on each individual element


You can't call 'delete' on each individual element in this case. What
you can do is to call 'delete[]' on all elements at once:

delete[] vec.front();

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

Jul 19 '05 #5

P: n/a
Yes my example code was in error, let me post the correct version and clean
up my question a little:

new example code:

struct base_class { };
struct derive_class : base_class { };

void foo(std::vector<base_class*>& vec)
{
base_class* pBases = new derive_class[100];
for(int i = 0; i < 100; ++i)
vec.push_back(&pBases[i]);
}

void bar(std::vector<base_class*>& vec)
{
for(int i = 0; i < vec.size(); ++i)
delete vec[i];
vec.clear();
}

// I dont give a crap that the main func has bad prototype so dont even
bother
int main()
{
std::vector<base_class*> vec;
foo(vec);
bar(vec);
return 0;
}
Now, with this example only, is memory leaked? My intuition says yes
because I allocated with new[] but didnt de-allocate with delete[], so
somewhere the compiler must have stored the size of the array but it never
cleaned that up.

And just forget about the latter part of my original question, I didn't
provide enough context to make it clear and doing so would require more time
and space than most would care to read I believe.

Jeff
"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:3f415089@shknews01...
Jeff Williams wrote:
Ok, everyone loves to talk about dynamic arrays and ptr's etc, they provide endless conversation :) so here goes:

Will this leak memory (my intuition says yes):


As far as I can tell, it will not. But only because it won't compile.

void foo(vector<int*>& vec)
{
int* pInts = new int[100];
for(int i = 0; i < 100; i++)
vec.push_back(pInts[i]);
}


vec holds int pointers. pInts[i] is an int. Implicit conversion from int
to int * is not allowed.

// It can be assumed that later on in the program vec will have
// delete called on each individual element


That would create an error, since each individual element is *not* a
pointer to something that was allocated with 'new'. You don't get to
make up the rules for how 'new' and 'delete' are used. They are:
Anything that is created with 'new' must eventually be destroyed by
applying 'delete' to it exactly once. Anything that is created with
'new[]' must eventually be destroyed by applying 'delete[]' to it
exactly once.

This example is to simulate a technique I am using involving more
complicated stuff so yes I realize there are better ways to do the above in this simple case.

But also I will explain what I am trying to do in the bigger picture in case anyone wishes to make suggestions.

I want to fill a container (a vector but it shouldnt matter what) with ptr's to instances of objects. But there will be millions of these objects and I wish to allocate them all at once and add them to the container. The
calling code doesn't really know the exact type of the object that will go into the container, it only knows they will at least derive off the type of the ptr in the container. BUT in reality they will all be the same object, which is why i want to allocate them all at once... for speed and to avoid fragmenting memory.


That's fine, but possibly misguided. Are you sure allocating all at once
will speed it up enough to be worth the effort? Also, what if you can't
get a single, huge chunk of memory large enough to hold all of the
objects, but you *can* get 2 or 3 smaller chunks that together are large
enough?

So the obvious solution of something like:

vector<basePtr*> vec;
vec.reserve(1000000);
for(int i = 0; i < 1000000; ++i)
{
basePtr* pOb = CreateObject(); // virtual func
vec.push_back(pOb);


What's wrong with

vec.push_back(CreateObject());

?
}

isn't the solution I want


Why not? It looks fine to me (except for the part about CreateObject
being virtual). CreateObject could simply return the next available
object in your massive allocation.

In fact, you could make it a bit better by doing something like this:

class Cache
{
public:
Cache() : p(new SomeObject[1000000]) {}
SomeBase *CreateObject();
void ReleaseObject(SomeBase *);
~Cache() { delete [] p; }

private:
SomeBase *p;
};

It needs work, but at least with this you can be sure that your objects
are deleted when the Cache object is destroyed. You can even change the
implementation of Cache to allow for other methods of organizing the
SomeObjects if you find that one huge chunk of memory doesn't work so
well. Better still, you can change it to create the objects one at a
time in the usual way so that you have something nice and simple to use
during testing and debugging, and then possibly stick with if you find
that performance is good enough.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #6

P: n/a
On Tue, 19 Aug 2003 12:18:10 GMT, "Jeff Williams" <no*********************************@mfchelp.com > wrote:
Yes my example code was in error, let me post the correct version and clean
up my question a little:

new example code:

struct base_class { };
struct derive_class : base_class { };

void foo(std::vector<base_class*>& vec)
{
base_class* pBases = new derive_class[100];
for(int i = 0; i < 100; ++i)
vec.push_back(&pBases[i]);
}

void bar(std::vector<base_class*>& vec)
{
for(int i = 0; i < vec.size(); ++i)
delete vec[i];
vec.clear();
}

// I dont give a crap that the main func has bad prototype so dont even
bother
int main()


The prototype is OK.

Your attitude is not.

That includes both the language and neglecting to study earlier answers.

Jul 19 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.