I'm experimenting with large arrays in VisualStudio2013 IDE and I'm noticing that when trying to allocate arrays larger than about 1GB, C++ style, i.e. by using:
the program crashes. I have traced the crash to this line so it is at the call of the 'new' function it happens.Code:double *myArray = new double[numBytes];
But when I allocate C-style, i.e.
the program runs just fine.Code:double *myArray = (double *)malloc(numBytes);
What is the value of numBytes?
Is it the same with both snippets?
How much memory does your system have, what operating system are you using, what compiler, compiler version?
Do you realize that your first snippet may be allocating more memory than your second snippet?
Jim
Well, I have experimented with many different values of numBytes but it is around 1GB that the crash happens. The value if numBytes is of course the same, try for example '12000*12000*sizeof(double)'.
I had about 8GB of free RAM according to task manager at the time of executions, according to task manager.
Operating system: Windows 7 x64 SP1.
Given the same numBytes, I cannot see how the first code snippet allocates more memory than the second snippet. If that's the case then something is horribly wrong with C++, or the C++ part of the Visual compiler.
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.31101 for x64
So what you're saying is that this is a bug within the compiler?
No there's nothing wrong with your compiler, it's your understanding of that nasty C function malloc() that is lacking. Your first snippet is allocating doubles, your second snippet is only allocating bytes. Doubles are usually about 8 bytes each.Given the same numBytes, I cannot see how the first code snippet allocates more memory than the second snippet. If that's the case then something is horribly wrong with C++, or the C++ part of the Visual compiler.
Jim
^ Or rather, the understanding of new, since numBytes is misplaced there, not in malloc.
Perhaps, but since this is the C++ forum I lean towards misunderstanding malloc(), especially since the OP was under the impression that his malloc() call was allocating enough space for "numBytes" doubles.
Also since this is the C++ forum the OP should start using the safer C++ style casts.
Jim
The OP should be using std::vector, not new.
Originally Posted by Adak
Yes, I have misunderstood "new", not malloc(). I thought that it wanted number of bytes as input argument whereas the number of elements should be used as input argument. After making the correction my programs run fine with "new" and "delete[]".
But still, if it fails to allocate memory, why crash the program? Why not just terminate without allocating the memory or, at the very least, throw an exception?
Yes, std::vector looks really nice and powerful, will use it in the future if it doesn't consume too much of performance.
Last edited by bot; 11-23-2015 at 01:49 PM.
new does throw an exception called std::bad_alloc, but any exception that goes uncaught will cause termination eventually.
Operator new DOES throw an exception if it fails to allocate the memory. If you never catch that exception, it WILL crash your program.
I have played around with try and catch(std::bad_alloc &errH) blocks and that seemed to prevent the crash.
I tried using
Code:int x(999999), y(999999); int nBytes(x*y);
which yielded a large number. But when I used
Code:int x(1<<16), y(1<<16); int nBytes(x*y);
I found that x*y was 0! So
Code:array = new double[0];
is what caused the crash. I solved it by using
Now I realize that allocating 32GB of memory won't crash the system, only create a very big page file. Not at the point of allocation of course but when filling it with data.Code:int x(1<<16), y(1<<16); int64 nBytes = static_cast<int64>(x)*y;
I also realize that 'nBytes' is not the number of bytes but number of elements in this context.
Last edited by bot; 11-23-2015 at 02:53 PM.
Because the lower 32 bits yield 1101 0100 1000 0110 1000 1011 1000 0001 -- i.e. a very large number.
In this case, the lower 32 bits are only 0s.Code:int x(1<<16), y(1<<16); int nBytes(x*y);
I found that x*y was 0! So
Disable or reduce the page file to a very small file. The page file is evil™.Now I realize that allocating 32GB of memory won't crash the system, only create a very big page file. Not at the point of allocation of course but when filling it with data.
