array greater than 100

[P.N.]

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

[Simon Biber]

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.

[Mark McIntyre]

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

[Keith Thompson]

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.

[Keith Thompson]

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.

[Simon Biber]

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.

[Keith Thompson]

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.

[santosh]

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?

[Jordan Abel]

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.

[P.N.]

> 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.

[Mark McIntyre]

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

[P.N.]

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

[Vladimir S. Oka]

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.

[Robert Gamble]

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

[Keith Thompson]

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.

[Jordan Abel]

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.

[Mark McIntyre]

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

[Keith Thompson]

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.

[Jordan Abel]

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.