MSVC gives up on template heavy code with "fatal error C1060: compiler is out of heap space"

I am trying to compile some relatively template heavy code with MSVC (2010), and it eventually quits with fatal error C1060: compiler is out of heap space.

The whole thing is just one translation unit, and, in comparsion, gcc handles it quite easily (inside a VM, with significantly fewer r开发者_开发技巧esources).

Any hints what to look for? Are there any relevant compiler options?

You might be able to counter this by explicitly adding the /Zm option to the C/C++ options of your project. e.g. /Zm256

See this page for the possible solution with the /Zm compiler option, as Mordachai suggested. Instead of using higher limit for the precompiled header, you may want to try lowering it, so the system has more free memory avaible.

I was able to resolve a C1060 error with moderate template code by reducing the amount of template arguments on my templates. For example, if Foo expects three types:

template< typename T1, typename T2, typename T3 > struct Foo
{
  T1 t1;
  T2 t2;
  T3 t3;
};

Foo< int, char, bool > foo;

Then encapsulate the types into a single struct, and use that struct as the argument.

template< typename T_ARG > struct Foo
{
  typename T_ARG::T1 t1;
  typename T_ARG::T2 t2;
  typename T_ARG::T3 t3;
};

struct FooArgs
{
  typedef int  T1;
  typedef char T2;
  typedef bool T3;
};

Foo< FooArgs > foo;

If specialization is required, then consider:

• Push specialized behavior into policies and inherit from them.
• Keep arguments on which you need to specialize in the argument list.
• Chain the types into a typelist. Foo< TypeList< int, TypeList< char, TypeList< bool, NullType > > > >.

In case anyone run into this problem, here's a possible solution:

One potential cause of this error is cl.exe is bumping against the 2 gig application memory limit in 32-bit version of Windows. Normally Windows split the 4 gig address space right in the middle, giving 2 gig to the OS and 2 gig to an application. You can change that to a 1/3 split instead. On Windows 7 and Vista, run the following in a command prompt as an administrator:

bcdedit /set IncreaseUserVa 3072

Then restart the computer. Now MSVC has 3 gig to work with instead of 2.

Doing so has just allowed me compile a project that was failing due to error C1060. According to Resource Monitor, cl.exe was consuming just above 2 gig of memory. It would have failed under the regular address space arrangement.

Limiting the OS to just 1 gig can have adverse impact on performance during everyday use of your computer. To change the split back to 2/2, run the following:

bcdedit /deletevalue IncreaseUserVa

I had a similar issue (also template-heavy), and I was already using /Zm1000 to compile my code (which worked initially). However, after cleaning-up the code, dividing long functions to smaller ones, putting stuff to namespaces / etc., the compiler would spit out the error message:

fatal error C1060: compiler is out of heap space.

right after starting, without any delay (not actually seeming to compile anything). At first, I was confused, as I have 32 GB of swap space and only about 6.1 GB was used at the time. I'm also running x64 OS, so there should be a plenty of memory and swap for everyone.

I referred to MSDN and found out that I actually needed to lower to /Zm800 and now it works great. My understanding is that taking up all heap space for the precompiled header buffer actually locks out the memory space; so using /Zm2000 would leave a 32-bit compiler without means to dynamically allocate memory for other stuff (which it somehow also needs, making the /Zm option completely ridiculous - use with caution).

I'm using MSVC 6.0, but I hope this helps in 2010 as well.

(VC2022 Community x64) my C1060 was triggered by 2 problems when using deep #define nesting to instantiate a tree of templates with lots of different arguments. /Zm[x] didn't help.

it required two fixes:

1. change Project-> C++ ->Preprocessor -> Use Standard Conforming Preprocessor to Yes (/Zc:preprocessor).

(without it died with C1060 almost straight away without compiling much).

2. after that, cl.exe compiles but eventually runs out of of memory (at around 35GB on my setup), and then still causes C1060. allocating more swap space fixed it.