Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Creating and Accessing Very Big Arrays in C

Reply
Thread Tools

Creating and Accessing Very Big Arrays in C

 
 
djhulme@gmail.com
Guest
Posts: n/a
 
      08-08-2006
Hi,

I'm using GCC. Please could you tell me, what is the maximum number of
array elements that I can create in C, i.e.

char* anArray = (char*) calloc( ??MAX?? , sizeof(char) ) ;

I've managed to create arrays using DOUBLE data types, but when I try
to access the array, the compiler complains that the number is not an
INT, i.e.

// this succeeds
char* anArray = (char*) calloc( 999999999999999999 , sizeof(char) ) ;

// this does not compile because the number 1234567891234584 is not an
INT
anArray[1234567891234584] = 1 ;

Your help and advice would be sinceraly appreciated.

Thanking you in anticipation,

Daniel

 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      08-08-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Hi,
>
> I'm using GCC. Please could you tell me, what is the maximum number of
> array elements that I can create in C, i.e.
>
> char* anArray = (char*) calloc( ??MAX?? , sizeof(char) ) ;
>

Depends on your system.

> I've managed to create arrays using DOUBLE data types, but when I try
> to access the array, the compiler complains that the number is not an
> INT, i.e.
>

Should that be 'int'?

> // this succeeds
> char* anArray = (char*) calloc( 999999999999999999 , sizeof(char) ) ;
>

Realy?

> // this does not compile because the number 1234567891234584 is not an
> INT
> anArray[1234567891234584] = 1 ;
>

If you can allocate more than INT_MAX elements, you should probably
write 1234567891234584LL to tell the compiler the constant is a long
long, otherwise it will default to int.

--
Ian Collins.
 
Reply With Quote
 
 
 
 
Old Wolf
Guest
Posts: n/a
 
      08-08-2006
Ian Collins wrote:
> (E-Mail Removed) wrote:
> > // this does not compile because the number 1234567891234584 is not an
> > INT
> > anArray[1234567891234584] = 1 ;
> >

> If you can allocate more than INT_MAX elements, you should probably
> write 1234567891234584LL to tell the compiler the constant is a long
> long, otherwise it will default to int.


Constants always take on a type that can represent them
(unless there is no such type). In this case, the constant
will be a long long without you having to specify it --
assuming that the number exceeds LONG_MAX, and that
the compiler is in C99 mode.

I don't know where this myth came from that there is
something wrong with un-suffixed constants.

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      08-08-2006
Old Wolf wrote:
> Ian Collins wrote:
>
>>(E-Mail Removed) wrote:
>>
>>>// this does not compile because the number 1234567891234584 is not an
>>>INT
>>>anArray[1234567891234584] = 1 ;
>>>

>>
>>If you can allocate more than INT_MAX elements, you should probably
>>write 1234567891234584LL to tell the compiler the constant is a long
>>long, otherwise it will default to int.

>
>
> Constants always take on a type that can represent them
> (unless there is no such type). In this case, the constant
> will be a long long without you having to specify it --
> assuming that the number exceeds LONG_MAX, and that
> the compiler is in C99 mode.
>
> I don't know where this myth came from that there is
> something wrong with un-suffixed constants.
>

In my case, the dim and distant past!

Cheers,

--
Ian Collins.
 
Reply With Quote
 
Tom St Denis
Guest
Posts: n/a
 
      08-09-2006
(E-Mail Removed) wrote:
> I've managed to create arrays using DOUBLE data types, but when I try
> to access the array, the compiler complains that the number is not an
> INT, i.e.
>
> // this succeeds
> char* anArray = (char*) calloc( 999999999999999999 , sizeof(char) ) ;


I doubt you are allocating what you think you are (hint: truncation).
Also why are you casting the return value?

How many times can people say "don't cast void pointers" before newbs
actually read the advice and do it?

> // this does not compile because the number 1234567891234584 is not an
> INT
> anArray[1234567891234584] = 1 ;
>
> Your help and advice would be sinceraly appreciated.


This usually is a sign you are trying to address objects larger than
your platform can natively address. E.g. on a 32-bit platform the
object has more than 4 billion entries. On a 64-bit platform it means
you have an object with 2^64 entries which you most certainly don't
have enough disk or memory for.

Why are you trying to use such large arrays?

There are ways of emulating sparsely populated arrays. Perhaps that's
what you want?

Tom

 
Reply With Quote
 
jaysome
Guest
Posts: n/a
 
      08-09-2006
On 8 Aug 2006 16:22:52 -0700, "Old Wolf" <(E-Mail Removed)>
wrote:

>Ian Collins wrote:
>> (E-Mail Removed) wrote:
>> > // this does not compile because the number 1234567891234584 is not an
>> > INT
>> > anArray[1234567891234584] = 1 ;
>> >

>> If you can allocate more than INT_MAX elements, you should probably
>> write 1234567891234584LL to tell the compiler the constant is a long
>> long, otherwise it will default to int.

>
>Constants always take on a type that can represent them
>(unless there is no such type). In this case, the constant
>will be a long long without you having to specify it --
>assuming that the number exceeds LONG_MAX, and that
>the compiler is in C99 mode.
>
>I don't know where this myth came from that there is
>something wrong with un-suffixed constants.


Which begs the question, why would one ever use a suffixed constant?

--
jay
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      08-09-2006
jaysome wrote:
> On 8 Aug 2006 16:22:52 -0700, "Old Wolf" <(E-Mail Removed)>
> wrote:
>
>
>>Ian Collins wrote:
>>
>>>(E-Mail Removed) wrote:
>>>
>>>>// this does not compile because the number 1234567891234584 is not an
>>>>INT
>>>>anArray[1234567891234584] = 1 ;
>>>>
>>>
>>>If you can allocate more than INT_MAX elements, you should probably
>>>write 1234567891234584LL to tell the compiler the constant is a long
>>>long, otherwise it will default to int.

>>
>>Constants always take on a type that can represent them
>>(unless there is no such type). In this case, the constant
>>will be a long long without you having to specify it --
>>assuming that the number exceeds LONG_MAX, and that
>>the compiler is in C99 mode.
>>
>>I don't know where this myth came from that there is
>>something wrong with un-suffixed constants.

>
>
> Which begs the question, why would one ever use a suffixed constant?
>


long double a = 1e500;

This is an error because 1e500 is a double constant and its maximum
value can be only around 1e300. To avoid
getting garbage you HAVE to put the 'L' like

long double a = 1e500L;
 
Reply With Quote
 
Harald van =?UTF-8?B?RMSzaw==?=
Guest
Posts: n/a
 
      08-09-2006
jaysome wrote:
> On 8 Aug 2006 16:22:52 -0700, "Old Wolf" <(E-Mail Removed)>
> wrote:
>>Constants always take on a type that can represent them
>>(unless there is no such type). In this case, the constant
>>will be a long long without you having to specify it --
>>assuming that the number exceeds LONG_MAX, and that
>>the compiler is in C99 mode.
>>
>>I don't know where this myth came from that there is
>>something wrong with un-suffixed constants.

>
> Which begs the question, why would one ever use a suffixed constant?


long long int i = 1LL << 40;
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-09-2006
jacob navia <(E-Mail Removed)> writes:
> jaysome wrote:
>> On 8 Aug 2006 16:22:52 -0700, "Old Wolf" <(E-Mail Removed)>
>> wrote:

[...]
>>>I don't know where this myth came from that there is
>>>something wrong with un-suffixed constants.

>> Which begs the question, why would one ever use a suffixed constant?

>
> long double a = 1e500;
>
> This is an error because 1e500 is a double constant and its maximum
> value can be only around 1e300. To avoid
> getting garbage you HAVE to put the 'L' like
>
> long double a = 1e500L;


Interesting point. Integer literals have a type that depends on the
value of the literal and the range of the type; floating-point
literals don't. I suppose that since floating-point has both range
and precision, it would be more difficult to construct a consistent
set of rules.

(If DBL_MAX >= 1e500, the above declaration is ok, but you do need the
suffix to be safe.)

So the previous question can be changed to: why would one ever use a
suffixed *integer* constant?

One example is an argument to a variadic function, but that's probably
fairly rare. In most contexts, numeric values will be implicitly
converted to the required type.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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.
 
Reply With Quote
 
tgur
Guest
Posts: n/a
 
      08-09-2006
Tom St Denis wrote:

> How many times can people say "don't cast void pointers" before newbs
> actually read the advice and do it?
>

Could you explain, why casting void pointers is bad?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Multidimensional arrays and arrays of arrays Philipp Java 21 01-20-2009 08:33 AM
GIDS 2009 .Net:: Save Big, Win Big, Learn Big: Act Before Dec 29 2008 Shaguf ASP .Net 0 12-26-2008 09:29 AM
GIDS 2009 .Net:: Save Big, Win Big, Learn Big: Act Before Dec 29 2008 Shaguf ASP .Net Web Controls 0 12-26-2008 06:11 AM
GIDS 2009 Java:: Save Big, Win Big, Learn Big: Act Before Dec 29 2008 Shaguf Python 0 12-24-2008 07:35 AM
GIDS 2009 Java:: Save Big, Win Big, Learn Big: Act Before Dec 29 2008 Shaguf Ruby 0 12-24-2008 05:07 AM



Advertisments