Thank you all for your input, It seems clear that an const unsigned int would be the best choice while checking for a segfault error. I had assumed that creating an array of such a large size would cause some kind of an error on most systems but wasn't sure what to do about it.
Creating an array of that size isn't only an error for most systems, it's an error for a compiler. You simply can't have an array of that size.Originally Posted by osyrez
On my computer, SIGN_MAX was 2147483647. Which would make this a 32 bit integer. Now, if you do the math (We'll make it 2147483648 to remain in integers).Code:const unsigned int USIGN_MAX = (unsigned int)-1; // The largest unsigned value const signed int SIGN_MAX = USIGN_MAX / 2; // The largest signed value int main() { int foo[SIGN_MAX] = { 0 }; return 0; }You can see why this is a problem. Your compile may let you get away with this with a char, but if you plan on initializing it, good luck getting it to run.Code:2147483648 times 4 bytes equals 8589934592 bytes divided by 1024 equals 8388608 kilobytes divided by 1024 equals 8182 megabytes divided by 1024 equals 8 gigabytes of memory
Last edited by SlyMaelstrom; 08-16-2006 at 09:28 PM.
Sent from my iPadŽ
Another approach I saw recently was to use some RSIZE_MAX and test against it.
(page 17 of 89 page pdf)
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
ick.... ya I see what you mean.
So I'm assuming the max size an array can have is determined by how much avaliable memory a system has. If this is the case then one could find out how much memory is avaliable before creation of the dynamic array and determine from that what the maximum size of the array could be. Of course that would leave no room for anything else so that wouldn't be desirable. Now I suppose one could subtract off of that an amount that would leave a reasonable amount of memory for the system to run normaly. But then again that is quite a large chunk of memory to be allocating for one array, and that would also limit the use of the function. Although I'm hesitant to set a limit to a possible array size, it seems like the best option so far. I would just need to figure out what the largest array size I could need for my purpose and maybee add a bit just to be sure.
On that note I'm thinking of doing somthing of the sort
using #define to set my maximum size for all arrays in the program and allowing my to easily change that value if needed.Code:#define MAX_ARRAY_SIZE 1000 function(const unsigned); int main() {... return 0;} void function(const unsigned size) {if (size > MAX_ARRAY_SIZE) {}throw some_error;}
No, no, no, and no... just stop what you're thinking and back up. Forget about checking system resources, system memory, or anything like that... If you're creating an array that could potentially cause system instability it's so large then you are already doing something wrong. Arrays suck... period. They're good for very small things in C++. If you're handling a lot of data, look to containers like vectors and queues. They'll automatically allocate, deallocate, resize everything for you. No need to decide at the beginning how much memory you need or can afford. If your container gets too large, then you can store it in a file on the harddrive (god forbid) and use it like a swap file.
Sent from my iPadŽ
