Click here to Skip to main content
15,887,214 members
Home / Discussions / C / C++ / MFC
   

C / C++ / MFC

 
GeneralRe: how big array size does a visual c++ program allow ? Pin
mrby12324-Apr-06 9:27
mrby12324-Apr-06 9:27 
GeneralRe: how big array size does a visual c++ program allow ? Pin
Maximilien24-Apr-06 10:02
Maximilien24-Apr-06 10:02 
GeneralRe: how big array size does a visual c++ program allow ? Pin
mrby12324-Apr-06 10:07
mrby12324-Apr-06 10:07 
Answer[Message Deleted] Pin
Joe Woodbury24-Apr-06 10:08
professionalJoe Woodbury24-Apr-06 10:08 
GeneralRe: how big array size does a visual c++ program allow ? Pin
venadder24-Apr-06 10:10
venadder24-Apr-06 10:10 
GeneralRe: how big array size does a visual c++ program allow ? Pin
mrby12324-Apr-06 10:11
mrby12324-Apr-06 10:11 
GeneralRe: how big array size does a visual c++ program allow ? Pin
David Crow24-Apr-06 10:19
David Crow24-Apr-06 10:19 
GeneralRe: how big array size does a visual c++ program allow ? Pin
Rilhas25-Apr-06 9:22
Rilhas25-Apr-06 9:22 
I would strongly sugest you not to use GlobalAlloc(). Why limit your code to Windows if you don't really need to? Standard ANSI should be fine for your problem. I assume, of course, that you are programming for Win32. If this is not the case then my comments don't apply. But if you avoid GlobalAlloc() you can easilly port to LINUX, which is very similar to Win32 but where GlobalAlloc() doesn't exist.

The first thing you need to do is estimate how much memory you are demanding from the system. From your figures I assume the largest is 3 arrays of doubles with 16400 entries each. Since each double is 8 bytes on most platforms, this results in a total of 393600 bytes of RAM. That's peanuts by today's standards... I assume your computer is equipped with 16MB of RAM or more, so memory outage is surelly not the problem. I have 512 MB, and I once needed 1.3 GB for a simulation, and the virtual memory manager tolerated it just fine. So I'm sure memory outage is not a problem.

There are no real limits on array sizes except those you declare on the stack. Stack is the only real limited resource. It is the space where you declare local variables, and the space the compiler uses to remember where to return to after a function call and where it places the parameters that you pass to functions.

If you are not used to pointers then I would suggest you use a little class to wrap the pointer code. I will paste an example below. This will hide the complexities of allocation and will tolerate bad pointer coding practices.


template <class t="">
class Array {
protected:
T* itsBuffer;
long itsBufferCount;
void Crash(void) { char* p=0; *p=0; }
public:
Array(long count) {
itsBuffer=new T[count];
itsBufferCount=count;
if (!itsBuffer) Crash();
}
Array(Array<t>& arr); // dummy
~Array() {
if (itsBuffer) delete [] itsBuffer;
}
long GetCount(void) {
return itsBufferCount;
}
T* Get(long index_0_based=0) {
if (index_0_based<0) Crash();
if (index_0_based>=itsBufferCount) Crash();
return itsBuffer+index_0_based;
}
T& operator[](long index_0_based) {
return *Get(index_0_based);
}
};

long main_2(Array<double> arr) {
return arr.GetCount();
}

long main_3(Array<double>& arr) {
return arr.GetCount();
}

void main(void) {
long i;
long arr_size=16400;
Array<double> arr_a(arr_size);
Array<double> arr_b(arr_size);
Array<double> arr_c(arr_size);
#ifdef _DEBUG
// slow protected implementation to detect software errors
Array<double>& a=arr_a;
Array<double>& b=arr_b;
Array<double>& c=arr_c;
#else
// fast unprotected implementation for release builds
double* a=arr_a.Get();
double* b=arr_b.Get();
double* c=arr_c.Get();
#endif
for(i=0; i<arr_size; i++)="" {
="" a[i]="100000+i;
" b[i]="200000+i;
" c[i]="300000+i;
" }
="" call="" functions
="" main_2(arr_a);
="" main_3(arr_a);
="" check="" protection
="" a[-1]="316.7;
}



The" example="" above="" shows="" you="" how="" to="" declare="" arrays="" of="" doubles.="" the="" code="" is="" reusable,="" so="" could="" as="" easilly="" integers,="" classes,="" or="" structs.="" class="" protected="" against="" "java="" coding="" style",="" meaning="" that="" don't="" have="" worry="" about="" forgetting="" delete="" array.="" destructor="" will="" do="" for="" you.

the="" protection="" fairly="" simple="" in="" this="" example.="" array="" simply="" crash="" if="" something="" gets="" out="" hand.="" although="" a="" real="" application="" would="" probably="" catch="" these="" exceptions,="" i="" just="" software="" keep="" simple.="" however,="" already="" can="" track="" errors="" other="" causes,="" like="" bad="" addresses.

for="" _debug="" define="" cause="" "a",="" "b",="" and="" "c"="" identifiers="" be="" array<double=""> objects, referencing their respective original arrays. Thus, accessing them with "a[i]", "b[i]", or "c[i]" will invoke the operator[] of class Array. This will be slow, since for every access a function will be called, the parameter will be checked, and if all goes well then the reference to the array entry is finally returned to be used.

For example, the last line has an invalid access to array index -1. If you run this code then this line will cause a crash. If you activate the display of the call stack in the VC debugger you can see where the fault was detected, and climb up the stack to find out where the cause is. For the a[-1] the 4th entry of the call stack will show you the error location. This is a very usefull way of tracking down bugs burried inside complex code.

When you build the release version then the _DEBUG define will not be defined, as, as a result, the "a", "b", and "c" will be compiled as pointers to the buffer of doubles for fast direct access. Setting up "a", "b", and "c" by calling Get() is not the most efficient way to set up the pointers, but typically the impact is not relevant and the code is clean and readable. As a downside no checking is performed, and the a[-1] may not be detected. So build the release after the debug has shown that there are no more bugs. If performance is not an issue, then use only the operator[] version.

I tested the code above with array sizes of 10,000,000 (yes, 10 million!!) and it works just fine. Granted my system has 512 MB, but the theoretical 240,000,000 bytes (10,000,000 entries * 8 bytes per entry * 3 arrays) was confirmed by taking a look at the task manager pausing at a breakpoint after array creation (235 MB in total, with the data taking about 228 MB).

Another thing to note: in JAVA references are implicit, but in C/C++ they are not. So, if you called main_2 then a copy of the array would be made. This would require more memory, and a copy of the contents to be created. In main_3 this does not happen, since the array is passed as a reference. In C/C++ don't forget the & when passing a reference.

To protect the code against such mistakes I added the copy constructor to the Array but with no implementation (// dummy line). If I didn't add the dummy copy contructor line then the compiler would feel free to make a flat copy, and that would be a bad copy for the object (which is not flat). I wouldn't notice it except that the code would use up more memory than necessary and eventually crashed (if I got lucky). No warning or error is issued during compilation stage. This is a very bad flaw in C++ design.

Since I don't want to make copies (in this example) I want a way to protect myself against my own mistakes (of forgetting the & in function prototypes). So I state that I have my own copy constructor (with the dummy line), and so the compiler is not allowed to use its own copy contructor, and, instead, will have to use mine.

But since I don't provide an implementation for the copy constructor then the compiler will issue a link error stating that my copy contructor is unresolved. When I see this error I know I have made a mistake somewhere and after finding the bad line (invocation of main_2) I correct it and the error disappears (everything will be ok, I don't provide a copy contructor implementation but my code doesn't need one, so the compiler has no problem with the missing copy constructor).

I hope this helps.

Rilhas
AnswerRe: how big array size does a visual c++ program allow ? Pin
Stephen Hewitt24-Apr-06 21:54
Stephen Hewitt24-Apr-06 21:54 
GeneralRe: how big array size does a visual c++ program allow ? Pin
mrby12325-Apr-06 16:03
mrby12325-Apr-06 16:03 
QuestionSuggestions for Memory Leak Tool Pin
Barry Etter24-Apr-06 7:10
Barry Etter24-Apr-06 7:10 
AnswerRe: Suggestions for Memory Leak Tool Pin
Maximilien24-Apr-06 7:49
Maximilien24-Apr-06 7:49 
AnswerRe: Suggestions for Memory Leak Tool Pin
Shog924-Apr-06 8:00
sitebuilderShog924-Apr-06 8:00 
AnswerRe: Suggestions for Memory Leak Tool Pin
Joe Woodbury24-Apr-06 10:20
professionalJoe Woodbury24-Apr-06 10:20 
QuestionHow to get my IP ? Pin
Surivevoli24-Apr-06 7:02
Surivevoli24-Apr-06 7:02 
AnswerRe: How to get my IP ? Pin
Bob X24-Apr-06 7:11
Bob X24-Apr-06 7:11 
GeneralRe: How to get my IP ? Pin
Surivevoli24-Apr-06 8:13
Surivevoli24-Apr-06 8:13 
GeneralRe: How to get my IP ? Pin
Bob X24-Apr-06 10:24
Bob X24-Apr-06 10:24 
GeneralRe: How to get my IP ? Pin
Nibu babu thomas24-Apr-06 17:09
Nibu babu thomas24-Apr-06 17:09 
AnswerRe: How to get my IP ? Pin
David Crow24-Apr-06 7:36
David Crow24-Apr-06 7:36 
QuestionSelection of lengthy path in the open save dialog box, retunr truncated string Pin
Sandeep. Vaidya24-Apr-06 5:37
Sandeep. Vaidya24-Apr-06 5:37 
AnswerRe: Selection of lengthy path in the open save dialog box, retunr truncated string Pin
Nibu babu thomas24-Apr-06 17:17
Nibu babu thomas24-Apr-06 17:17 
GeneralRe: Selection of lengthy path in the open save dialog box, retunr truncated string Pin
Sandeep. Vaidya24-Apr-06 20:25
Sandeep. Vaidya24-Apr-06 20:25 
GeneralRe: Selection of lengthy path in the open save dialog box, retunr truncated string Pin
Sandeep. Vaidya25-Apr-06 0:06
Sandeep. Vaidya25-Apr-06 0:06 
GeneralRe: Selection of lengthy path in the open save dialog box, retunr truncated string Pin
Nibu babu thomas25-Apr-06 1:49
Nibu babu thomas25-Apr-06 1:49 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.