Fatal error c1060 компилятору не хватает размера кучи

I’m trying to build a program from its source code with VC 11. When the compiler is about to finish, it raises the error mentioned in title of this post.

As I’ve read here and in other forums, I tried to both close as many programs as possible and enlarge the size of the swap file in Windows… neither works.

I’ve read about a parameter called Zm but I don’t understand how to use it.

Can you please help me?

Olivia Stork

4,6005 gold badges26 silver badges39 bronze badges

asked May 28, 2014 at 16:26

SagittariusASagittariusA

5,22915 gold badges71 silver badges126 bronze badges

Take a look at this documentation which gives possible solutions:

I also had that problem and found the documentation useful. Main points:

If the compiler also issues errors C1076 and C3859, use the /Zm compiler option to lower the memory allocation limit. More heap space
is available to your application if you lower the remaining memory
allocation.

If the /Zm option is already set, try removing it. Heap space might be
exhausted because the memory allocation limit specified in the option
is too high. The compiler uses a default limit if you remove the /Zm
option.

If you are compiling on a 64-bit platform, use the 64-bit compiler toolset. For information, see How to: Enable a 64-Bit Visual C++
Toolset on the Command Line.

On 32-bit Windows, try using the /3GB boot.ini switch.

Increase the size of the Windows swap-file.

Close other running programs.

Eliminate unnecessary include files.

Eliminate unnecessary global variables, for example, by allocating memory dynamically instead of declaring a large array.

Eliminate unused declarations.

Split the current file into smaller files.

svick

232k50 gold badges385 silver badges509 bronze badges

answered Oct 21, 2016 at 10:37

I can’t tell much about the /Zm parameter, but I had the same issue (compiler is out of heap space).

What has helped me was the /m:4 (4 for the count of your CPUs) parameter so that you can use multiple CPUs for building.

Hope that helps you as well.

Also, if you are running on x64, be sure that the x64 version of «msbuild.exe» and «cl.exe» is beeing used. I had the issue that even when using e.g. the x64 ms powershell, the compiler would still choose the 32-bit version of msbuild.exe (in task manager «msbuild.exe*32», windows 7)

answered Sep 20, 2017 at 9:30

In addition to the other answers here (and in my case), fatal error C1060: compiler is out of heap space can be caused by a syntax error. The following code (in certain circumstances) can cause this error even with correct compiler options — for instance if you’ve previously successfully compiled the same program.

r.push_back(e[1];

instead of

r.push_back(e[1]);

It seems to only cause this error rather than the standard error C2143: syntax error: missing ')' before ';' when r and e are of certain types, but it’s worth checking any code you’ve edited recently if the program previously compiled without errors.

answered Feb 23, 2018 at 15:09

We had similar problem: a relativelly simple program (although, full of templates, using Eigen library) persistently failed to compile on one of the computers. All were using MSVC2013 x64, but only one was unable to compile the program due to C1060 error. We tried different compiler flags, setting/unsetting -Zm, but failed to resolve it without modifying code.

Some pointers were, however, given to us, when we switched from x64/x64 (64bit compiler for 64bit resulting executable) version of the compiler to the x86/x86 (32bit compiler for 32bit resulting executable). The x86 compiler gave us exact locations of the problematic parts of the program — calls to template functions receiving heavy templated objects. We have rewritten those to normal functions (build in different object file) and that solved the problem…

answered Nov 6, 2017 at 21:19

TimeSTimeS

1112 silver badges4 bronze badges

VS: Visual Studio 2015
OS: Windows10

If you are using VS2015 as your IDE, maybe there is another solution:
Go to update the VS2015 «Update3» package and everything will work smoothly.

answered Nov 29, 2019 at 1:35

W. DanW. Dan

8067 silver badges10 bronze badges

In my case, a main program would not compile is VS 2022 Community Edition (free). It had many include files. By process of elimination, I managed to compile it once I removed any «volatile» modifiers in declarations that had this modifier.
A very strange bug, to say the least!

answered Mar 24, 2022 at 21:17

I got this error when compiling OnnxRuntime with MS Visual C++ 17 2022.

The solution for this issue was to close all other programs and compile using a single thread (in this case, removing the —parallel argument from the build.bat call).

answered Jan 26 at 15:05

Adriel JrAdriel Jr

2,26618 silver badges24 bronze badges

Источник

Содержание

Fatal error c1060 компилятору не хватает размера кучи
Asked by:
Question
All replies
Fatal error c1060 компилятору не хватает размера кучи
Вопрос:
Комментарии:
Fatal error c1060 компилятору не хватает размера кучи

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

Question

I keep getting that error when trying to compile one C++ file. It includes some library headers that are full with templates, but I’m 100% sure that code is correct since it’s an popular, well tested library and I was able to compile with those headers a couple versions earlier.

First I tried in Visual C++ 2008 SP1 EE, then VC++ 2010 Beta 2. The behaviour is even worse in VC++ 2010 cause the compiler somehow «caches» the compile command and no clean, no code changes, no configuration switches, no manual deleting of Visual output files can force a recompilation attempt.

I did try various /Zm values (from 200 to 2000) but it has no effect. cl.exe exits before it allocates 350 MB, so I doubt memory shortage is a real issue here (I have 2G of Ram and 2G of page file).

For programs, heap space is very different to physical memory. But anyway, if you think it is a bug go to http://connect.microsoft.com and go to the Visual Studio and .NET Framework connection and report a bug. But the question is, how does VC2010 RC handle this?

Visit my (not very good) blog at http://c2kblog.blogspot.com/

Please check MSDN article about Fatal Error C1060, and try the possible solutions:

* Use /Zm to increase memory allocation limit.
* Increase the size of the Windows swap-file.
* Close other running programs.
* Eliminate unnecessary include files.
* Eliminate unnecessary global variables, for example, by allocating memory dynamically instead of declaring a large array.
* Eliminate unused declarations.
* Split the current file into smaller files.

If you think this is a bug, could you give us a small sample to reproduce this issue?

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Instead of nesting a map as the value, I nested a pointer to the map. The trick is that I have to remember that the value is a pointer. I created a template to delete the values as my intention is that this container owns the values. At least the branches delete themselves. I did not try using smart pointers.

#ifndef nullptr
#define nullptr NULL
#endif

template >
class MapToPtrOfValuesOwned : public std::map
<
public:

MapToPtrOfValuesOwned()
<
typename std::map ::iterator it_end = std::map ::end();
for (typename std::map ::iterator it = std::map ::begin(); it != it_end; ++it)
<
Value ptr = it->second;
if (ptr != nullptr)
delete ptr;
>
>

typedef std::map qaa;
typedef qaa* p_qaa;
typedef MapToPtrOfValuesOwned qab;
typedef qab* p_qab;
typedef MapToPtrOfValuesOwned qac;
typedef qac* p_qac;
typedef MapToPtrOfValuesOwned qad;
typedef qad* p_qad;
typedef MapToPtrOfValuesOwned qae;
typedef qae* p_qae;
typedef MapToPtrOfValuesOwned qaf;
typedef qaf* p_qaf;
typedef MapToPtrOfValuesOwned qag;
typedef qag* p_qag;
typedef MapToPtrOfValuesOwned qah;
typedef qah* p_qah;
typedef MapToPtrOfValuesOwned qai; // works not using pointers
typedef qai* p_qai;
typedef MapToPtrOfValuesOwned qaj; // out of heap not using pointers
typedef qaj* p_qaj;
typedef MapToPtrOfValuesOwned qak;

class MyClass
<
public:
qak theTree;

int main(int x, char* y[])
<
MyClass a;
qak theFix;

Источник

Fatal error c1060 компилятору не хватает размера кучи

#c #visual-c

Вопрос:

Я играю с комбинаторами синтаксических анализаторов и у меня есть некоторый шаблонный код (множество функций, шаблонизированных поверх лямбд). Когда я пытаюсь скомпилировать его cl.exe использует около 660 МБ памяти (в соответствии с диспетчером задач), затем завершается с ошибкой «C1060: компилятору не хватает места в куче». В моей системе доступно гораздо больше памяти (16 ГБ файл подкачки, и только половина из них используется другими процессами), поэтому я не понимаю, почему я получаю эту ошибку.

Я прочитал все другие темы об этой проблеме и страницу MSDN и попробовал их решения.

Переключение на 64-разрядную инструментальную архитектуру на некоторое время решило проблему, но когда мой проект стал больше, ошибка вернулась, хотя cl.exe по-прежнему далек от пределов физической или виртуальной памяти.
/Zm не имел никакого эффекта, независимо от того, установил я его высоким или низким, я все равно не использую предварительно скомпилированные заголовки.
Изменение /MP (многопроцессорная компиляция), будь то включение или отключение, не имело никакого эффекта.

Я использую Visual Studio Community Edition 2019 v16.11.5 и компилирую с помощью /std:c 20, если это имеет значение.

Я вставил свой код в Godbolt, хотя я не знаю, как использовать многофайловые проекты на Godbolt, так что это просто для того, чтобы поделиться им. Если я закомментирую различные разделы кода в ExpandBrace.cpp он успешно компилируется в MSVC, поэтому я думаю, что это реальная проблема с памятью и не связана с какой-либо ошибкой в коде.

Я почти уверен, что мой проект будет скомпилирован, если cl.exe я бы использовал больше памяти, прежде чем сдаваться, но я не могу найти никакого способа увеличить лимит памяти кучи.

1. Не вдаваясь в подробности, есть одна вещь, которую можно попробовать: разделить большие файлы .cpp на два, которые вы компилируете отдельно. Это просто обычай иметь один .hpp и один .cpp, но так не должно быть.

2. Правильная странность может привести к очень быстрому потреблению памяти, за которым последует сбой программы и ее полное освобождение. Это может быть один ошибочный запрос на безумный объем памяти. Это может закончиться так быстро, что ни один живой человек не сможет этого увидеть.

3. @user4581301 Есть ли способ исследовать эту возможность дальше? Я чувствую, что это не то, что происходит, но я хотел бы правильно исключить это.

4. Боюсь, понятия не имею. Я в основном использую Visual Studio для отладчика, и мне никогда не приходилось отлаживать саму Visual Studio.

5. @UlrichEckhardt Я попробовал, и это сработало. Мне не нравится это решение, оно уродливое, и я чувствую, что в нем нет необходимости, однако оно подтверждает, что мой код работает, и я могу, по крайней мере, использовать его в качестве обходного пути, если не появится лучшего решения.

Источник

Fatal error c1060 компилятору не хватает размера кучи

Проект компилится 10 минут и выдает fatal error C1060: compiler is out of heap space.
VS 2008. Активно используется boost::mpl, boost::fusion.

Установка опции компилятора /Zm не помогает. Виртуальная память 5 Гигабайт.

Как быть? Может есть рецепты для преодоления?
Заранее спасибо!

	От:	eklmn
Дата:	13.10.08 07:39
Оценка:	-1

Здравствуйте, Аноним, Вы писали:

А>Проект компилится 10 минут и выдает fatal error C1060: compiler is out of heap space.
А>VS 2008. Активно используется boost::mpl, boost::fusion.
А>Установка опции компилятора /Zm не помогает. Виртуальная память 5 Гигабайт.
А>Как быть? Может есть рецепты для преодоления?

1. взять бубен и побегать с ним.
3. найти телепата, кот. по ошибке компилятора определяет в какой строке и какая ошибка.
2. выявить куски кода которые являются причиной проблемы и запостить их сюда
для изучения/замены на нормально компилирующийся вариант.

	От:	Кодт
Дата:	13.10.08 08:20
Оценка:

Здравствуйте, , Вы писали:

А>Проект компилится 10 минут и выдает fatal error C1060: compiler is out of heap space.
А>VS 2008. Активно используется boost::mpl, boost::fusion.

А>Установка опции компилятора /Zm не помогает. Виртуальная память 5 Гигабайт.

Возможно, что слишком большая рекурсия в метафункциях.
Даже не столь глубокая (например, функция Аккермана), а широкая. Порождается куча воплощений шаблонов и исчерпывается память.
А тот факт, что память даже на 5 гигабайтах исчерпывается — значит, что где-то затаилась бесконечность.

	От:	K13	http://akvis.com
Дата:	13.10.08 10:24
Оценка:	-1

А>>Установка опции компилятора /Zm не помогает. Виртуальная память 5 Гигабайт.

А толку? 32-битный процесс не может адресовать больше 2 Gb адресного пространства (во вторую пару гигов он может загрузить DLL дополнительно к системным).

	От:	Кодт
Дата:	13.10.08 10:57
Оценка:

Здравствуйте, eklmn, Вы писали:

E>3. найти телепата, кот. по ошибке компилятора определяет в какой строке и какая ошибка.

Несерьёзно. Когда наступает ICE, компилятор сообщает, в какой строке ЕГО исходников произошла ошибка.

А вот насчёт бубнов — тут да, стоит побубнить.
Обычно такие вещи решаются методом отсечения.
1) Ставишь #error в разные места программы и смотришь, до какой строки возникает рукодельная ошибка, а после какой — ICE
2) Начинаешь резать свои мега-функции, наблюдая, на чём пропадает/возникает ICE

	От:	Аноним
Дата:	13.10.08 20:18
Оценка:

	От:	eklmn
Дата:	13.10.08 21:34
Оценка:

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, eklmn, Вы писали:

E>>3. найти телепата, кот. по ошибке компилятора определяет в какой строке и какая ошибка.

К>Несерьёзно. Когда наступает ICE, компилятор сообщает, в какой строке ЕГО исходников произошла ошибка.

И? Что это дает?
Потом, msvc далеко не всегда на свои internal error выдает где именно ему поплохело.

К>А вот насчёт бубнов — тут да, стоит побубнить.
К>Обычно такие вещи решаются методом отсечения.
К>1) Ставишь #error в разные места программы и смотришь, до какой строки возникает рукодельная ошибка, а после какой — ICE
К>2) Начинаешь резать свои мега-функции, наблюдая, на чём пропадает/возникает ICE

Так я это и предлагал сделать — определить в каком месте компилеру йок наступает, а дальше
уже будет видно в какую сторону копать.

	От:	Кодт
Дата:	14.10.08 07:35
Оценка:

Здравствуйте, eklmn, Вы писали:

E>Здравствуйте, Кодт, Вы писали:

К>>Здравствуйте, eklmn, Вы писали:

E>>>3. найти телепата, кот. по ошибке компилятора определяет в какой строке и какая ошибка.

К>>Несерьёзно. Когда наступает ICE, компилятор сообщает, в какой строке ЕГО исходников произошла ошибка.

E>И? Что это дает?
E>Потом, msvc далеко не всегда на свои internal error выдает где именно ему поплохело.

Именно это я и имел в виду.
Ай пардон пардон, только сейчас понял, что твой совет найти телепата — не риторический, а практический. Извини.

	От:	Кодт
Дата:	14.10.08 08:22
Оценка:

Здравствуйте, , Вы писали:

А>А может помочь разбиение проекта на отдельные, слабо связанные cpp файлы?
А>Сейчас проект — это один cpp с множемтвом включенных хидеров.

Как минимум, ты изолируешь проблему.
Если у тебя сто хедеров, и в одном из них код-убийца, то ты замучаешься его выявлять.
А если сто единиц компиляции — то увидишь, в каком (или в каких) оно срывается с резьбы, и по пересечению найдёшь преступника.

	От:	Аноним
Дата:	14.10.08 08:30
Оценка:

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, , Вы писали:

А>>А может помочь разбиение проекта на отдельные, слабо связанные cpp файлы?
А>>Сейчас проект — это один cpp с множемтвом включенных хидеров.

К>Как минимум, ты изолируешь проблему.
К>Если у тебя сто хедеров, и в одном из них код-убийца, то ты замучаешься его выявлять.
К>А если сто единиц компиляции — то увидишь, в каком (или в каких) оно срывается с резьбы, и по пересечению найдёшь преступника.

Мои эксперименты показали что там проблема именно с большим к-вом инстанцирований шаблонов. Задизейбливал отельные ветки и смотрел на результат. Таким образом выяснил что все ветки проходимы. Все вместе переполняют компилятор.

	От:	Кодт
Дата:	14.10.08 09:28
Оценка:

Здравствуйте, , Вы писали:

А>Мои эксперименты показали что там проблема именно с большим к-вом инстанцирований шаблонов. Задизейбливал отельные ветки и смотрел на результат. Таким образом выяснил что все ветки проходимы. Все вместе переполняют компилятор.

Прекрасно. Раз бесконечности нет, значит, нужно бороться не с логической ошибкой, а с архитектурной.
Как-то поизбавляться от лишних вещей.

Может быть, использовать альтернативные средства. Скажем, если у тебя некий DSL, реализуемый на шаблонах — попробуй реализовать его на кодогенераторе.
То есть, у тебя будут отдельные исходники на этом языке, и средство трансляции его в C++. Примеры — MIDL, Yacc и т.п.
Транслятор можно написать на каком-нибудь скриптовом языке, например, на питоне или руби.
А кстати, и DSL можно прямо в скрипт встроить чтобы исходники были сами-себе-генераторами.

Источник

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

Closed

ohmtech-rdi opened this issue

Apr 12, 2016

· 8 comments

Comments

Hi,

I have a problem when trying to build my project with Visual Studio 2015.

Description

I’m using MSBuild 14.0 and the 2015 compiler and encounter the following error :

 fatal error C1060: compiler is out of heap space

quite randomly.
After that, random errors like the following will appear, but the one described upper is always the first one.

fatal error C1090: PDB API call failed, error code '24':
Internal Compiler Error in C:Program Files (x86)Microsoft Visual Studio 14.0VCbinamd64_x86CL.exe.
cl : Command line error D8040: error creating or communicating with child process

Using MSBuild 12.0 and the 2013 compiler on the same build worker image is running perfectly.

The visual 2013 & 2015 solutions are generated using gyp.

The project itself is on GitHub and is private, so I can’t share here the code I’m using. But I don’t think this is a big issue for the following reasons :

It’s C++ code, it is quite modern C++ but not heavily templatized
I can reproduce the error on a local VM with interesting results described below

Findings

I can reproduce the problem on a local VM I have set up with Windows 10 and Visual 2015. If I set the VM memory to 4 GB (the same as the build worker image), then it will show the same behaviour.
Also I know it does not come from the C++ code itself, as I can run MSBuild several times and after some point (at most 3 consecutive builds) have my project correctly built and linked.

The behaviour upper is the same with update 1 or update 2 of MSVS2015.

I’m not using precompiled headers (this is what shows up mostly when searching for this error on google/stackoverflow)

Question

I’m quite surprised as it seems I’m the only one facing this error. But maybe others found a working and acceptable workaround for this problem?

Any information on that matter would be greatly appreciated.

Thanks,

Raphael

I used to see this error when compiling some .cpp files that, when including many header files, would become very large. Essentially, the compiler is running out of memory trying to allocate space for your very large file.

https://msdn.microsoft.com/en-us/library/yz7kx3y2(v=vs.140).aspx

Sometimes, this issue would occur on one developer’s PC, but not others. But when it did occur on a PC, it was quite consistent.

To fix, one option that worked for me was to split the very large .cpp file into multiple files. But this did not always work.

Other times, I was able to solve this problem by using the /Zm compiler option to set/increase the memory limit.

Hi,

First, thanks for your answer.

My .cpp files are quite small (38 KB for the biggest, almost all others are below 20 KB), and my headers use forward declaration extensively.

However, since I’m testing the library with a configuration matrix, I end up with quite a number of projects in the solution (with different precompiler flags), and I guess the total number of files to compile might be around 1500. Each project has around 100 code unit .cpp files.

Reading the /Zm documentation :
https://msdn.microsoft.com/en-us/library/bdscwf1c.aspx
says that it is used to «Determines the amount of memory that the compiler allocates to construct precompiled headers»

I’m not using precompiled headers. Do you think that the documentation is actually faulty and there is an influence even in the case where I wouldn’t be using precompiled headers? (or an misunderstanding of me of what could be precompiled headers in that context?)

My experience is that the issue occurs (and is fixed) regardless of precompiled header use. So give it a try (wouldn’t hurt). I was able to do /Zm100 and it solved my issue. Also, my understanding is that the memory allocation is a per-file thing, not a per-project thing. So it’s the size of an individual .cpp file.

We see this issue often and it’s intermittent. We usually see it in the middle of a full rebuild. I believe it’s intermittent because multiple files may be passed on the command line at once due to a multiprocessor build.

We’ve found adding RAM and increasing virtual memory seems to help diminish this issue.

@mwhouser Thanks for your advice. Meantime I’ve tried with /Zm100, /Zm200 and /Zm10 and it seems that the latter «makes it work». I’m not super confident, as I don’t understand what I’m doing, and the MSDN documentation is completely misleading on this one.

@kelleyma49 Yes, this is exactly what I was seeing. Usually it would always fail around the 500th code unit. I can’t increase the RAM of the VM myself as I’m running on the AppVeyor CI system.

@mwhouser Ah no actually it’s not working reliably. Relaunched the same build to test and it had the same issue.

Thanks everyone for your input. It helped to understand more the problem, and we found a solution, that I’m going to expose here, as it was a misuse of MSBuild/CL arguments, that could go unnoticed on a typical developer workstation but will most probably makes problem on a limited memory VM configuration.

We are creating on the fly a MSVS solution using gyp. Then we use MSBuild to build the solution.

We were using the compiler option /MP for the solution as well as the argument /maxcpucount for MSBuild.
In this configuration, and on AppVeyor VM, MSBuild will «fork» 4 times and CL will also «fork» 4 times, resulting in 16 compilers running in parallel. Some code units require more heap memory than others, and so we could run in the situation where we would exhaust the available memory as each compiler process have on average a bit less than 200 MB to run.

Removing /maxcpucount or /MP solves the problem.
As far as build time is concerned, it seems that keeping /maxcpucount and removing /MP gives better overall build duration (The time fluctuation is small enough to be considered not significant though, and could be related to overall AppVeyor platform charge).

As a matter of fact, this behaviour is described in details on a MSDN page here :
https://msdn.microsoft.com/en-us/library/bb385193.aspx
(bottom of the page, in the «The MSBUILD.exe Tool» section)

Thanks,

Raphael

Thanks for sharing the solution!

Источник

Remove From My Forums

Question
Hi,

I am currently testing VS2013 Pro in a virtual machine. My native C++ / MFC application compiles perfectly in release mode.

However, when I build for Code Analysis (‘Analyze’ —> ‘Run Code Analysis on Solution’) the compiler crashes (after a long ‘building’ time) with:

1> Running Code Analysis for C/C++…
1>C:Program Files (x86)Microsoft Visual Studio 12.0VCincludexlocale(1654): fatal error C1060: compiler is out of heap space
1>c1xxast : fatal error C1001: An internal error has occurred in the compiler.
1> (compiler file ‘msc1ast.cpp’, line 1325)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1> Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information

Is there a way to fix this (which doesn’t involve rewriting my own code, which surely is ‘OK’ if it compiles in normal release or debug mode)? Otherwise, the Code Analysis feature is of very little use really, which is a shame as it provides one big
reason for me to upgrade from VS2010.

My application may not be the best written C++ but it’s actually not that big!

Suggestions welcome! Thanks!

Pete

Creator of the Software Update Wizard… add update over the web to your app with a single line of code!

Answers

OP here.

Here is a solution that worked for me.

I switched off Precompiled Headers on the Property Pages —> Configuration —> C/C++ settings sheet and retried.

I read here that Precompiled Headers use heap memory:

http://msdn.microsoft.com/en-gb/library/bdscwf1c.aspx

Not using them thankfully allowed my code checking compilation to run to completion without running out of heap space.

I’m not sure this would be the solution to all instances of this issue, and in my opinion it surely is an issue with VS2013?

Pete

Creator of the Software Update Wizard… add update over the web to your app with a single line of code!
- Marked as answer by
  
  Friday, October 10, 2014 1:41 PM

Источник

    template<int current_level, typename... T> static int func(HMODULE h, const char *fname, const std::vector<three_values> &parameters, T... args) {
        long int count = (long int)parameters[0];
        if (((std::string)parameters[current_level].type).find("Пустота") == 0 || ((std::string)parameters[current_level].type).find("Универ") == 0) {
            if (count > current_level) {
                if (current_level <= 10) {
                    return func<current_level + 1, T..., int>(h, fname, parameters, args..., (int)parameters[current_level]);
                }
                else {
                    return 0;
                }
            }
            return ((int (*)(T..., int))GetProcAddress(h, fname))(args... , (int)parameters[current_level]);
        }
        else if (((std::string)parameters[current_level].type).find("Число") == 0) {
            if (count > current_level) {
                if (current_level <= 10) {
                    return func<current_level + 1, T..., double>(h, fname, parameters, args..., (double)parameters[current_level]);
                }
                else {
                    return 0;
                }
            }
            return ((int (*)(T..., double))GetProcAddress(h, fname))(args..., (double)parameters[current_level]);
        }
        else if (((std::string)parameters[current_level].type).find("Целое") == 0) {
            if (count > current_level) {
                if (current_level <= 10) {
                    return func<current_level + 1, T..., long int>(h, fname, parameters, args..., (long int)parameters[current_level]);
                }
                else {
                    return 0;
                }
            }
            return ((int (*)(T..., long int))GetProcAddress(h, fname))(args..., (long int)parameters[current_level]);
        }
        else if (((std::string)parameters[current_level].type).find("Целое без знака") == 0) {
            if (count > current_level) {
                if (current_level <= 10) {
                    return func<current_level + 1, T..., unsigned long int>(h, fname, parameters, args..., (unsigned long int)parameters[current_level]);
                }
                else {
                    return 0;
                }
            }
            return ((int (*)(T..., unsigned long int))GetProcAddress(h, fname))(args..., (unsigned long int)parameters[current_level]);
        }
        else if (((std::string)parameters[current_level].type).find("Строка") == 0 || ((std::string)parameters[current_level].type).find("Короткая строка") == 0) {
            if (count > current_level) {
                if (current_level <= 10) {
                    return func<current_level + 1, T..., const char *>(h, fname, parameters, args..., (const char *)parameters[current_level]);
                }
                else {
                    return 0;
                }
            }
            return ((int (*)(T..., const char *))GetProcAddress(h, fname))(args..., (const char *)parameters[current_level]);
        }
        else {
            if (count > current_level) {
                if (current_level <= 10) {
                    return func<current_level + 1, T..., int>(h, fname, parameters, args..., (int)parameters[current_level]);
                }
                else {
                    return 0;
                }
            }
            return ((int (*)(T..., int))GetProcAddress(h, fname))(args..., (int)parameters[current_level]);
        }
        return 0;
    }
 
    static int func(HMODULE h, const char *fname, const std::vector<three_values> &parameters) {
        long int count = (long int)parameters[0];
        if (count > 0) {
            if (((std::string)parameters[1].type).find("Пустота") == 0 || ((std::string)parameters[1].type).find("Универ") == 0) {
                if (count > 1) {
                    return func<2, int>(h, fname, parameters, (int)parameters[1]);
                }
                return ((int (*)(int))GetProcAddress(h, fname))((int)parameters[1]);
            }
            else if (((std::string)parameters[1].type).find("Число") == 0) {
                if (count > 1) {
                    return func<2, double>(h, fname, parameters, (double)parameters[1]);
                }
                return ((int (*)(double))GetProcAddress(h, fname))((double)parameters[1]);
            }
            else if (((std::string)parameters[1].type).find("Целое") == 0) {
                if (count > 1) {
                    return func<2, long int>(h, fname, parameters, (long int)parameters[1]);
                }
                return ((int (*)(long int))GetProcAddress(h, fname))((long int)parameters[1]);
            }
            else if (((std::string)parameters[1].type).find("Целое без знака") == 0) {
                if (count > 1) {
                    return func<2, unsigned long int>(h, fname, parameters, (unsigned long int)parameters[1]);
                }
                return ((int (*)(unsigned long int))GetProcAddress(h, fname))((unsigned long int)parameters[1]);
            }
            else if (((std::string)parameters[1].type).find("Строка") == 0 || ((std::string)parameters[1].type).find("Короткая строка") == 0) {
                if (count > 1) {
                    return func<2, const char *>(h, fname, parameters, (const char *)parameters[1]);
                }
                return ((int (*)(const char *))GetProcAddress(h, fname))((const char *)parameters[1]);
            }
            else {
                if (count > 1) {
                    return func<2, int>(h, fname, parameters, (int)parameters[1]);
                }
                return ((int (*)(int))GetProcAddress(h, fname))((int)parameters[1]);
            }
        }
        return ((int (*)())GetProcAddress(h, fname))();
    }

Источник

Fatal error c1060 компилятору не хватает размера кучи

<img decoding="async" onError="javascript: wp_broken_images = window.wp_broken_images || function(){}; wp_broken_images(this);" src="https://i1.social.s-msft.com/globalresources/Images/trans.gif" />

Asked by:

Question

Fatal error c1060 компилятору не хватает размера кучи

Вопрос:

Комментарии:

Fatal error c1060 компилятору не хватает размера кучи

Comments

Description

Findings

Question

Question

Answers

Читайте также: