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

array greater than 100

P: n/a
Hi!
when i define array[100][100] (any type)
then compilator say that array is to large! ??

i need at least 10.000 instead 100. This is for numeric methods in "C"

any sugestion?
thx
Greetings
P
Mar 18 '06 #1
Share this Question
Share on Google+
18 Replies


P: n/a
P.N. wrote:
Hi!
when i define array[100][100] (any type)
then compilator say that array is to large! ??

i need at least 10.000 instead 100. This is for numeric methods in "C"

any sugestion?


Try something like this:

#include <stdio.h>
#include <stdlib.h>

type (*foo)[100] = malloc(100 * sizeof *foo);
if(foo == NULL)
{
fprintf(stderr, "Error allocating memory\n");
exit(EXIT_FAILURE);
}
else
{
/* use foo here, for example: */

for(int i = 0; i < 100; i++)
for(int j = 0; j < 100; j++)
foo[i][j] = i + j;

/* then free up the memory: */

free(foo);
}
This defines 'foo' as a pointer to an array of 100 'type' objects.
It then allocates 100 of these 100-element arrays.

For some reasons that are off-topic on comp.lang.c, this method of
allocation is more likely to work than directly specifying a 100x100 array.

--
Simon.
Mar 18 '06 #2

P: n/a
On Sat, 18 Mar 2006 13:51:26 +0100, in comp.lang.c , "P.N."
<el******@klub.chip.pl> wrote:
Hi!
when i define array[100][100] (any type)
then compilator say that array is to large! ??
you've hit a limitation of your compiler. The C standard doesn't
require compilers to support objects that large.
i need at least 10.000 instead 100. This is for numeric methods in "C"

any sugestion?


Read up on malloc
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 18 '06 #3

P: n/a
Simon Biber <ne**@ralmin.cc> writes:
P.N. wrote:
Hi!
when i define array[100][100] (any type)
then compilator say that array is to large! ??
i need at least 10.000 instead 100. This is for numeric methods in
"C"
any sugestion?
Try something like this:

#include <stdio.h>
#include <stdlib.h>

type (*foo)[100] = malloc(100 * sizeof *foo);
if(foo == NULL)
{
fprintf(stderr, "Error allocating memory\n");
exit(EXIT_FAILURE);
}
else
{
/* use foo here, for example: */

for(int i = 0; i < 100; i++)
for(int j = 0; j < 100; j++)
foo[i][j] = i + j;

/* then free up the memory: */

free(foo);
}
This defines 'foo' as a pointer to an array of 100 'type' objects.


No, "foo" is a pointer to an array of 100 pointers to "type" objects.
It then allocates 100 of these 100-element arrays.


You didn't perform those allocations.

I'm suprised that a declaration like:
char array_obj[100][100]
would cause a problem; that's only 10,000 bytes. But if you want a
bigger array of larger elements, then yes, you're likely to need to
use some other approach.

See question 6.16 in the comp.lang.c FAQ, <http://www.c-faq.com/>.
See also the rest of section 6, and the rest of the FAQ; it's all good
stuff.

(Simon, just citing the FAQ would have saved you a lot of time and
avoided the risk of errors.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Mar 18 '06 #4

P: n/a
Mark McIntyre <ma**********@spamcop.net> writes:
On Sat, 18 Mar 2006 13:51:26 +0100, in comp.lang.c , "P.N."
<el******@klub.chip.pl> wrote:
when i define array[100][100] (any type)
then compilator say that array is to large! ??


you've hit a limitation of your compiler. The C standard doesn't
require compilers to support objects that large.


10000 bytes? Yes, it does. (He said "any type", so I presume that
includes char.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Mar 19 '06 #5

P: n/a
Keith Thompson wrote:
Simon Biber <ne**@ralmin.cc> writes:
type (*foo)[100] = malloc(100 * sizeof *foo); [...]This defines 'foo' as a pointer to an array of 100 'type' objects.

No, "foo" is a pointer to an array of 100 pointers to "type" objects.


I don't think so! There are no pointers to "type" objects involved.

$ cdecl explain 'int (*foo)[100]'
declare foo as pointer to array 100 of int

$ cat test.c
#include <stdio.h>

int main(void)
{
int (*foo)[100];

printf("sizeof foo = %zu\n", sizeof foo);
printf("sizeof *foo = %zu\n", sizeof *foo);

return 0;
}

$ c99 test.c

$ ./a.out
sizeof foo = 8
sizeof *foo = 400

Here, foo is a pointer (8 bytes, 64 bits). It points to an array of size
400 bytes, ie. 100 ints (each 4 bytes, 32 bits).

My malloc call was:
malloc(100 * sizeof *foo)

This allocated 100 * sizeof *foo. Assuming 'type' was int, that's 40000
bytes on my machine.

--
Simon.
Mar 19 '06 #6

P: n/a
Simon Biber <ne**@ralmin.cc> writes:
Keith Thompson wrote:
Simon Biber <ne**@ralmin.cc> writes:
type (*foo)[100] = malloc(100 * sizeof *foo); [...]This defines 'foo' as a pointer to an array of 100 'type' objects.

No, "foo" is a pointer to an array of 100 pointers to "type" objects.


I don't think so! There are no pointers to "type" objects involved.


D'oh! You're right.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Mar 19 '06 #7

P: n/a
Mark McIntyre wrote:
On Sat, 18 Mar 2006 13:51:26 +0100, in comp.lang.c , "P.N."
<el******@klub.chip.pl> wrote:
Hi!
when i define array[100][100] (any type)
then compilator say that array is to large! ??


you've hit a limitation of your compiler. The C standard doesn't
require compilers to support objects that large.


Doesn't the standard garuntee that objects upto 64 kilobytes are
garunteed to be supported?

Mar 19 '06 #8

P: n/a
On 2006-03-19, santosh <sa*********@gmail.com> wrote:
Doesn't the standard garuntee that objects upto 64 kilobytes are
garunteed to be supported?


Not quite.
Mar 19 '06 #9

P: n/a
> 10000 bytes? Yes, it does. (He said "any type", so I presume that
includes char.)

sorry, of course no char, for numerical algorithm i do not need char type.
Mar 19 '06 #10

P: n/a
On Sun, 19 Mar 2006 03:40:49 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
Mark McIntyre <ma**********@spamcop.net> writes:
On Sat, 18 Mar 2006 13:51:26 +0100, in comp.lang.c , "P.N."
<el******@klub.chip.pl> wrote:
when i define array[100][100] (any type)
then compilator say that array is to large! ??


you've hit a limitation of your compiler. The C standard doesn't
require compilers to support objects that large.


10000 bytes? Yes, it does. (He said "any type", so I presume that
includes char.)


For C99 you're right:

5.2.4.1 trranslation limits
- 65534 bytes in an object. (in a hosted environment only).

However I recall that C89 was 32K, and I suspect the OP is using one
of those. Anyone got the old standard, to confirm?
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 19 '06 #11

P: n/a
I SEE imortant thing , that borland c++ 3.11 that i generally use, doesnt
permiss compile arrays up to max 40.
but borland c++ builder 6 permiss make arrays for example more than 1000
elemnts... and more dimensions.

of course that you later told is equal important.
thanks
P.N
Mar 19 '06 #12

P: n/a
P.N. opined:
I SEE imortant thing , that borland c++ 3.11 that i generally use,
doesnt permiss compile arrays up to max 40.
but borland c++ builder 6 permiss make arrays for example more than
1000 elemnts... and more dimensions.
Limitations of your particular implementation are off-topic here.
of course that you later told is equal important.


Who knows what who said when you did not post any context?

Read:

<http://cfaj.freeshell.org/google/>
<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

before posting again.

--
BR, Vladimir

Your true value depends entirely on what you are compared with.

Mar 19 '06 #13

P: n/a
Mark McIntyre wrote:
On Sun, 19 Mar 2006 03:40:49 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:
Mark McIntyre <ma**********@spamcop.net> writes:
On Sat, 18 Mar 2006 13:51:26 +0100, in comp.lang.c , "P.N."
<el******@klub.chip.pl> wrote:
when i define array[100][100] (any type)
then compilator say that array is to large! ??

you've hit a limitation of your compiler. The C standard doesn't
require compilers to support objects that large.


10000 bytes? Yes, it does. (He said "any type", so I presume that
includes char.)


For C99 you're right:

5.2.4.1 trranslation limits
- 65534 bytes in an object. (in a hosted environment only).

However I recall that C89 was 32K, and I suspect the OP is using one
of those. Anyone got the old standard, to confirm?


The limit for C89 was indeed 32K (actually 32,767 bytes, one byte less
than 32K) but this should still be enough for the OP to create an
object of 10000 chars.

Robert Gamble

Mar 19 '06 #14

P: n/a
Jordan Abel <ra*******@gmail.com> writes:
On 2006-03-19, santosh <sa*********@gmail.com> wrote:
Doesn't the standard garuntee that objects upto 64 kilobytes are
garunteed to be supported?


Not quite.


Jordan, what exactly do you mean by "Not quite"? Are you referring to
the fact that the actual limit is 65535, 1 byte less than 64 kilobytes
(kibibytes if we're being pedantic)? Or do you mean that an
implementation is only required to accept a single program that
contains at least one instance of each of the limits specified in
5.2.4.1? Or did you mean something else?

Either way, posting "Not quite." with no further explanation is a
waste of time -- particularly mine. Presumably you know what what you
mean; take the time to tell the rest of us.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Mar 19 '06 #15

P: n/a
On 2006-03-19, Keith Thompson <ks***@mib.org> wrote:
Jordan Abel <ra*******@gmail.com> writes:
On 2006-03-19, santosh <sa*********@gmail.com> wrote:
Doesn't the standard garuntee that objects upto 64 kilobytes are
garunteed to be supported?
Not quite.


Jordan, what exactly do you mean by "Not quite"? Are you referring to
the fact that the actual limit is 65535, 1 byte less than 64 kilobytes
(kibibytes if we're being pedantic)? Or do you mean that an
implementation is only required to accept a single program that
contains at least one instance of each of the limits specified in
5.2.4.1? Or did you mean something else?


I meant the second. The belief that everything will be OK as long as he
doesn't allocate any single object over 65535 bytes is obviously
ridiculous, so I didn't feel the need to explain.

Either way, posting "Not quite." with no further explanation is a
waste of time -- particularly mine. Presumably you know what what you
mean; take the time to tell the rest of us.

Mar 19 '06 #16

P: n/a
On 19 Mar 2006 07:19:37 -0800, in comp.lang.c , "Robert Gamble"
<rg*******@gmail.com> wrote:
The limit for C89 was indeed 32K (actually 32,767 bytes, one byte less
than 32K) but this should still be enough for the OP to create an
object of 10000 chars.


He wanted 10,000 floats (he clarified that later).
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Mar 19 '06 #17

P: n/a
Jordan Abel <ra*******@gmail.com> writes:
On 2006-03-19, Keith Thompson <ks***@mib.org> wrote:
Jordan Abel <ra*******@gmail.com> writes:
On 2006-03-19, santosh <sa*********@gmail.com> wrote:
Doesn't the standard garuntee that objects upto 64 kilobytes are
garunteed to be supported?

Not quite.


Jordan, what exactly do you mean by "Not quite"? Are you referring to
the fact that the actual limit is 65535, 1 byte less than 64 kilobytes
(kibibytes if we're being pedantic)? Or do you mean that an
implementation is only required to accept a single program that
contains at least one instance of each of the limits specified in
5.2.4.1? Or did you mean something else?


I meant the second. The belief that everything will be OK as long as he
doesn't allocate any single object over 65535 bytes is obviously
ridiculous, so I didn't feel the need to explain.


Since your comment was addressed to someone who obviously didn't know
that, clarity was particularly important.
Either way, posting "Not quite." with no further explanation is a
waste of time -- particularly mine. Presumably you know what what you
mean; take the time to tell the rest of us.


--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Mar 19 '06 #18

P: n/a
On 2006-03-19, Keith Thompson <ks***@mib.org> wrote:
Jordan Abel <ra*******@gmail.com> writes:
On 2006-03-19, Keith Thompson <ks***@mib.org> wrote:
Jordan Abel <ra*******@gmail.com> writes:
On 2006-03-19, santosh <sa*********@gmail.com> wrote:
> Doesn't the standard garuntee that objects upto 64 kilobytes are
> garunteed to be supported?

Not quite.

Jordan, what exactly do you mean by "Not quite"? Are you referring to
the fact that the actual limit is 65535, 1 byte less than 64 kilobytes
(kibibytes if we're being pedantic)? Or do you mean that an
implementation is only required to accept a single program that
contains at least one instance of each of the limits specified in
5.2.4.1? Or did you mean something else?


I meant the second. The belief that everything will be OK as long as he
doesn't allocate any single object over 65535 bytes is obviously
ridiculous, so I didn't feel the need to explain.


Since your comment was addressed to someone who obviously didn't know
that, clarity was particularly important.


I shouldn't have to, if it's "obviously ridiculous". I interpreted the
statement I was replying to as indicative of a belief whose logical
extension was that you are guaranteed the ability to allocate _any
number_ of 65535-byte objects with no problem.
Either way, posting "Not quite." with no further explanation is a
waste of time -- particularly mine. Presumably you know what what you
mean; take the time to tell the rest of us.

Mar 19 '06 #19

This discussion thread is closed

Replies have been disabled for this discussion.