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

Dynamic memory allocation stack heaps

P: n/a
i have some doubts on dynamic memory allocation and stacks and heaps

where is the dynamic memory allocation used?

in function calls there are some counters like "i" in the below
function. Is this stored in stack. If yes whether it will be deleted
on exiting from the function.

is dynamic memory allocation needed for this purpose

int listnum()
{
unsigned char i;
for(i=0;i>10;i++)
}

Nov 15 '07 #1
Share this Question
Share on Google+
14 Replies


P: n/a
vivek wrote:

[Post-hoc I wonder if this is homework. Oh well.]
i have some doubts on dynamic memory allocation and stacks and heaps

where is the dynamic memory allocation used?
Where static or stack (in C, "auto[matic]") allocation isn't appropriate:
eg the size of store needed isn't known in advance, or the memory must be
available for longer than the lifetime of the function which allocated
it.

["Dynamic" allocation is ambiguous. Stack aka auto allocation is dynamic;
variables come into existence when their function is entered and are
no longer accessible when it exits. People often, but not invariably,
mean something like malloc/free or heap allocation when they say
"dynamic".]
in function calls there are some counters like "i" in the below
function. Is this stored in stack. If yes whether it will be deleted
on exiting from the function.

is dynamic memory allocation needed for this purpose

int listnum()
{
unsigned char i;
for(i=0;i>10;i++)
Oops, missing loop body. We'll pretend you wrote `{}` after the `)`.
}
The variable `i` is automatic and is local to the execution(s) of `listnum`.
A typical implementation will allocate it on a stack, but this isn't
required by the Standard, just convenient. So it's dynamic memory
allocation -- just not /very/ dynamic.

When the function exits, the variable becomes inaccessible. (That is,
what happens if you try to access it -- eg through a pointer you got
when the variable was accessible -- is Not Defined, which means that
you Do Not Know what will happen.) Whether that counts as the variable
being "deleted" depends on what you mean by "deleted". Typically the
store used for that version of the variable will be used for something
else.

--
Chris "static is bad for chips -- hence vinegar" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

Nov 15 '07 #2

P: n/a
On Nov 15, 4:27 pm, Chris Dollin <chris.dol...@hp.comwrote:
vivek wrote:

[Post-hoc I wonder if this is homework. Oh well.]
i have some doubts on dynamic memory allocation and stacks and heaps
where is the dynamic memory allocation used?

Where static or stack (in C, "auto[matic]") allocation isn't appropriate:
eg the size of store needed isn't known in advance, or the memory must be
available for longer than the lifetime of the function which allocated
it.

["Dynamic" allocation is ambiguous. Stack aka auto allocation is dynamic;
variables come into existence when their function is entered and are
no longer accessible when it exits. People often, but not invariably,
mean something like malloc/free or heap allocation when they say
"dynamic".]
in function calls there are some counters like "i" in the below
function. Is this stored in stack. If yes whether it will be deleted
on exiting from the function.
is dynamic memory allocation needed for this purpose
int listnum()
{
unsigned char i;
for(i=0;i>10;i++)

Oops, missing loop body. We'll pretend you wrote `{}` after the `)`.
}

The variable `i` is automatic and is local to the execution(s) of `listnum`.
A typical implementation will allocate it on a stack, but this isn't
required by the Standard, just convenient. So it's dynamic memory
allocation -- just not /very/ dynamic.

When the function exits, the variable becomes inaccessible. (That is,
what happens if you try to access it -- eg through a pointer you got
when the variable was accessible -- is Not Defined, which means that
you Do Not Know what will happen.) Whether that counts as the variable
being "deleted" depends on what you mean by "deleted". Typically the
store used for that version of the variable will be used for something
else.

--
Chris "static is bad for chips -- hence vinegar" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
Thanks. Typically which data are stored on the heap.
Nov 15 '07 #3

P: n/a
vivek wrote:
Thanks. Typically which data are stored on the heap.
Data that can't be allocated statically or automatically. I'm not sure
what "typically" would be here.

[It also depends on what you mean by "the heap", since the Standard doesn't
talk about a heap; you can say that in C, "the heap" is the memory managed
by malloc/realloc/free, which leads to the unilluminating answer "data
allocated by malloc or realloc" ...]

--
Chris "tautologies are tautologies" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

Nov 15 '07 #4

P: n/a
Chris Dollin wrote:
vivek wrote:
>Thanks. Typically which data are stored on the heap.

Data that can't be allocated statically or automatically. I'm not sure
what "typically" would be here.

[It also depends on what you mean by "the heap", since the Standard doesn't
talk about a heap; you can say that in C, "the heap" is the memory managed
by malloc/realloc/free, which leads to the unilluminating answer "data
allocated by malloc or realloc" ...]
On at least one system I work on, thread stacks are allocated from the
heap, so automatic data is also in heap space...
Nov 15 '07 #5

P: n/a
Mark Bluemel wrote:
Chris Dollin wrote:
>vivek wrote:
>>Thanks. Typically which data are stored on the heap.

Data that can't be allocated statically or automatically. I'm not sure
what "typically" would be here.

[It also depends on what you mean by "the heap", since the Standard doesn't
talk about a heap; you can say that in C, "the heap" is the memory managed
by malloc/realloc/free, which leads to the unilluminating answer "data
allocated by malloc or realloc" ...]
On at least one system I work on, thread stacks are allocated from the
heap, so automatic data is also in heap space...
(fx:weasel) Fortunately, Standard C doesn't have threads.

Unfortunately, at least one C implementation handles stack overflow by
grabbing another block of memory from whatever-underlies-malloc and
linking it in to a chain of stack chunks, so (at least some) automatic
memory is mallocated.

Conclusion: It All Depends On Why It Matters.

Vivek, what difference do the answers make to what you do?

--
Chris "test-driven newsgroups" Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

Nov 15 '07 #6

P: n/a
I found this http://www.cs.uleth.ca/~holzmann/C/s...morylayout.pdf
quite handy for general understanding.

My group is hiring multiple SW engineers and I've interviewed many
experienced SW engineers. Believe it or not, my impression have been
that 8 out 10 people don't know about this.
Nov 16 '07 #7

P: n/a
On Thu, 15 Nov 2007 03:14:49 -0800 (PST), vivek <gv********@gmail.com>
wrote in comp.lang.c:
i have some doubts on dynamic memory allocation and stacks and heaps
C doesn't define stacks or heaps, nor are C compilers required to use
them.
where is the dynamic memory allocation used?
When you call memory allocation functions malloc(), realloc(), or
calloc().
in function calls there are some counters like "i" in the below
function. Is this stored in stack. If yes whether it will be deleted
on exiting from the function.
There is no such thing as a "stack" at the C language level. If you
want to know how a particular compiler operates, ask in a group that
supports that compiler. If you want to know how compilers in general
might work, try reading news:comp.compilers.

With most of the implementations I use these days, the variable 'i'
will most likely be stored in a register and not in any kind of memory
at all.
is dynamic memory allocation needed for this purpose
Why do you think you need to know? Are you writing a compiler? If
'i' is stored in memory, it is stored where and how the writer(s) of
the particular compiler decided was the best way to do it, on the
processor for which the code is generated.
int listnum()
{
unsigned char i;
for(i=0;i>10;i++)
}
The C language does not specify or care where the memory comes from,
nor does a programmer writing a standard C program need to know.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Nov 16 '07 #8

P: n/a
On Nov 15, 5:13 pm, Chris Dollin <chris.dol...@hp.comwrote:
Mark Bluemel wrote:
Chris Dollin wrote:
vivek wrote:
>Thanks. Typically which data are stored on the heap.
Data that can't be allocated statically or automatically. I'm not sure
what "typically" would be here.
[It also depends on what you mean by "the heap", since the Standard doesn't
talk about a heap; you can say that in C, "the heap" is the memory managed
by malloc/realloc/free, which leads to the unilluminating answer "data
allocated by malloc or realloc" ...]
On at least one system I work on, thread stacks are allocated from the
heap, so automatic data is also in heap space...

(fx:weasel) Fortunately, Standard C doesn't have threads.

Unfortunately, at least one C implementation handles stack overflow by
grabbing another block of memory from whatever-underlies-malloc and
linking it in to a chain of stack chunks, so (at least some) automatic
memory is mallocated.

Conclusion: It All Depends On Why It Matters.

Vivek, what difference do the answers make to what you do?

--
Chris "test-driven newsgroups" Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England- Hide quoted text -

- Show quoted text -
Chris,
Iam an embedded software professional for 3 years and iam migrating
from assembly language to C.(predominantly communication protocol
related)

Since in microcontrollers/processors memory is considered valuable,
iam trying to learn the better way of writing C code.

In assembly language, i can re-use the registers multiple times since
every thing we do on assembly is directly visible to the programmer.

Here in my system, there will be different threads like ADC interrupt,
Keypad interrupt, communication data received, LCD etc...

so when i switch between each thread i wanted to know where the data
is being stored and whether the memory used by automatic variables
inside functions or threads is being reused.

thanks,
vivek
Nov 16 '07 #9

P: n/a
On Nov 16, 8:54 am, Jack Klein <jackkl...@spamcop.netwrote:
On Thu, 15 Nov 2007 03:14:49 -0800 (PST), vivek <gvivek2...@gmail.com>
wrote in comp.lang.c:
i have some doubts on dynamic memory allocation and stacks and heaps

C doesn't define stacks or heaps, nor are C compilers required to use
them.
where is the dynamic memory allocation used?

When you call memory allocation functions malloc(), realloc(), or
calloc().
in function calls there are some counters like "i" in the below
function. Is this stored in stack. If yes whether it will be deleted
on exiting from the function.

There is no such thing as a "stack" at the C language level. If you
want to know how a particular compiler operates, ask in a group that
supports that compiler. If you want to know how compilers in general
might work, try reading news:comp.compilers.

With most of the implementations I use these days, the variable 'i'
will most likely be stored in a register and not in any kind of memory
at all.
is dynamic memory allocation needed for this purpose

Why do you think you need to know? Are you writing a compiler? If
'i' is stored in memory, it is stored where and how the writer(s) of
the particular compiler decided was the best way to do it, on the
processor for which the code is generated.
int listnum()
{
unsigned char i;
for(i=0;i>10;i++)
}

The C language does not specify or care where the memory comes from,
nor does a programmer writing a standard C program need to know.

--
Jack Klein
Home:http://JK-Technology.Com
FAQs for
comp.lang.chttp://c-faq.com/
comp.lang.c++http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Jack,
Embedded software developers do need to know about where the data is
being stored for debugging and other purposes.
Nov 16 '07 #10

P: n/a
vivek wrote:
On Nov 16, 8:54 am, Jack Klein <jackkl...@spamcop.netwrote:
>On Thu, 15 Nov 2007 03:14:49 -0800 (PST), vivek <gvivek2...@gmail.com>
wrote in comp.lang.c:
>>i have some doubts on dynamic memory allocation and stacks and heaps
C doesn't define stacks or heaps, nor are C compilers required to use
them.
....
>The C language does not specify or care where the memory comes from,
nor does a programmer writing a standard C program need to know.
Embedded software developers do need to know about where the data is
being stored for debugging and other purposes.
Vivek - please don't quote people's signatures, and consider editing
your quotations.

If you need to know where the data is stored, you'll have to find out
about the particular architecture and C implementation you're working
with. There isn't a general answer.
Nov 16 '07 #11

P: n/a
Podi wrote, On 16/11/07 02:26:
I found this http://www.cs.uleth.ca/~holzmann/C/s...morylayout.pdf
quite handy for general understanding.
I can see that as being good for understanding one particular
implementation, but it is very implementation specific.
My group is hiring multiple SW engineers and I've interviewed many
experienced SW engineers. Believe it or not, my impression have been
that 8 out 10 people don't know about this.
The last time I needed to know a memory layout in that detail it was
because I was working on an embedded system and I had to tell the linker
how to arrange the sections in memory. I have never needed that level of
knowledge when programming for a PC or server.
--
Flash Gordon
Nov 16 '07 #12

P: n/a
Podi wrote:
....
I meant to say that most SW engineers I've spoken with don't
understand the general concept of stack/heap/data when a process is
created. I have reviewed many other people's programs. And the ones
don't understand the memory layout usually write less efficient/
optimal programs. Some examples are: auto array variables with large
size, use of malloc when not necessary, initialized data with large
size arrays, etc.
Because the details of memory layout are implementation-specific, so is
any judgment about whether or not any of those features of the code make
it more or less efficient. In my last job, I remember being very
concerned about overflowing the stack, because it was very easy to do. I
would never create anything of any significant size automatically;
everything big was either static or dynamic. Our code could only be
successfully compiled by making use of some complicated special compiler
options relevant to memory management.

The first piece of code I was given to work on in my current job (and
it's still the one I update most frequently), routinely created
multi-megabyte arrays automatically. It's a memory hog, but it works on
every platform it needs to work on. Our organization's coding standards
explicitly provide a waiver of the 65535 byte limit for object sizes
that is mentioned in 5.2.4.1p1. It would be a major re-design task to
re-write that program so it could operate within that limit, and such
changes would incur a significant performance hit when running on the
machines we normally use.

YMMV - which is precisely my point.
Nov 16 '07 #13

P: n/a
On Nov 16, 3:56 am, James Kuyper <jameskuy...@verizon.netwrote:
YMMV - which is precisely my point.
Digressing from pure C here...

For web application developers using C# or Java, I can accept that. I
used to work with a very senior developer who did not know about
endianess, not to mention stack/heap. What I didn't realize was that a
PC/Server programmer would not concern about such things, thus my
surprise. I forgot to mention that I was interviewing people for a
position that will involve with device driver programming in small
devices such as Window CE and embedded Linux.

Anyway, in my group's opinion, people understand the memory layout in
general usually produce higher quality programs.

Also, I don't understand why the multi-megabyte automatic variables
would be a memory hog instead of CPU hog. Your program needs the
amount of memory anyway for doing whatever it does. Wouldn't the large
arrays cause the OS to put it on the stack every time you enter the
function? Whereas if the arrays are allocated in the (uninitialized)
data section, you would have better performance? BTW, allocating large
arrays in the initialized data section would increase the file size of
the exectuable file (in most platforms: *nix and Windows).

So for example, we would like to work with developers who prefer to
pass pointer to a struct instead of the struct itself. Since every
function parameter is also copied on to the stack. The smaller the
stack each function requires, the better the performance of the over
all program.
Nov 17 '07 #14

P: n/a
Thanks for the replies.

I will take this issue up with the complier people.
Nov 17 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.