Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Dynamically allocated array question

Reply
Thread Tools

Dynamically allocated array question

 
 
Jeff Williams
Guest
Posts: n/a
 
      08-18-2003
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


 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      08-18-2003
On Mon, 18 Aug 2003 16:30:34 GMT, "Jeff Williams" <(E-Mail Removed) > 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.

 
Reply With Quote
 
 
 
 
Dimitris Kamenopoulos
Guest
Posts: n/a
 
      08-18-2003
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

 
Reply With Quote
 
Dimitris Kamenopoulos
Guest
Posts: n/a
 
      08-18-2003
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.
 
Reply With Quote
 
Andrey Tarasevich
Guest
Posts: n/a
 
      08-18-2003
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

 
Reply With Quote
 
Jeff Williams
Guest
Posts: n/a
 
      08-19-2003
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" <(E-Mail Removed)> 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.
>



 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      08-19-2003
On Tue, 19 Aug 2003 12:18:10 GMT, "Jeff Williams" <(E-Mail Removed) > 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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to free dynamically allocated array? Markus C Programming 7 08-31-2005 03:48 PM
is it safe to point to an element in a dynamically allocated array? songfire@gmail.com C++ 2 06-14-2005 07:51 PM
Problems initializing a dynamically allocated 2D array masood.iqbal@lycos.com C Programming 4 02-07-2005 06:55 AM
Problems initializing a dynamically allocated 2D array masood.iqbal@lycos.com C++ 6 02-07-2005 06:55 AM
Dynamically Allocated Memory vs. Statically allocated Memory csnerd@gmail.com C++ 5 12-09-2004 01:44 AM



Advertisments