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

Some advice about references on memory management in C

P: n/a
I can comprehend the basics of that subject (pointers, memory
allocation, heap, stack etc), but I am interested to have
references with more details. I have some C/C++ books
and lots of URLs "bookmarked", but all of them don't go too
far on memory management as I would like. One of my main issues
is whether function "main" and its local variables are allocated
on the stack area as other functions.

Does anybody recommend a good book or site with a good text
on memory management in C/C++?

In comp.lang.c++ someone recommended "C++ Pointers and Dynamic
Memory Management", by Michael C. Daconta. Is it good?

Does anybody know the book "Memory as a programming
concept in C and C++" (Cambridge Press - link below)?
(http://titles.cambridge.org/catalogu...sbn=0521520436)
There are some resources here
"http://www.cas.mcmaster.ca/~franek/books.html".
However, I'd like to have some advice about the whole book.

Regards and TIA,
Rafael Charnovscki
Nov 14 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a

"Rafael Charnovscki" <rc*@unesc.net> wrote in message
news:cd*************************@posting.google.co m...
I can comprehend the basics of that subject (pointers, memory
allocation, heap, stack etc), but I am interested to have
references with more details. I have some C/C++ books
and lots of URLs "bookmarked", but all of them don't go too
far on memory management as I would like. One of my main issues
is whether function "main" and its local variables are allocated
on the stack area as other functions.


It's really not that hard.

As a rule of thumb:

All local variables are located on stack, as are parameters to functions,
global variables are located in the .data (or equivalent)segment and
everything you alloc() on the heap.

The .data segment (that's what they call it in UNIX, forgive me) is loaded
with the rest of your program (memory is allocated by your OS) so you can
'initialize' that data by just assigning a value to it.

int global_a = 42;

void foobar(int parameter_b)
{
void* local_c;

local_c = malloc(0x0100)

...
}

then global_a would be in your .data segment, parameter_b and local_c would
be on stack and *local_c would be in the heap.

I cannot give any advice on books, but I could reccomend a decent debugger
and a simple sample program so you can check for yourself.

Regards,

dandelion
Nov 14 '05 #2

P: n/a
Hi there,
dandelion wrote:
"Rafael Charnovscki" <rc*@unesc.net> wrote in message
news:cd*************************@posting.google.co m...
I can comprehend the basics of that subject (pointers, memory
allocation, heap, stack etc), but I am interested to have
references with more details. I have some C/C++ books
and lots of URLs "bookmarked", but all of them don't go too
far on memory management as I would like. One of my main issues
is whether function "main" and its local variables are allocated
on the stack area as other functions.

It's really not that hard.

As a rule of thumb:

All local variables are located on stack, as are parameters to functions,
global variables are located in the .data (or equivalent)segment and
everything you alloc() on the heap.

The .data segment (that's what they call it in UNIX, forgive me) is loaded
with the rest of your program (memory is allocated by your OS) so you can
'initialize' that data by just assigning a value to it.

int global_a = 42;

void foobar(int parameter_b)
{
void* local_c;

local_c = malloc(0x0100)

...
}

then global_a would be in your .data segment, parameter_b and local_c would
be on stack and *local_c would be in the heap.

I cannot give any advice on books, but I could reccomend a decent debugger
and a simple sample program so you can check for yourself.


Note, however, that the C standard does not say anything about heap or
stack, let alone .data. That is, one cannot rely on things being like
described, even though the description gives you a good idea of
how things are done on a specific platform.

Another book which can give you a good idea of how addresses are mapped
and so on, is "Linkers and Loaders". I do not have the link right
now, but there is an alpha version of the book out there for free
(legally).

Once again: This information does not hold for all standard compliant
C environments. If you have a certain system and a certain compiler
in mind, you may want to ask in the respective newsgroups.
Cheers,
Michael

Nov 14 '05 #3

P: n/a
rc*@unesc.net (Rafael Charnovscki) wrote in message news:<cd*************************@posting.google.c om>...
I can comprehend the basics of that subject (pointers, memory
allocation, heap, stack etc), but I am interested to have
references with more details. I have some C/C++ books
and lots of URLs "bookmarked", but all of them don't go too
far on memory management as I would like. One of my main issues
is whether function "main" and its local variables are allocated
on the stack area as other functions.

The problem is that not all machines are stack-based. A good number
of them are, but the C language doesn't require it.

AFAIK, main() is treated like any other function as far as how it's
data is managed, but the details may vary based on the platform. You
might be better off asking this kind of question in a newsgroup
devoted to your particular architecture.
Does anybody recommend a good book or site with a good text
on memory management in C/C++?

In comp.lang.c++ someone recommended "C++ Pointers and Dynamic
Memory Management", by Michael C. Daconta. Is it good?

Does anybody know the book "Memory as a programming
concept in C and C++" (Cambridge Press - link below)?
(http://titles.cambridge.org/catalogu...sbn=0521520436)
There are some resources here
"http://www.cas.mcmaster.ca/~franek/books.html".
However, I'd like to have some advice about the whole book.

Regards and TIA,
Rafael Charnovscki

Nov 14 '05 #4

P: n/a
On Thu, 7 Oct 2004 16:56:20 +0200, "dandelion" <so*****@meadow.net>
wrote in comp.lang.c:

"Rafael Charnovscki" <rc*@unesc.net> wrote in message
news:cd*************************@posting.google.co m...
I can comprehend the basics of that subject (pointers, memory
allocation, heap, stack etc), but I am interested to have
references with more details. I have some C/C++ books
and lots of URLs "bookmarked", but all of them don't go too
far on memory management as I would like. One of my main issues
is whether function "main" and its local variables are allocated
on the stack area as other functions.
It's really not that hard.

As a rule of thumb:

All local variables are located on stack, as are parameters to functions,


....unless of course you are using an efficient compiler for a modern
processor architecture, and then at least some of the parameters and
local variables are entirely in registers. Possibly all of them,
depending on how many there are.
global variables are located in the .data (or equivalent)segment and
everything you alloc() on the heap.
....unless of course they are default initialized, in which case they
are more likely to be in another section.
The .data segment (that's what they call it in UNIX, forgive me) is loaded
with the rest of your program (memory is allocated by your OS) so you can
'initialize' that data by just assigning a value to it.


You seem to have forgotten about file scope and block scope values
with static storage duration. Not to mention string literals and
constant objects.

The true answer is that there is no rule of the thumb. If it made
sense for there to be a rule of the thumb, it would be in the C
standard, which it most certainly is not.

The only answer to a question like this, from a language stand point,
is to direct the OP to a group that specialized in the particular
OS/compiler combination that interests him. It may be quite a bit
different from others, and from the model you are familiar with.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #5

P: n/a
In article <cd*************************@posting.google.com> ,
Rafael Charnovscki <rc*@unesc.net> wrote:
One of my main issues
is whether function "main" and its local variables are allocated
on the stack area as other functions.


In typical implementations on general-purpose computers, the function
main() is called in the usual way from some other function, which also
handles calling exit() if main() returns.

-- Richard
Nov 14 '05 #6

P: n/a

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:op********************************@4ax.com...
On Thu, 7 Oct 2004 16:56:20 +0200, "dandelion" <so*****@meadow.net>
wrote in comp.lang.c:

"Rafael Charnovscki" <rc*@unesc.net> wrote in message
news:cd*************************@posting.google.co m...
I can comprehend the basics of that subject (pointers, memory
allocation, heap, stack etc), but I am interested to have
references with more details. I have some C/C++ books
and lots of URLs "bookmarked", but all of them don't go too
far on memory management as I would like. One of my main issues
is whether function "main" and its local variables are allocated
on the stack area as other functions.
It's really not that hard.

As a rule of thumb:

All local variables are located on stack, as are parameters to functions,
...unless of course you are using an efficient compiler for a modern
processor architecture, and then at least some of the parameters and
local variables are entirely in registers. Possibly all of them,
depending on how many there are.
global variables are located in the .data (or equivalent)segment and
everything you alloc() on the heap.
...unless of course they are default initialized, in which case they
are more likely to be in another section.


Hence "(or equivalent)".
The .data segment (that's what they call it in UNIX, forgive me) is loaded with the rest of your program (memory is allocated by your OS) so you can 'initialize' that data by just assigning a value to it.


You seem to have forgotten about file scope and block scope values
with static storage duration. Not to mention string literals and
constant objects.


Ummm...

Scoping (in this case and to my knowledge) is dermined by the kind of record
generated by the compiler and is ultimately delt with by the linker.

You seem to have forgotten the little "As a rule of thumb" I put in front of
my remarks.
The true answer is that there is no rule of the thumb.
Not one that is generally valid or refelcts exactly what the standard says,
but rules of thumb (i.e. inaxact, but workable) do exist. The above works
well wen explaining stuff to (relative) newbies.
If it made
sense for there to be a rule of the thumb, it would be in the C
standard, which it most certainly is not.
Standards and "rules of thumb" are two extremey different things, one seeks
to define exactly and exhaustively, the other seeks to give general rules,
which are easy to work with, eventhough they are not always and exactly
true.

I would be very disappointed if standards contained "rules of thumb".
Standards are intended for those who write compilers, rules of thumb for
newbies and regular users who want a rough idea without worrying about the
exact details.
The only answer to a question like this, from a language stand point,
is to direct the OP to a group that specialized in the particular
OS/compiler combination that interests him.
Perhaps. In that case you can just sit back, delegate all practical
questions to some other n.g. and lock yourself in an ivory tower of language
abstractions and formulations in The Standard, I presume.

I can see how that would be attractive. I, personally, prefer to give
answers (to specific questions) people can work with, eventhough the details
may be less than exact.
It may be quite a bit different from others, and from the model you are

familiar with.

That's quite a lot of models, platforms and languages and dialects, from
assemby to Prolog, from Sun Supersparc and PowerPC to (refurbished) 68000,
Z80, AVR, PIC and 68HC11.

Regards,

dandelion.
Nov 14 '05 #7

P: n/a

"John Bode" <jo*******@my-deja.com> wrote in message
news:43**************************@posting.google.c om...

<snip>
The problem is that not all machines are stack-based. A good number
of them are, but the C language doesn't require it.


Noted. However, I am still pondering the architecture in use today which
does not. I know about IBM 360, but those are ancient (in computer terms).
Nov 14 '05 #8

P: n/a
On Mon, 11 Oct 2004 12:25:49 +0200
"dandelion" <so*****@meadow.net> wrote:
"John Bode" <jo*******@my-deja.com> wrote in message
news:43**************************@posting.google.c om...

<snip>
The problem is that not all machines are stack-based. A good number
of them are, but the C language doesn't require it.


Noted. However, I am still pondering the architecture in use today
which does not. I know about IBM 360, but those are ancient (in
computer terms).


Ancient in computer terms does *not* mean that it is no longer in use. I
don't know about the IBM 360 or other machines that are not stack based,
but I do know (from personal involvement) of systems based on the Z80
processor programmed in assembler being updated and sold to new a new
large customer in the late 90s and of another customer who signed for an
option of 20 years of support on another variation. So if we will have
Z80 based systems with an expected end of life after 2015 it is possible
you could find any system since the C89 standard still in use and
undergoing active maintenance. So it is important when learning that one
learns which assumptions cannot be made.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
Nov 14 '05 #9

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dandelion wrote:
"John Bode" <jo*******@my-deja.com> wrote in message
news:43**************************@posting.google.c om...

<snip>
The problem is that not all machines are stack-based. A good number
of them are, but the C language doesn't require it.

Noted. However, I am still pondering the architecture in use today which
does not. I know about IBM 360, but those are ancient (in computer terms).


System 360 /is/ ancient, but S/390 is only /old/, and zSeries is practically a
baby. *But*, you can compile and run a C program on each of these IBM
S/360-compatable processors without problems. No stack necessary.

And, the architecture may be ancient, but we still use it for a large (> 50%)
of big business computing. Your bank, your hospital, and your local government
all use these machine.
- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBauyWagVFX4UWr64RAvVgAKDUIN39+EG/9eqaHtA0gbYN0FuAOwCggoBu
m+uQKwxBic+CvwuYPhkGV58=
=MmS+
-----END PGP SIGNATURE-----
Nov 14 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.