Large arrays: malloc or 'just declare'?

[Hal Styli]

Hello,

Can someone please help.

I need to use a large array and I'm not sure when one should
use (A) and when one should use (B) below:-

#define MAX 10000000

(A) int x[MAX];

(B) int *x = ( int * ) malloc( MAX*sizeof( int ) );

This isn't a compiler specific problem, but just for some background, I was
using (A) for lower values of MAX but when I started increasing it, I hit
some compiler/linker problems with the borland compiler.

I then noticed that the size of the executable was similar regardless of
whether
I used (A) or (B) which might have been a mild advantage of (B).

Other than compiler/linker problems, assuming MAX is fixed (as it is!)
why would I use (B) rather than (A)?

I think the answer relates to stack versus heap (but I'm interested in any
other answers that come up). Can anyone point me to an online reference on
stack vs heap, my google searches haven't inspired me.

Thanks in advance
Hal.

[Rakesh]

i) First of all, if you want to go for very large arrays,( as you had
rightly put it b4 ) , go for the heap and avoid taking up stack space
for it.

ii) Second, the life time of the variable. Most of the time, you would
want to move around the data pointed by the very large array and operate
on them. In that case, again it makes sense to have it on the heap and
pass around the address of the same.
Yeah . you can even define a local variable on the stack and move
around the address, but needless to say that is lost once the function
returns, whereas if it taken from heap, it is still there ( But then
there is always a lurking danger of a memory leak by separating the
malloc / free in diff. functions . )
My vote goes for heap !!

Hal Styli wrote:

Hello,

Can someone please help.

I need to use a large array and I'm not sure when one should
use (A) and when one should use (B) below:-

#define MAX 10000000

(A) int x[MAX];

(B) int *x = ( int * ) malloc( MAX*sizeof( int ) );

Thanks in advance
Hal.

--

--
Rakesh Kumar
** Remove nospamplz from my email address for my real email **

[Christopher Benson-Manica]

Hal Styli <no_spam@all> spoke thus:

#define MAX 10000000 (A) int x[MAX]; (B) int *x = ( int * ) malloc( MAX*sizeof( int ) ); ^^^^^^^^^
Don't cast the return value of malloc, ever. If you've forgotten to
include <stdlib.h>, you won't know it if you cast malloc's return
value. Highly detailed discussions on this topic can be found in this
group's archives.
This isn't a compiler specific problem, but just for some background, I was
using (A) for lower values of MAX but when I started increasing it, I hit
some compiler/linker problems with the borland compiler.
If it isn't compiler specific, why mention Borland's compiler? The
amount of automatic storage you can allocate is a function of your
implementation and how you use it.
I then noticed that the size of the executable was similar regardless of
whether
I used (A) or (B) which might have been a mild advantage of (B).
Mostly irrelevent, unless you have the (mis)fortune of developing on a
highly space-sensitive platform, such as an embedded device.
Other than compiler/linker problems, assuming MAX is fixed (as it is!)
why would I use (B) rather than (A)?
Use A when:

1) You know how much space you want at compile time,
2) You won't want more space at any future time, and
3) You don't run into problems such as the one you're having.

Otherwise, use B. (Right, clc?) Remember that you must free() memory
you allocate with malloc().
I think the answer relates to stack versus heap (but I'm interested in any
other answers that come up). Can anyone point me to an online reference on
stack vs heap, my google searches haven't inspired me.

On this newsgroup, "stack" and "heap" are dangerous terms, as
implementations need not use such structures to manage the memory they
allocate. As for references, the following contain a wealth of
valuable C information:

http://www.ungerhu.com/jxh/clc.welcome.txt
http://www.eskimo.com/~scs/C-faq/top.html
http://benpfaff.org/writings/clc/off-topic.html

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[August Derleth]

On Tue, 20 Apr 2004 01:45:53 +0000, Christopher Benson-Manica wrote:

Hal Styli <no_spam@all> spoke thus:

#define MAX 10000000

(A) int x[MAX];

(B) int *x = ( int * ) malloc( MAX*sizeof( int ) );

^^^^^^^^^
Don't cast the return value of malloc, ever. If you've forgotten to
include <stdlib.h>, you won't know it if you cast malloc's return
value. Highly detailed discussions on this topic can be found in this
group's archives.

I then noticed that the size of the executable was similar regardless of
whether
I used (A) or (B) which might have been a mild advantage of (B).

Mostly irrelevent, unless you have the (mis)fortune of developing on a
highly space-sensitive platform, such as an embedded device.

In which case you should know how much memory your program can use to the
nearest byte or word.

Other than compiler/linker problems, assuming MAX is fixed (as it is!)
why would I use (B) rather than (A)?
Use A when:

1) You know how much space you want at compile time,
2) You won't want more space at any future time, and
3) You don't run into problems such as the one you're having.

Otherwise, use B. (Right, clc?) Remember that you must free() memory
you allocate with malloc().

And always check to see if your call to malloc() succeeded; that is,
always test the pointer you got back against NULL.

I like to use constructions like the below:

#include <stdlib.h>

/* ... */

int *ptr;

if ((ptr = malloc(sizeof(i nt) * LEN)) == NULL) {
/* Handle failure to allocate RAM */
}

I think the answer relates to stack versus heap (but I'm interested in any
other answers that come up). Can anyone point me to an online reference on
stack vs heap, my google searches haven't inspired me.

On this newsgroup, "stack" and "heap" are dangerous terms, as
implementations need not use such structures to manage the memory they
allocate. As for references, the following contain a wealth of
valuable C information:

http://www.ungerhu.com/jxh/clc.welcome.txt
http://www.eskimo.com/~scs/C-faq/top.html
http://benpfaff.org/writings/clc/off-topic.html

Good pointers. ;)

--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.

[Rakesh]

August Derleth wrote:

And always check to see if your call to malloc() succeeded; that is,
always test the pointer you got back against NULL.

I like to use constructions like the below:

#include <stdlib.h>

/* ... */

int *ptr;

if ((ptr = malloc(sizeof(i nt) * LEN)) == NULL) {
/* Handle failure to allocate RAM */
}

My two cents - Before you start writing your C++ code, write your
wrappers for all the routine things that you would do - mem. allocation
(like the one above), sockets, files etc. It would really help a lot
later in terms of debugging the code later.

--
Rakesh Kumar
** Remove nospamplz from my email address for my real email **

[August Derleth]

On Mon, 19 Apr 2004 20:06:37 -0700, Rakesh wrote:

My two cents - Before you start writing your C++ code, write your
wrappers for all the routine things that you would do - mem. allocation
(like the one above), sockets, files etc. It would really help a lot
later in terms of debugging the code later.

Who says we're going to write C++?

(I probably missed something in the original post. Sorry.)

[OT]
Using malloc() in C++ isn't good style, as I understand it.
[/OT]

--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.

[Rakesh Kumar]

Sorry for the confusion and bringing in C++ here.

I wanted to mention abt wrappers ( and that has nothing to do with, if u
do in C++ or not ).

August Derleth wrote:

On Mon, 19 Apr 2004 20:06:37 -0700, Rakesh wrote:

My two cents - Before you start writing your C++ code, write your
wrappers for all the routine things that you would do - mem. allocation
(like the one above), sockets, files etc. It would really help a lot
later in terms of debugging the code later.

Who says we're going to write C++?

(I probably missed something in the original post. Sorry.)

[OT]
Using malloc() in C++ isn't good style, as I understand it.
[/OT]

--

--
Rakesh Kumar
** Remove nospamplz from my email address for my real email **

[josh]

"Hal Styli" <no_spam@all> wrote in news:40******** **@127.0.0.1:

I need to use a large array and I'm not sure when one should
use (A) and when one should use (B) below:-

#define MAX 10000000

(A) int x[MAX];

(B) int *x = ( int * ) malloc( MAX*sizeof( int ) ); [...] Other than compiler/linker problems, assuming MAX is fixed (as it is!)
why would I use (B) rather than (A)?

I think the answer relates to stack versus heap (but I'm interested in
any other answers that come up). Can anyone point me to an online
reference on stack vs heap, my google searches haven't inspired me.

If "int x[MAX];" is global or static, it will typically not be put in
either place. Usually it'll get added to the .bss section, which is stored
in your executable as just a size, then the OS will allocate that much
memory somewhere for you when your program starts. Completely system
dependent, but pretty common.

Otherwise, the only serious reason I can think of to prefer (B) is: what
happens when you don't have that much memory available? With (A), your
program dies in some way that you probably have no control over. With (B),
you can exit gracefully and let the user know why. (or, algorithm
permitting, fall back to a smaller size)

-josh

[heyo]

August Derleth <se*@sig.now> wrote in message news:<pa******* *************** ******@sig.now> ...

On Tue, 20 Apr 2004 01:45:53 +0000, Christopher Benson-Manica wrote:

Hal Styli <no_spam@all> spoke thus:
[...]
Mostly irrelevent, unless you have the (mis)fortune of developing on a
highly space-sensitive platform, such as an embedded device.
In which case you should know how much memory your program can use to the
nearest byte or word.

.... and you don't need to alloc() memory, because you know it's there and
it's all yours. :-)

Other than compiler/linker problems, assuming MAX is fixed (as it is!)
why would I use (B) rather than (A)?

Use A when:

1) You know how much space you want at compile time,
2) You won't want more space at any future time, and
3) You don't run into problems such as the one you're having.
4) You realy need it.

Otherwise, use B. (Right, clc?) Remember that you must free() memory
you allocate with malloc().

And always check to see if your call to malloc() succeeded; that is,
always test the pointer you got back against NULL.
[...]

That makes (A) a favorite even if you don't know the exact amount but
an upper limit. (and have enough so you mustn't be stingy)

I think the answer relates to stack versus heap (but I'm interested in any
other answers that come up). Can anyone point me to an online reference on
stack vs heap, my google searches haven't inspired me.

On this newsgroup, "stack" and "heap" are dangerous terms, as
implementations need not use such structures to manage the memory they
allocate. [...]

.... but for most of them you can assum that local variables end up
on the stack and global (and static) variables end up on the heap.
So your problem (stack overflow ?) may vanish, if you declare your
big array global. (If it doesn't bother you that that is regarded
bad style.)

bye,
heyo

[Darrell Grainger]

On Tue, 20 Apr 2004, Hal Styli wrote:

Hello,

Can someone please help.

I need to use a large array and I'm not sure when one should
use (A) and when one should use (B) below:-

#define MAX 10000000

(A) int x[MAX];

(B) int *x = ( int * ) malloc( MAX*sizeof( int ) );
Just a side note. If you failed to have #include <stdlib.h> the compiler
will not have a prototype for malloc. This will lead to undefined
behaviour. The behaviour might be things work fine. On the other hand, it
migth crash your computer or format your hard drive. If you had:

int *x = malloc(MAX*size of(int));

and failed to #include <stdlib.h>, you should get a warning or error
message.
This isn't a compiler specific problem, but just for some background, I was
using (A) for lower values of MAX but when I started increasing it, I hit
some compiler/linker problems with the borland compiler.

I then noticed that the size of the executable was similar regardless of
whether
I used (A) or (B) which might have been a mild advantage of (B).

Other than compiler/linker problems, assuming MAX is fixed (as it is!)
why would I use (B) rather than (A)?

I think the answer relates to stack versus heap (but I'm interested in any
other answers that come up). Can anyone point me to an online reference on
stack vs heap, my google searches haven't inspired me.
The idea of stack vs heap assumes your compiler is using a stack and a
heap. If you are looking for a generic C answer then forget that.

Method A will only work if you know the size of the array at compile time.
If the size of the array is dependent on the user then you must use method
B. Since you indicate that you can use either method the decision is not
being force one way or the other.

If I use method A, I'll know at compile or load time whether the program
will work. It will also work or not work. With method B, I have to wait
until run time to see if it will work. But I have the option to recover.
If the call to malloc fails I can have a fall back plan. I could switch to
secondary memory or process an array of half the size twice. It I'm just
going to exit then it is no better than method A.

On the other hand, I realize that different compilers and platforms behave
differently. I might try both methods and measure the performance of each.
For my particular platform with a specific compiler I might find one
method is notably better than the other. I'd put a comment reminding
myself and anyone else who might inherit my code.

If my testing found that method B was no better than method A, I'd go with
method A because it is less work for me.
Thanks in advance
Hal.

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@ whitehouse.gov