Hi,

It's probably a stupid question, but here goes. I know that for every 
"new", there must be a delete. I don't deal with malloc statements, so 
let's disregard that branch of memory management.

So here's the question. If I create an array like so: int i[20];, and 
then proceed to assign values for each entry, must I then delete it at 
some point? I didn't use a "new" flag to initialize the array. Is the 
memory used by that array freed after the program is terminated?

I can't find information regarding this, as all the texts I found dealt 
with the "new" and "delete []" statements.

I ask this because my Light's Out game seem to use more and more memory 
each time it is run and closed, but the memory consumption actually goes 
back down to what it originally was after the 11th or 12th time. I don't 
get why that would happen...

Sam

Post a reply to this message

Samuel Benge a écrit :
> Hi,
> 
> It's probably a stupid question, but here goes. I know that for every 
> "new", there must be a delete. I don't deal with malloc statements, so 
> let's disregard that branch of memory management.
> 
> So here's the question. If I create an array like so: int i[20];, and 
> then proceed to assign values for each entry, must I then delete it at 
> some point? I didn't use a new flag. Is the memory used by that array 
> freed after the program is terminated?
> 

What you make whith the instruction int i[20]; is a static array, that 
is allocated in the stack if I remember correctly. You do not have to 
manage the memory in the stack, so no free or delete.

Try googling for "static dynamic array C++", it should bring you 
something useful...

Hope this helps

-- 
Vincent

Post a reply to this message

On Wed, 03 Oct 2007 00:36:05 +0200, Samuel Benge  
<stb### [at] THIShotmailcom> wrote:
> If I create an array like so: int i[20];, and then proceed to assign  
> values for each entry, must I then delete it at some point?

No. Indeed, you must not, as it is not dynamically allocated.


> Is the memory used by that array freed after the program is terminated?

It is freed when 'i' goes out of scope. If 'i' is in namespace scope, it  
goes out of scope when the program ends.



-- 
FE

Post a reply to this message

Vincent Le Chevalier wrote:
> What you make whith the instruction int i[20]; is a static array, that 
> is allocated in the stack if I remember correctly. You do not have to 
> manage the memory in the stack, so no free or delete.

Hmm, that's good to know.

> Try googling for "static dynamic array C++", it should bring you 
> something useful...
> 
> Hope this helps

Yes, it does. Thanks! I'm off to use Google for the umpteenth time today!

Sam

Post a reply to this message

Fredrik Eriksson wrote:
> 
> No. Indeed, you must not, as it is not dynamically allocated.
> 
>> Is the memory used by that array freed after the program is terminated?
> 
> It is freed when 'i' goes out of scope. If 'i' is in namespace scope, it 
> goes out of scope when the program ends.

Thank you. My program should not have any memory leaks, then. I assume 
this also applies to other variables as well?

Sam

Post a reply to this message

Samuel Benge <stb### [at] thishotmailcom> wrote:
> It's probably a stupid question, but here goes. I know that for every 
> "new", there must be a delete.

> So here's the question. If I create an array like so: int i[20];, and 
> then proceed to assign values for each entry, must I then delete it at 
> some point?

  Odd question, given that you answered it even before you asked it.

  If you deleted it, you would have more deletes than news, which would
break the "for each new, delete" rule.

> I didn't use a "new" flag to initialize the array. Is the 
> memory used by that array freed after the program is terminated?

  No. It's freed when it goes out of scope.

-- 
                                                          - Warp

Post a reply to this message

Samuel Benge a écrit :
> Fredrik Eriksson wrote:
>>
>> No. Indeed, you must not, as it is not dynamically allocated.
>>
>>> Is the memory used by that array freed after the program is terminated?
>>
>> It is freed when 'i' goes out of scope. If 'i' is in namespace scope, 
>> it goes out of scope when the program ends.
> 
> Thank you. My program should not have any memory leaks, then. I assume 
> this also applies to other variables as well?
> 

Everything that wasn't new-ed.

Normally the OS frees the memory used when the program ends anyway... So 
I don't understand exactly what you observe in your game. You mean it 
takes more memory when it runs for the 6th time than it took the first time?

-- 
Vincent

Post a reply to this message

On Wed, 03 Oct 2007 00:50:20 +0200, Samuel Benge  
<stb### [at] THIShotmailcom> wrote:
> Fredrik Eriksson wrote:
>>  No. Indeed, you must not, as it is not dynamically allocated.
>>
>>> Is the memory used by that array freed after the program is terminated?
>>  It is freed when 'i' goes out of scope. If 'i' is in namespace scope,  
>> it goes out of scope when the program ends.
>
> Thank you. My program should not have any memory leaks, then. I assume  
> this also applies to other variables as well?


Only objects that are dynamically allocated - i.e. with 'new' - need to be  
explicitly deallocated. You may not need to use 'delete' at all if you use  
standard library containers and/or smart pointers.



-- 
FE

Post a reply to this message

Vincent Le Chevalier wrote:
> Everything that wasn't new-ed.
> 
> Normally the OS frees the memory used when the program ends anyway... So 
> I don't understand exactly what you observe in your game. You mean it 
> takes more memory when it runs for the 6th time than it took the first 
> time?

I mean when I monitor my system's memory usage, more memory is being 
used AFTER I close my program. But after several runs, the memory is 
returned to an earlier state.

Sam

Post a reply to this message

Fredrik Eriksson wrote:
> Only objects that are dynamically allocated - i.e. with 'new' - need to 
> be explicitly deallocated. You may not need to use 'delete' at all if 
> you use standard library containers and/or smart pointers.

Okay, it's good to hear it from several people.

I use a DirectX game engine which requires a few "news", but I always 
delete them when I am through with 'em.

Sam

Post a reply to this message

Warp wrote:
>   Odd question, given that you answered it even before you asked it.

I knew I'd get this response from someone. I was just worried about the 
non-new declaration of arrays and variables, but I am clear on those now.

>   If you deleted it, you would have more deletes than news, which would
> break the "for each new, delete" rule.

Indeed. This happened with my maze game, and I got a warning about it.

>> I didn't use a "new" flag to initialize the [static] array. Is the 
>> memory used by that array freed after the program is terminated?
> 
>   No. It's freed when it goes out of scope.

Cool. Thanks!

Sam

Post a reply to this message

Samuel Benge a écrit :
> I mean when I monitor my system's memory usage, more memory is being 
> used AFTER I close my program. But after several runs, the memory is 
> returned to an earlier state.
> 

I don't think the problem is in your program, then. When it does not run 
anymore, it does not use memory anymore, at least on modern OSes... 
Perhaps you could try to find a way to monitor the memory per process, 
rather than the whole.

-- 
Vincent

Post a reply to this message

Vincent Le Chevalier wrote:
> Samuel Benge a écrit :
>> I mean when I monitor my system's memory usage, more memory is being 
>> used AFTER I close my program. But after several runs, the memory is 
>> returned to an earlier state.
> 
> I don't think the problem is in your program, then. When it does not run 
> anymore, it does not use memory anymore, at least on modern OSes... 
> Perhaps you could try to find a way to monitor the memory per process, 
> rather than the whole. 

No, I mean the program uses more memory when I run it, and the memory 
consumption is slightly higher after I quit than it was before I opened 
the program. It does this with other apps, too (Firefox). I don't think 
it's a problem with my program, if other programs are doing it too. 
Unless, of course, Firefox is buggy (which it might be).

Sam

Post a reply to this message

Samuel Benge escribió:
> Vincent Le Chevalier wrote:
>> Everything that wasn't new-ed.
>>
>> Normally the OS frees the memory used when the program ends anyway... 
>> So I don't understand exactly what you observe in your game. You mean 
>> it takes more memory when it runs for the 6th time than it took the 
>> first time?
> 
> I mean when I monitor my system's memory usage, more memory is being 
> used AFTER I close my program. But after several runs, the memory is 
> returned to an earlier state.
> 
> Sam
> 
Two words: disk cache.

Post a reply to this message

Memory can be free, but not available, it can
be fragmented, some other process might
have put a small amount of data in a big block,
the block is mostly empty, but is GC later by
the system after it runs out of fresh memory,
so after many levels the system packs the
memory in tighter, and the next GC takes
longer to be required because the data is
now assigned to the same blocks instead of
scattered blocks.

Post a reply to this message

"Samuel Benge" <stb### [at] THIShotmailcom> wrote in message
news:4702e940$1@news.povray.org...
> Vincent Le Chevalier wrote:
> > Samuel Benge a écrit :
> >> I mean when I monitor my system's memory usage, more memory is being
> >> used AFTER I close my program. But after several runs, the memory is
> >> returned to an earlier state.
> >
> > I don't think the problem is in your program, then. When it does not run
> > anymore, it does not use memory anymore, at least on modern OSes...
> > Perhaps you could try to find a way to monitor the memory per process,
> > rather than the whole.
>
> No, I mean the program uses more memory when I run it, and the memory
> consumption is slightly higher after I quit than it was before I opened
> the program. It does this with other apps, too (Firefox). I don't think
> it's a problem with my program, if other programs are doing it too.
> Unless, of course, Firefox is buggy (which it might be).
>
> Sam

Your OS could be keeping the most recently used libraries in memory in case
they are going to be called again.

Post a reply to this message

Samuel Benge wrote:
> No, I mean the program uses more memory when I run it, and the memory 
> consumption is slightly higher after I quit than it was before I opened 
> the program.

I think the basic problem here is what you mean by "memory consumption". 
Memory doesn't get consumed, and all of it is always there. It's just a 
question of who happens to be using it at the moment. Once your program 
exits, your program isn't using the memory any more. There might be 
something in a cache, or the kernel may have a bug in it that's not 
marking the memory as available after your program stops using it.

But the question of "how do you know the memory is 'consumed'?" would 
likely provide clues towards answering the question of who is using it.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> But the question of "how do you know the memory is 'consumed'?" would 
> likely provide clues towards answering the question of who is using it.

  That's indeed quite relevant.

  The amount of available "free memory" is quite an irrelevant number in
any modern OS (and most of the older ones too). Even Windows. That number
doesn't really say anything. IMO it could and should be removed from the
basic user interface because it only causes confusion and serves no useful
purpose. Even some very experienced users get confused by that number.
Usually many people get worried if the amount of free memory is very low,
even though there's often absolutely nothing to it.

  Sure, the number is telling the amount of memory currently not used by
anything. However, knowing the amount of memory not used currently by
anything is basically useless information because it tells you nothing
about the state of the system. It does *not* tell how much memory will
be available for a program you will be next starting. It does *not* tell
you that the system is running out of memory and that something is wrong
because of that.

  Most OSes will use available free memory for internal things. This is
usually pretty "light" form of usage of memory in that immediately when
a new process requests more memory than is currently unused, that memory
used by the OS for its own things will be immediately freed for the process
to use.
  It may very well happen that the OS reports that there's only 1MB of free
memory in a 1GB system, yet when you start a program requiring half of a
gigabyte of memory, it runs smoothly without even the slightest bit of
swapping or anything. The OS simply stopped using part of that memory and
freed it for the process to use.

  That's why the "memory free" number doesn't really say anything.

-- 
                                                          - Warp

Post a reply to this message

Tim Attwood wrote:
> Memory can be free, but not available, it can
> be fragmented, some other process might
> have put a small amount of data in a big block,
> the block is mostly empty, but is GC later by
> the system after it runs out of fresh memory,
> so after many levels the system packs the
> memory in tighter, and the next GC takes
> longer to be required because the data is
> now assigned to the same blocks instead of
> scattered blocks.
> 

Now that makes sense!

Post a reply to this message

Ross wrote:
> Your OS could be keeping the most recently used libraries in memory in case
> they are going to be called again.

This also makes sense.

Post a reply to this message

Warp escribió:
> Darren New <dne### [at] sanrrcom> wrote:
>> But the question of "how do you know the memory is 'consumed'?" would 
>> likely provide clues towards answering the question of who is using it.
> 
>   That's indeed quite relevant.
> 
>   The amount of available "free memory" is quite an irrelevant number in
> any modern OS (and most of the older ones too). Even Windows. That number
> doesn't really say anything. IMO it could and should be removed from the
> basic user interface because it only causes confusion and serves no useful
> purpose. Even some very experienced users get confused by that number.
> Usually many people get worried if the amount of free memory is very low,
> even though there's often absolutely nothing to it.
> 
>   Sure, the number is telling the amount of memory currently not used by
> anything. However, knowing the amount of memory not used currently by
> anything is basically useless information because it tells you nothing
> about the state of the system. It does *not* tell how much memory will
> be available for a program you will be next starting. It does *not* tell
> you that the system is running out of memory and that something is wrong
> because of that.
> 
>   Most OSes will use available free memory for internal things. This is
> usually pretty "light" form of usage of memory in that immediately when
> a new process requests more memory than is currently unused, that memory
> used by the OS for its own things will be immediately freed for the process
> to use.
>   It may very well happen that the OS reports that there's only 1MB of free
> memory in a 1GB system, yet when you start a program requiring half of a
> gigabyte of memory, it runs smoothly without even the slightest bit of
> swapping or anything. The OS simply stopped using part of that memory and
> freed it for the process to use.
> 
>   That's why the "memory free" number doesn't really say anything.
> 

Free RAM is *wasted RAM*. That's why Vista has such an "aggressive" disk 
cache, pre-fetching files even before you open them.

Post a reply to this message

Warp wrote:
>   That's why the "memory free" number doesn't really say anything.

Interestingly...

The Amiga OS, when unable to satisfy a request to allocate RAM(*), would 
loop through all the loaded libraries and invoke in each the standard 
entry point intended to unload the library from RAM, then try again. If 
someone still had the library open, the library would refuse to free() 
its memory of course. If the library was closed, it was supposed to call 
free() on any memory it had allocated, and then free itself (via some 
mechanism I don't recall 20 years later offhand).

There was one library that would cache stuff for you (disk pages, if I 
recall), and when the "unload" entry was called, would free the memory 
in the cache without actually exiting.  Another one let you register 
with that library, and when *it* got the unload call, it would pass it 
on to everyone who had registered, so you could (say) trim the undo 
stack down some rather than crash some other program.

Overall, a pretty cool functionality for such a simple mechanism. It's 
amazing how flexible AmigaOS was, simply by having a handful of 
primitives that it *didn't* try to combine for you into what the 
designers thought you'd want to do.


(*) In the good old days, back before desktop CPUs handled page faults...

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message