Thread: [Dev-C++] RES: RES: RES: Question about software design

Sorry, but I didn´t understand the stack realease sfuff...

-->Suppose I make a lot of malloc´s during the execution of
my program. Then I finish the execution (without "freeing" the
memory).
-->Does all the "malloced" memory return to the Operating
System and can be considered available again?

Thank you!
Andre
  -----Mensagem original-----
  De: Rafael Menezes [mailto:so...@gm...]
  Enviada em: quarta-feira, 21 de novembro de 2007 10:02
  Para: André Macário Barros
  Assunto: Re: [Dev-C++] RES: RES: Question about software design


  Hi André.

  I'm not asking about some particular language skill's, and if you are
using ANSI C, that is great. Not much people see that ANSI C is faster than
anything else (with one exception to assembly, but assembly... oh joy...),
and can be used in many places of the code in order to increase speed and
memory usage. Keep using that everywhere it fits. About that automatic
memory release, well... the memory will be cleaned up in most cases, but you
cant count on that. Sometimes (each time you ask for a new memory space that
is bigger than the actual remaining stack on the SO, reserved to your
application), you can just see your memory leaking and don't have a thread
to kill and stop this beast. The normal memory management functions supplied
with C compilers do not provide garbage collection. free and calloc still
can be useful in your code.

  Regards
  Rafael
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.16.2/1142 - Release Date: 20/11/2007
17:44

Andr=E9 Mac=E1rio Barros sez,

> Sorry, but I didn=B4t understand the stack realease sfuff...

Local variables are generally allocated on the functions stack
frame.  Once you return from a function the local variables are no
longer valid.  A pointer to a local variable is no longer valid
once you've returned from the function.  Thus you need to take a
lot of care when referencing local variables via pointers.
=20
> -->Suppose I make a lot of malloc=B4s during the
> execution of my program. Then I finish the execution (without
> "freeing" the memory).

> -->Does all the "malloced" memory return to
> the Operating System and can be considered available again?

With Winders, probably.  Other OS's probably not.  The real issue is
that not keeping track of memory that has been allocated via malloc
is bad programming practice as it leads directly to memory leaks.

Mr Foo

Be careful with programming small processors like the PIC, they do not have
enough stack depth to support deeply nested calls or large argument lists. =
I
wouldn't recommend using C++, stick to C.

And generally, there is no "operating system".

Best regards,

Fernando

On Nov 21, 2007 3:47 PM, Pink Boy <da...@ya...> wrote:

> Andr=E9 Mac=E1rio Barros sez,
>
> > Sorry, but I didn=B4t understand the stack realease sfuff...
>
> Local variables are generally allocated on the functions stack
> frame.  Once you return from a function the local variables are no
> longer valid.  A pointer to a local variable is no longer valid
> once you've returned from the function.  Thus you need to take a
> lot of care when referencing local variables via pointers.
>
> > -->Suppose I make a lot of malloc=B4s during the
> > execution of my program. Then I finish the execution (without
> > "freeing" the memory).
>
> > -->Does all the "malloced" memory return to
> > the Operating System and can be considered available again?
>
> With Winders, probably.  Other OS's probably not.  The real issue is
> that not keeping track of memory that has been allocated via malloc
> is bad programming practice as it leads directly to memory leaks.
>
> Mr Foo
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>



--=20
Fernando Lichtschein
li...@fi...