static memory allocation versus dynamic memory allocation

K

Ken

In C programming, I want to know in what situations we should use
static memory allocation instead of dynamic memory allocation. My
understanding is that static memory allocation like using array is
faster than malloc, but dynamic memory allocation is more flexible.

Please comment... thanks.
 
T

Tom St Denis

Ken said:
In C programming, I want to know in what situations we should use
static memory allocation instead of dynamic memory allocation. My
understanding is that static memory allocation like using array is
faster than malloc, but dynamic memory allocation is more flexible.

Ho, Ho, Ho, Hold the homework!

Tom
 
R

Richard Heathfield

Ken said:
In C programming, I want to know in what situations we should use
static memory allocation instead of dynamic memory allocation. My
understanding is that static memory allocation like using array is
faster than malloc, but dynamic memory allocation is more flexible.

That's about right. Broadly, if you know in advance how much memory you
need, you don't need to use malloc (unless your implementation has a very
low limit on the amount of memory available for auto objects, but a less
restrictive limit on free store).

But malloc & co give you the flexibility to grow your data structures only
as large as they need to be, and (most importantly) the decision is
deferred until runtime (which is when you actually find out how much data
you've got!).
 
S

santosh

Ken said:
In C programming, I want to know in what situations we should use
static memory allocation instead of dynamic memory allocation. My
understanding is that static memory allocation like using array is
faster than malloc, but dynamic memory allocation is more flexible.

Use static allocation when you know in advance the amount of memory
needed, or if dynamic allocation is not available, (as may happen in
some embedded systems). Use of auto variables, (a form of static
allocation, though in reality it may not be), also helps in data
encapsulation and automatic memory management.

Dynamic memory is particularly relevant when you anticipate growth in
your data structures, where you may only know the maximum needed
memory, but actual usage may be far less than that, and when you need
for the data to persist throughout the process's lifetime but you
don't, (rightly), want to use global memory for the purpose.
 
M

Malcolm

Richard Heathfield said:
Ken said:


That's about right. Broadly, if you know in advance how much memory you
need, you don't need to use malloc (unless your implementation has a very
low limit on the amount of memory available for auto objects, but a less
restrictive limit on free store).

But malloc & co give you the flexibility to grow your data structures only
as large as they need to be, and (most importantly) the decision is
deferred until runtime (which is when you actually find out how much data
you've got!).
The other factor is that malloc() makes modules much more resuable.
Often you will know the size of the object at complie time, but not when you
write the code that handles arbitrary objects. For instance, a hash table
could hold any number of objects of any size, even though you know that you
need at most 1000 of type CAR.
 
R

rhle.freak

In C programming, I want to know in what situations we should use
static memory allocation instead of dynamic memory allocation. My
understanding is that static memory allocation like using array is
faster than malloc, but dynamic memory allocation is more flexible.

Please comment... thanks.

Static Memory Allocation is used when u know the memory requirement in
advance ;memory is assigned by the compiler at runtime . The space is
allocated once, when your program is started (part of the exec
operation), and is never freed.
Static allocation is what happens when you declare a static or global
variable. Each static or global variable defines one block of space, of
a fixed size.

Dynamic Memory Allocation is used when the memory you need, or how
long you continue to need it, depends on factors that are not known
before the program runs or if u working with a dynamic data structure
..Memory is allocated at runtime rather than during compilation n u can
free a block of memory once u no longer need it during the execution of
the program.

further Dynamic allocation is not supported by C variables; there is no
storage class "dynamic", and there can never be a C variable whose
value is stored in dynamically allocated space. The only way to get
dynamically allocated memory is via a system call and the only way to
refer to dynamically allocated space is through a pointer.
the actual process of dynamic allocation requires more computation time
n hence its slower than static memory allocation
 
C

CBFalconer

rhle.freak said:
.... snip ...

Dynamic Memory Allocation is used when the memory you need, or
how long you continue to need it, depends on factors that are not
known before the program runs or if u working with a dynamic data
structure .Memory is allocated at runtime rather than during
compilation n u can free a block of memory once u no longer need
it during the execution of the program.

You appear to be fairly capable of using English. Why spoil your
articles and make them hard to read by using such incomprehensibles
as u and n?
 
M

Malcolm

CBFalconer said:
You appear to be fairly capable of using English. Why spoil your
articles and make them hard to read by using such incomprehensibles
as u and n?
Or nonsense words like "int", "float" and "char" for
"integer", "real number", and "character"?
 
B

Ben Bacarisse

Malcolm said:
Or nonsense words like "int", "float" and "char" for
"integer", "real number", and "character"?

Why would you even consider removing such important distinctions in a
C new group? Did you forget the smiley?
 
S

santosh

Ben said:
Why would you even consider removing such important distinctions in a
C new group? Did you forget the smiley?

No distinction is removed. He's probably just pointing out that full
names like 'integer' would have been a better design choice than terse
abbreviations like int, float etc. Too late now and anyway, Pascal is
always available.
 
B

Ben Bacarisse

santosh said:
Ben said:
No distinction is removed. He's probably just pointing out that full
names like 'integer' would have been a better design choice than terse
abbreviations like int, float etc. Too late now and anyway, Pascal is
always available.

Oh, OK. Because the reply was to a comment about *posting* style
(using u and n) I though Malcolm was suggesting is was equally silly
to use words like int and char in posting in this group! Not to self:
sleep more, post less.
 
M

Malcolm

Ben Bacarisse said:
santosh said:
Oh, OK. Because the reply was to a comment about *posting* style
(using u and n) I though Malcolm was suggesting is was equally silly
to use words like int and char in posting in this group! Not to self:
sleep more, post less.
If you attack "u" for "you" on what basis do you defend "int" for
"integer?".
 
K

Keith Thompson

Ben Pfaff said:
Which one of them is defined in the C standard?

Both are. There are several integer types; "int" is one of them. See
C99 6.2.5.

Malcolm appears to be of the opinion that there should be one and
only one integer type. He is, as far as I can tell, in a minority of
one in this regard.
 
B

Ben Pfaff

Keith Thompson said:
Both are. There are several integer types; "int" is one of them. See
C99 6.2.5.

My point is that whereas "u" is *not* defined in the C standard,
"int" *is*, so it is a proper term for use in comp.lang.c.
 
K

Keith Thompson

Ben Pfaff said:
My point is that whereas "u" is *not* defined in the C standard,
"int" *is*, so it is a proper term for use in comp.lang.c.

Of course, I agree completely. I was merely quibbling about the way
you expressed the point. We do that here, you know. :cool:}
 
R

Richard Harter

Of course, I agree completely. I was merely quibbling about the way
you expressed the point. We do that here, you know. :cool:}

Oh well, as well as we are going to quibble, the "both" should refer to
"u" and "int", the issue being parallelism of usage. OTOH, this being
comp.lang.c the governing rule is that if it can be misread, then it
should be. :)
 
B

Ben Bacarisse

Malcolm said:
If you attack "u" for "you" on what basis do you defend "int" for
"integer?".

On the basis that it is the keyword for an important type in the
language discussed here. Can you discuss C without using the keywords
that designate the core types of the language?

I though I had misunderstood you comment but it seem I had not.

(BTW, I don't attack using "u" for "you". I find it does not impede
my understanding and it probably gives useful "out of band" data about
the poster.)
 
C

CBFalconer

Keith said:
.... snip ...

Of course, I agree completely. I was merely quibbling about the
way you expressed the point. We do that here, you know. :cool:}

Quibble? Here? I am shocked, shocked I tell you.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,756
Messages
2,569,540
Members
45,025
Latest member
KetoRushACVFitness

Latest Threads

Top