Array size limitiation in Visual C/C++

I'm porting a Unix app that I developed to windows and I'm having a
terrible time getting the bloody thing to work. I can compile just
fine but when I run I get stack overflow errors. I started taking
things apart and found that the problem stems from the size of the
arrays I'm declaring. These are arrays of structures and some of them
are quite large (100,000 elements, it's an engineering app).

I've been able to get things working by reducing the array sizes but
I'd really like to know the limits for Visual C/C++ 6.0? The largest
array I have is now down to 15,000 elements and that's going to just
barely cover what I need (but not the future need). Unix handles this
without a hitch with some of the arrays at 250,000 elements. Do I have
to download the GNU compiler or is this just a Windows limitation?

Thanks for any help you can give me,

James Kimble

re: Array size limitiation in Visual C/C++

"James Kimble" <jkimble@one.net> wrote:
[color=blue]
> I'm porting a Unix app that I developed to windows[/color]
....[color=blue]
> the problem stems from the size of the
> arrays I'm declaring. These are arrays of structures and some of them
> are quite large (100,000 elements, it's an engineering app).[/color]

Is there a particular reason not to use dynamically allocated arrays (or
std::vector)
and allocate them when they are first needed ?

David F

re: Array size limitiation in Visual C/C++

"James Kimble" <jkimble@one.net> wrote in message
news:<edf020eb.0311272120.4bc1e96d@posting.google. com>...[color=blue]
> I'm porting a Unix app that I developed to windows and I'm having a
> terrible time getting the bloody thing to work. I can compile just
> fine but when I run I get stack overflow errors. I started taking
> things apart and found that the problem stems from the size of the
> arrays I'm declaring. These are arrays of structures and some of them
> are quite large (100,000 elements, it's an engineering app).
>
> I've been able to get things working by reducing the array sizes but
> I'd really like to know the limits for Visual C/C++ 6.0? The largest
> array I have is now down to 15,000 elements and that's going to just
> barely cover what I need (but not the future need). Unix handles this
> without a hitch with some of the arrays at 250,000 elements. Do I have
> to download the GNU compiler or is this just a Windows limitation?
>
> Thanks for any help you can give me,
>
> James Kimble[/color]

dear James.
you can't handle big array under windows UNLESS you are using pointers.
i had this problem while handling a static array of size 100000
(Array[100000]).
this will give a successful compilation, but a big time run-time error.
SOLUTION:
use pointers;
instead of declaring a static array of 100000 like this:
int Array[100000;
do this:
int* Array = NULL ; //<<this is a pointer poiting to NULL(be sure to
include <iostream>)
Array = new int [100000] ; //<<here, you just created a Dynamic array
of 100000

after you are done with your array, be sure to delete it by using:
delete [ ] Array ;

anytime
Eliahooo

re: Array size limitiation in Visual C/C++

James Kimble wrote:[color=blue]
> I'm porting a Unix app that I developed to windows and I'm having a
> terrible time getting the bloody thing to work. I can compile just
> fine but when I run I get stack overflow errors. I started taking
> things apart and found that the problem stems from the size of the
> arrays I'm declaring. These are arrays of structures and some of them
> are quite large (100,000 elements, it's an engineering app).
>
> I've been able to get things working by reducing the array sizes but
> I'd really like to know the limits for Visual C/C++ 6.0? The largest
> array I have is now down to 15,000 elements and that's going to just[/color]

From the online help:

"/STACK (Stack Allocations)
Home | Overview | How Do I | Linker Options

The Stack Allocations (/STACK:reserve[,commit]) option sets the size of the
stack in bytes.

To find this option in the development environment, click Settings on the
Project menu. Then click the Link tab, and click Output in the Category
box."

--
Regards,

Joe Hotchkiss,
http://joe.hotchkiss.com

XXXXXXXXXXXXXXXXXXXXXXXXX
X joe.hotchkiss X
X at baesystems.com X
XXXXXXXXXXXXXXXXXXXXXXXXX

re: Array size limitiation in Visual C/C++

"Elie Nader" <elienader@sympatico.ca> skrev i en meddelelse
news:EvBxb.20210$dt2.1536107@news20.bellglobal.com ...[color=blue]
>
>
> "James Kimble" <jkimble@one.net> wrote in message
> news:<edf020eb.0311272120.4bc1e96d@posting.google. com>...[color=green]
> > I'm porting a Unix app that I developed to windows and I'm having a
> > terrible time getting the bloody thing to work. I can compile just
> > fine but when I run I get stack overflow errors. I started taking
> > things apart and found that the problem stems from the size of the
> > arrays I'm declaring. These are arrays of structures and some of them
> > are quite large (100,000 elements, it's an engineering app).
> >
> > I've been able to get things working by reducing the array sizes but
> > I'd really like to know the limits for Visual C/C++ 6.0? The largest
> > array I have is now down to 15,000 elements and that's going to just
> > barely cover what I need (but not the future need). Unix handles this
> > without a hitch with some of the arrays at 250,000 elements. Do I have
> > to download the GNU compiler or is this just a Windows limitation?
> >
> > Thanks for any help you can give me,
> >
> > James Kimble[/color]
>
> dear James.
> you can't handle big array under windows UNLESS you are using pointers.
> i had this problem while handling a static array of size 100000
> (Array[100000]).
> this will give a successful compilation, but a big time run-time error.
> SOLUTION:
> use pointers;
> instead of declaring a static array of 100000 like this:
> int Array[100000;
> do this:
> int* Array = NULL ; //<<this is a pointer poiting to NULL(be sure to
> include <iostream>)
> Array = new int [100000] ; //<<here, you just created a Dynamic array
> of 100000
>
> after you are done with your array, be sure to delete it by using:
> delete [ ] Array ;
>
> anytime
> Eliahooo
>
>[/color]
Your solution is errorprone and tedious. Use std::vector instead.

/Peter

re: Array size limitiation in Visual C/C++

"Joe Hotchkiss" <nospam@baesystems.com> wrote in message
news:3fc7198a$1@baen1673807.greenlnk.net...[color=blue]
> James Kimble wrote:[color=green]
> > I'm porting a Unix app that I developed to windows and I'm having a
> > terrible time getting the bloody thing to work. I can compile just
> > fine but when I run I get stack overflow errors. I started taking
> > things apart and found that the problem stems from the size of the
> > arrays I'm declaring. These are arrays of structures and some of them
> > are quite large (100,000 elements, it's an engineering app).
> >
> > I've been able to get things working by reducing the array sizes but
> > I'd really like to know the limits for Visual C/C++ 6.0? The largest
> > array I have is now down to 15,000 elements and that's going to just[/color]
>
> From the online help:
>
> "/STACK (Stack Allocations)
> Home | Overview | How Do I | Linker Options
>
> The Stack Allocations (/STACK:reserve[,commit]) option sets the size of[/color]
the[color=blue]
> stack in bytes.
>
> To find this option in the development environment, click Settings on the
> Project menu. Then click the Link tab, and click Output in the Category
> box."
>[/color]

That is going to cure the symptoms (at least for a while) but not a real
solution. Using such large static arrays you're normally heading for
trouble, as the OP already experienced. I'd strongly suggest to use the
standard library's vector class.

Regards
Chris

re: Array size limitiation in Visual C/C++

Peter Koch Larsen wrote:[color=blue][color=green]
>> you can't handle big array under windows UNLESS you are using pointers.
>> i had this problem while handling a static array of size 100000
>> (Array[100000]).
>> this will give a successful compilation, but a big time run-time error.
>> SOLUTION:
>> use pointers;
>> instead of declaring a static array of 100000 like this:
>> int Array[100000;
>> do this:
>> int* Array = NULL ; //<<this is a pointer poiting to NULL(be sure to
>> include <iostream>)
>> Array = new int [100000] ; //<<here, you just created a Dynamic array
>> of 100000
>>
>> after you are done with your array, be sure to delete it by using:
>> delete [ ] Array ;
>>
>> anytime
>> Eliahooo
>>
>>[/color]
> Your solution is errorprone and tedious. Use std::vector instead.
> ...[/color]

No, since the code being ported is written in terms of built-in C++
arrays, this solution is significantly less "error prone and tedious"
than using 'std::vector<>'.

--
Best regards,
Andrey Tarasevich

re: Array size limitiation in Visual C/C++

"Andrey Tarasevich" <andreytarasevich@hotmail.com> skrev i en meddelelse
news:RJednd7rZJKBM1qiRVn-sQ@comcast.com...[color=blue]
> Peter Koch Larsen wrote:[/color]
[snip][color=blue][color=green][color=darkred]
> >> SOLUTION:
> >> use pointers;
> >> instead of declaring a static array of 100000 like this:
> >> int Array[100000;
> >> do this:
> >> int* Array = NULL ; //<<this is a pointer poiting to NULL(be sure[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> >> include <iostream>)
> >> Array = new int [100000] ; //<<here, you just created a Dynamic[/color][/color][/color]
array[color=blue][color=green][color=darkred]
> >> of 100000
> >>
> >> after you are done with your array, be sure to delete it by using:
> >> delete [ ] Array ;
> >>
> >> anytime
> >> Eliahooo
> >>
> >>[/color]
> > Your solution is errorprone and tedious. Use std::vector instead.
> > ...[/color]
>
> No, since the code being ported is written in terms of built-in C++
> arrays, this solution is significantly less "error prone and tedious"
> than using 'std::vector<>'.
>
> --
> Best regards,
> Andrey Tarasevich
>
>[/color]
Why? Do you believe that the task of changing the signature of functions
(alternatively create wrapper functions) will take longer time and be more
errorprone than replacing array-definitions with new-delete pairs? I doubt
that will be the case.

/Peter