besides ::malloc() what alternatives for Windows?

I think a better question is why did you reach the point where malloc is failing? With virtual memory being standard operating procedure in modern OSes, it should be extremely rare unless you're doing something silly.

Can you elaborate on what problems you're doing and how you're solving them?

Showing your code would be helpful also. The class you are trying to allocate an instance of, does it have a static new() method?

Normally, if bad-alloc is thrown, it indicates that you are trying to allocate more memory than you possibly could, given the amount of memory available on your system (RAM + virtual memory). Make sure you are not trying to allocate such a crazy amount of memory. And if this is the reason for the problem, then any alternative to malloc is not going to help you, because you will still run out of memory, whichever way you try to allocate it (from RAM).

Another possible, and much worse, reason for bad-alloc to get thrown is if you have corrupted your heap. This can happen when you delete the same memory twice, or if you ask one heap to delete memory that was allocated by another (e.g., allocating in a DLL and freeing in the EXE). That is a much more serious problem that requires significant investigation or memory debugging to find.

As far as alternatives go, the main alternative to malloc on Windows is to use the HeapAlloc function which is like malloc but allows you to specify which heap to use, and you can create a new heap object with HeapCreate. But that will not really solve the root problem that is causing your bad-alloc exception (whichever is the reason for it). The implementation of malloc on Windows probably uses HeapAlloc under-the-hood anyways (or GlobalAlloc or LocalAlloc, which are just shorthands for HeapAlloc with the default heap object, the one you get from the GetProcessHeap function).

If you do absolutely have to allocate a very large amount of memory (note: you should do whatever you can to avoid that), then you can look into using memory-mapped files, which is used to create a file that is made to appear to the program as regular RAM memory. Note, however, that this will be extremely slow and should not be needed in general. You could also just read and write the data to a file directly.

What other alternatives for Windows in memory allocation?

1. Use smart_pointers, std::string, std::vector<> etc. instead of raw pointers.
   http://msdn.microsoft.com/en-in/library/hh279674.aspx
   Unless the program has exhorbitant memory needs, this would fix the problem.

2. If dynamic memory requirements are well in excess of 1 GB, and you are on a 64-bit windows platform, switch to MinGW64.
   http://nuwen.net/mingw.html

3. Even if you switch to MinGW64, use smart_pointers, std::string, std::vector<> etc. instead of raw pointers.

Hello all! I am trying to generate prime numbers well in excess of 1Gbyte of mem. Yeah, it is a bit silly to do such things unless you are interested in Click Here

Wow, there are this many alternatives to malloc() for Windows, i am humbled. Some suggestions here are drastic... What I did was to do those calculations in my Nvidia graphics card SDK cuda_malloc(), and yes, rubberman, it involves overloading operator new with a static version. Ooh, Viking Mike's url is handy, i will bookmark them. Thank you all for responding!

Some years ago I wrote a bunch of code to generate any number of primes. I used the Sieve of Aristhostenes to generate all the primes up to 10K or so and then used a recursive algorithm to determine primes beyond that. I would write them out to disk, and memory use was small - I did this on an old Compaq PC with 640K RAM, back in 1984-1985. It was computationally intense, but I had an 8087 chip which let me deal with large numbers up to 32-bits without problems (unsigned long integers of the time) and quite efficiently - IE, primes up to 4 billion. Today, you can use 64-bit unsigned integers for a googleplex of primes. :-)

And don't ask me to post the code here. I still have it on a floppy disk somewhere, but I currently have no functional floppy disk reader.

am trying to generate prime numbers well in excess of 1Gbyte of mem.

It does not matter what knid of contortions we go thrugh to allocate memory - new, malloc, HeapAlloc, GlobalAlloc, VirtualAlloc, MapViewOfFile ... - we are fundamentaly limited by the virtual address space that we have. With MinGW32, the total amount of memory available for user land use is 2 GB (could have been 3 GB if MinGW was built with /largeaddressaware). Of this 2GB, a chunk is taken away by the executable image, system and language libraries etc.

Repeat: If dynamic memory requirements are well in excess of 1 GB, and you are on a 64-bit windows platform, switch to MinGW64.

I have made a search based on the question asking about the replacement of malloc function in Windows. I found some information like, for dynamic memory allocation like malloc fuction, it is possible to replace all callas to to the standard functions automatically with the use of scalable equivalents of Intel threading building blocks. It may improve the performance of the application. The replacement can be done using the proxy library. The a scalable memory allocator library and the proxy library must be of the same release of the Intel threading building blocks to be compatible.

Intel compilers and libraries are generally first class, but they are not free. You can get the same results with other compilers and libraries. On Linux, supposedly using the -pthreads option for the gcc compilers will use a thread safe version of malloc. I do know that when I use malloc/calloc/realloc on Linux using pthreads, that I have never had an issue (in 8+ years), so I suspect that is the case. As for Windows, that is an entirely different issue that I am not able to answer... :-( Sorry!