Fatal error c1060 compiler is out of heap space - Исправление ошибок и поиск оптимальных решений проблем

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

Источник

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!

Источник

Содержание

Fatal error c1060 компилятору не хватает размера кучи
Asked by:
Question
All replies
Fatal error c1060 компилятору не хватает размера кучи
Вопрос:
Комментарии:
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 можно прямо в скрипт встроить чтобы исходники были сами-себе-генераторами.

Источник

This topic has been deleted. Only users with topic management privileges can see it.

I’ve been porting quite a large project developed originally with Qt 4.8 and I’m and updating it for Qt 5.8. I’ve fixed all the warnings and errors so far.

There is now only one issue remaining or at least thats all I see:

Issues Panel contains:

C:Usersu49100DocumentsprojectNamebuild-projectName-Desktop_Qt_5_8_0_MSVC2013_32bit-Debugdebugqrc_qresources.cpp:1326934: error: C1060: compiler is out of heap space

In the Compiler Output panel:

debugqrc_qresources.cpp(1326934) : fatal error C1060: compiler is out of heap space
jom: C:Usersu49100DocumentsprojectNamebuild-projectName-Desktop_Qt_5_8_0_MSVC2013_32bit-DebugMakefile.Debug [debugqrc_qresources.obj] Error 2

I have no clue what the reason for this is and I’ve tried google but no further forward.

@SPlatten said in qrc_resources.cpp fatal error C1060: compiler is out of heap space:

I’ve never done this before, is it simply a case of copying chunks of the file and adding another .qrc file with the content?

Yes, exactly, a simple copy-paste. Or rather, cut-paste.

Try to split your resources into separate, smaller files. Compiling QRC consumes vast amounts of RAM etc. so it’s quite easy to run into memory problems.

Your Qt app won’t notice any difference — QRC paths inside of app stay the same, regardless of how many real concrete QRC files are used.

I’ve never done this before, is it simply a case of copying chunks of the file and adding another .qrc file with the content?

@SPlatten said in qrc_resources.cpp fatal error C1060: compiler is out of heap space:

I’ve never done this before, is it simply a case of copying chunks of the file and adding another .qrc file with the content?

Yes, exactly, a simple copy-paste. Or rather, cut-paste.

Hi,

Out of curiosity, how many resources do you have in the original file ?

The original XML file contains 548 lines.
358 of these are images.
5 are JavaScript files
The rest are QML files and fonts.

Having split the original resource into 3 files, it stills come back with the same error on the last file which contains all the QML files.

And now I’m also getting:

  C1063: INTERNAL COMPILER ERROR      c1xx

@SPlatten you have to rerun qmake after adding new resource files or when you edited a resource file

@J-Hilk, Done that, still a problem.

Thats weird! I’ve had memory issues in QRC with images, but with QML code — never. Something else must be causing the problem here.

2 things to try:

run in single-job mode (no -j 8 or /MP, no jom.exe or whatever — sorry I’m not too Windowsy :P). This should be a bit lighter on memory
try to add QML files one by one — maybe one specific QML file causes this? Maybe it contains some data which triggers the error?

Thanks, waiting for the current build to finish, if its still an issue I will take your advice.

Ok the error has changed again, now:

C1001: An internal error has occurred in the compiler.

And it stopped on the resource file that contains files that I don’t think are relevant:

<RCC>
<qresource prefix="/">
<file>distribution_support/qt.conf</file>
<file>sortexS_tr.ts</file>
<file>sortexS_th.ts</file>
<file>sortexS_es.ts</file>
<file>sortexS_en.ts</file>
<file>sortexS_ru.ts</file>
<file>sortexS_fr.ts</file>
<file>sortexS_it.ts</file>
<file>sortexS_vi.ts</file>
<file>sortexS_pt.ts</file>
<file>sortexS_kr.ts</file>
<file>sortexS_xx.ts</file>
<file>sortexS_xy.ts</file>
<file>malgun.ttf</file>
<file>runui.bat</file>
</qresource>
</RCC>

How heavy are these images ?
How big is these files ?

@SGaist Hi, sorry can you explain by heavy to you mean how big are the file size’s? They are all quite small, typical icon size’s and mostly png’s.

Yes, I meant their size.

@SGaist , The dimensions of the images again are icon sizes’s so all quite small, they’re is just a lot of them.

Ok, so nothing really unusual. How big are the generated cpp files ?

Total six of the project folder excluding objects and executable is 28MB, 882 Files.

Sorry, I meant the cpp files generated by rcc.

@SPlatten Hi, it’s too late but, maybe adding

CONFIG += resources_big

fixes the problem

Источник

Re[10]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 15:59

Оценка:

-2
:)))

E>>Я так понял, такая беда стряслась недавно, раньше всё как-то влезало…
BFE>Я думаю, что всё намного проще. Под лозунгом «один хеадер на всех, сэр!», в win32_fabric.hpp собраны все хедеры всего проекта…

Нафантазировали вы конечно здесь знатно, но ваше бессилие: <так не может быть>, <что то намутили>, <все срочно переписать с нуля> меня реально посмешило.

fatal error C1060: compiler is out of heap space

От:

Дата:

23.01.16 09:55

Оценка:

1 (1)
:)))

Compiler: VC++2008 x32
Target Platform: Win32
Source Platform: Win64

Компилятор выжирает свои максимально доступные 4GB памяти и падает. Источник проблемы большая фабрика классов которая позволяет создавать ~200 объектов (не ожидал что такой низкий порог чтобы завалить компилятор ) поэтому включает в себя много хедеров.
Опции (/bigobj /Zm2000) в частности /Zm2000 не помогает.
Можно конечно разбить эту фабрику на несколько фабрик но это последнее решение (так как создает дополнительные неудобства в использовании).

Возможно есть еще какой то волшебный

~~пендаль~~

опция компилятору?

Re[20]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 12:27

Оценка:

-2
:))

E>Опять не понятно. Пользователю доступен интерфейс этой фабрики или нет? Если доступен, то почему у него проблем не будет, а у вас они есть?
E>Если не доступен, то зачем вам вообще этот всемогутер понадобился?

Ты вообще понимаешь разницу между интерфейсом и его реализацией которая под капотом?
P.S. COM библиотека может использоваться например из Visual Basic и там никаких С++ классов юзер вообще не увидит, а только COM-интерфейсы.

Re[26]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 14:48

Оценка:

:)))

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

R>Да??? А не один метод, позводяющий создать объект по имени или CLSID?

Так тока лохи пишут!

Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно «ради красного словца». За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском

Re[9]: fatal error C1060: compiler is out of heap space

	От:	B0FEE664
Дата:	25.01.16 15:14
	Оценка:	+2

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

BFE>>Тогда всё это выглядит крайне подозрительно. Так не бывает.
E>Бывает. Если они, например, сделали cpp, который зависит от всех или почти всех хедеров в большой-пребольшой системе. Ну и ещё с шаблонами, которые стандартизованные, наверное чего-то намутили, то всё возможно…
Именно, что что-то намутили, а не так просто.

E>ТС там что-то писал, про хедер фабрики, который зависит от хедеров содержащих описания 200 классов, некоторые из которых, в свою очередь, зависят от хедеров, содержащих описания 500 классов…
А так подозреваю, что для кода:

HRESULT win32_fabric::create_myobj(
   //[out,retval] 
   IMyObject** result
)

в декларации, в .hpp, перед классом win32_fabric, вместо строчки

class IMyObject

; у них стоит даже не честный

#include «IMyObject.hpp»

, а полный

#include «CMyObject.hpp»

E>Ещё может так быть, что какие-то хедеры много раз включаются, и где-то } не закрыта, так что получается такой бесконечно вложенный nested класс…
E>Я так понял, такая беда стряслась недавно, раньше всё как-то влезало…
Я думаю, что всё намного проще. Под лозунгом «один хеадер на всех, сэр!», в win32_fabric.hpp собраны все хедеры всего проекта…

И каждый день — без права на ошибку…

Re[11]: fatal error C1060: compiler is out of heap space

	От:	B0FEE664
Дата:	25.01.16 17:35
	Оценка:	+3

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

E>>>Я так понял, такая беда стряслась недавно, раньше всё как-то влезало…
BFE>>Я думаю, что всё намного проще. Под лозунгом «один хеадер на всех, сэр!», в win32_fabric.hpp собраны все хедеры всего проекта…
UA>Нафантазировали вы конечно здесь знатно, но ваше бессилие:
Так это у нас код не собирается?

UA> <так не может быть>, <что то намутили>, <все срочно переписать с нуля> меня реально посмешило.

Я могу разве что добавить только своё любимое заклинание: «здесь вы видите то, чего не бывает!».

PS Информации не достаточно, вот и получается «лечение по фотографии». Разумеется я вполне допускаю, что вы уткнулись в пределы компилятора, но если вы скажете, что данная проблема не решается разбиением кода по файлам — не поверю. Вот если бы у вас линковщик падал, то тогда, можно было бы сказать — всё, приплыли. А так — реорганизация кода решает. Даже переписывать не надо.

И каждый день — без права на ошибку…

Re[7]: fatal error C1060: compiler is out of heap space

	От:	B0FEE664
Дата:	25.01.16 13:22
	Оценка:	+1

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

BFE>>А макросов разбирающих списки аргументов?
UA>Нету.
Тогда всё это выглядит крайне подозрительно. Так не бывает.

И каждый день — без права на ошибку…

Re[10]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 16:07

Оценка:

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

UA>Ты думаешь такое сейчас реально? Все фэйловые коммиты я просмотрел.

Я, в принципе, написал тут везде всё, что думаю…
Ты поясни зачем вам
1) 200 методов, а не 200 функций с мапом из ClassId?
2) Повышение связности в реализации интерфейса фабрики, по сравнению с его хедером?
Я думаю, что корень зла где-то там…

Re[11]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 16:09

Оценка:

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

UA>Нафантазировали вы конечно здесь знатно, но ваше бессилие: <так не может быть>, <что то намутили>, <все срочно переписать с нуля> меня реально посмешило.

Ты, если хочешь помощи, лучше на вопросы ответь…
Когда заработает — вместе посмеёмся…

Кстати, а зачем всё переписывать? Я, например, если правильно понимаю, как оно у вас устроено, предлагаю довольно таки формальные и простые правки…

Re[4]: fatal error C1060: compiler is out of heap space

От:

Дата:

08.02.16 15:13

Оценка:

1 (1)

LVV>Я в одной и той же студии 2012 одну и ту же прогу компилирую и как 32, и как 64.
LVV>Обе работают.
LVV>Я что-то делаю не так?

32 битный компилятор может собирать под x32 и под x64, а вот 64 битный только под x64

Re[6]: fatal error C1060: compiler is out of heap space

От:

Дата:

24.01.16 18:51

Оценка:

S>А промежуточные величины?
Сборка идет пару часов — на столько у меня терпения не хватит.

Re[17]: fatal error C1060: compiler is out of heap space

От:

rg45

Дата:

25.01.16 09:47

Оценка:

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

UA>Можно его разбить на несколько файлов — но это как я говорил последнее решение, пока что делаю оптимизацию заголовков.

Возможно, будет полезно сперва определить наиболее проблемные заголовки, вместо того, чтобы лопатить все 200. Вполне вероятно, исключение всего нескольких таких заголовков устраняет проблему. Искать проще всего дихотомией.

—
Завтра сегодня будет вчера

Re: fatal error C1060: compiler is out of heap space

	От:	B0FEE664
Дата:	25.01.16 11:36
	Оценка:	+1

И каждый день — без права на ошибку…

Re[5]: fatal error C1060: compiler is out of heap space

	От:	B0FEE664
Дата:	25.01.16 13:00
	Оценка:	+1

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

E>>А продвинутых шаблонов?
UA>Шаблоны все стандартизированы и их уже давно никто не менял.

А макросов разбирающих списки аргументов?

И каждый день — без права на ошибку…

Re[12]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 14:47

Оценка:

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

BFE>То, что это не глобальные функции ничего не меняет. Совет тот же — компилировать эти функции в разных *.cpp файлах.

Я так понял, что неподъёмные зависимости уже в хедере есть.

Re[12]: fatal error C1060: compiler is out of heap space

От:

Дата:

04.02.16 08:42

Оценка:

BFE>но если вы скажете, что данная проблема не решается разбиением кода по файлам — не поверю.
Не решается, потому что в древовидной архитектуре все равно есть место (уровнем выше) где эти разбиенные файлы встречаются вместе.
Пока что ясно что превышен лимит на обьявления типа CComObject<XXX>::CreateInstance (таких объявлений больше полутора тысяч), где CComObject шаблон типа

template <class Base>
class CComObject : public Base

И находятся эти объявления далеко не в Global Space.
Отключил пару сотен таких объявлений и все заработало — фантастика. Но все равно нужно думать как облегчить жизнь компилеру потому что рано или поздно эти объявления все равно понадобятся.

BFE>Вот если бы у вас линковщик падал, то тогда, можно было бы сказать — всё, приплыли. А так — реорганизация кода решает. Даже переписывать не надо.
И снова ты не прав, линкер рухнул первым по out of memory и почему то на границе 3GB (три!!! не четыре — возможно баг MS-а), но опция /OPT:NOREF пока помогает сбавить темп использования памяти линкером до 2.5GB.

Re[5]: fatal error C1060: compiler is out of heap space

	От:	_NN_	www.nemerleweb.com
Дата:	04.02.16 13:58
	Оценка:	+1

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

_NN>>Я так понимаю, что если я создам 200 таких классов в одном cpp файле , то компилятор должен вылететь ?
UA>Выходит типа того. Фабрика подтягивает все определения, но 200 это только на самом верхнем уровне, а всего по библиотеке наберется тысячи полторы.

Итак я создал 200 классов такого рода и компилятор съел без проблем.
Мне кажется что-то вы недоговариваете.

Re[2]: fatal error C1060: compiler is out of heap space

От:

Дата:

04.02.16 18:25

Оценка:

С>1) Попробовать intel compiler
С>2) Попробовать gcc

Это очень крайний выход.

С>3) Взять 64битный компилятор и арендовать сервер с 128гб оперативки.

Не знаю как другие, но MS-овский 64битный компилятор не умеет компилировать под Win32, а только под Win64.

Re[17]: fatal error C1060: compiler is out of heap space

	От:	_NN_	www.nemerleweb.com
Дата:	07.02.16 05:42
	Оценка:	+1

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

Мне всё же не ясно зачем подключать все заголовочные файлы в один cpp ?
ATL этого не требует.

Re[20]: fatal error C1060: compiler is out of heap space

От:

Дата:

08.02.16 10:21

Оценка:

UA>>CreateInstance требует.
_NN>Что значит требует ?
_NN>Поясните примером кода что ли.

Вынес CreateInstanc-ы в Global Space и теперь начало компилироваться без проблем. Куча работы только для того чтобы компилятор смог проглотить большой кусок пирога (оптимизировать сам не может), ужасно это все.

Re: fatal error C1060: compiler is out of heap space

От:

rg45

Дата:

23.01.16 10:15

Оценка:

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

UA>Компилятор выжирает свои максимально доступные 4GB памяти и падает. Источник проблемы большая фабрика классов которая позволяет создавать ~200 объектов (не ожидал что такой низкий порог чтобы завалить компилятор ) поэтому включает в себя много хедеров.

Ну так если проблема уже установлена, то почему бы в этой большой фабрике, вместо прямого конструирования, не использовать просто набор элементарных функций-фабрик, разнесенных по разным единицам трансляции? Тогда отпадает необходимось собирать все заголовки в одну кучу и, таким образом, ограничение на количество классов снимается вовсе.

—
Завтра сегодня будет вчера

Re[2]: fatal error C1060: compiler is out of heap space

От:

Дата:

23.01.16 10:21

Оценка:

R>Ну так если проблема уже установлена, то почему бы в этой большой фабрике, вместо прямого конструирования, не использовать просто набор элементарных функций-фабрик, разнесенных по разным единицам трансляции? Тогда отпадает необходимось собирать все заголовки в одну кучу и, таким образом, ограничение на количество классов снимается вовсе.

Можно пример? Мне кажется что кучи заголовков все равно не избежать.

Re[3]: fatal error C1060: compiler is out of heap space

От:

rg45

Дата:

23.01.16 10:40

Оценка:

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

R>>Ну так если проблема уже установлена, то почему бы в этой большой фабрике, вместо прямого конструирования, не использовать просто набор элементарных функций-фабрик, разнесенных по разным единицам трансляции? Тогда отпадает необходимось собирать все заголовки в одну кучу и, таким образом, ограничение на количество классов снимается вовсе.
UA>Можно пример? Мне кажется что кучи заголовков все равно не избежать.

Куча заголовков будет, но не в одном месте. Конкретных реализаций, разной степени вычурности, можно придумать множество. Самый «деревянный» может выглядеть примерно так:

// TheBigFactory.cpp

// Trivial object factories declarations
IMyObjectPtr CreateObject1();
IMyObjectPtr CreateObject2();
IMyObjectPtr CreateObject3();

TheBigFactory::TheBigFactory()
{
  m_factoriesByID[1] = &CreateObject1;
  m_factoriesByID[2] = &CreateObject2;
  m_factoriesByID[3] = &CreateObject3;
}

IMyObjectPtr TheBigFactory::CreateObjectByID(ID id)
{
  // cheking the id is valid, error handing
  . . . 
  return m_factoriesByID[id]();
}

// MyObject1.cpp
#include "MyObject1.h"

// MyObject1 members defitions
 . . .

IMyObjectPtr CreateObject1()
{
  return IMyObjectPtr(new MyObject1());
}

—
Завтра сегодня будет вчера

Re: fatal error C1060: compiler is out of heap space

	От:	swingus
Дата:	24.01.16 09:58
	Оценка:

Можно попробовать не только увеличивать, но и уменьшать значение опции /Zm

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

UA>Compiler: VC++2008 x32
UA>Target Platform: Win32
UA>Source Platform: Win64

UA>Компилятор выжирает свои максимально доступные 4GB памяти и падает. Источник проблемы большая фабрика классов которая позволяет создавать ~200 объектов (не ожидал что такой низкий порог чтобы завалить компилятор ) поэтому включает в себя много хедеров.
UA>Опции (/bigobj /Zm2000) в частности /Zm2000 не помогает.
UA>Можно конечно разбить эту фабрику на несколько фабрик но это последнее решение (так как создает дополнительные неудобства в использовании).

UA>Возможно есть еще какой то волшебный ~~пендаль~~ опция компилятору?

Re[2]: fatal error C1060: compiler is out of heap space

От:

Дата:

24.01.16 10:58

Оценка:

S>Можно попробовать не только увеличивать, но и уменьшать значение опции /Zm
В чем логика?

Re[3]: fatal error C1060: compiler is out of heap space

	От:	swingus
Дата:	24.01.16 15:22
	Оценка:

1. Такой совет есть у Microsoft’а
2. У меня иногда срабатывало

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

S>>Можно попробовать не только увеличивать, но и уменьшать значение опции /Zm
UA>В чем логика?

Re[4]: fatal error C1060: compiler is out of heap space

От:

Дата:

24.01.16 17:35

Оценка:

S>1. Такой совет есть у Microsoft’а
S>2. У меня иногда срабатывало

Изначально было на минимуме — падает, поставил максимум — падает.

Re[5]: fatal error C1060: compiler is out of heap space

	От:	swingus
Дата:	24.01.16 18:42
	Оценка:

А промежуточные величины?

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

S>>1. Такой совет есть у Microsoft’а
S>>2. У меня иногда срабатывало

UA>Изначально было на минимуме — падает, поставил максимум — падает.

Re[7]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

24.01.16 20:03

Оценка:

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

UA>Сборка идет пару часов — на столько у меня терпения не хватит.

Одного cpp?

Ты можешь толком пояснить, как устроен интерфейс фабрики?..

Re[8]: fatal error C1060: compiler is out of heap space

От:

Дата:

24.01.16 21:00

Оценка:

Re[9]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

24.01.16 21:08

Оценка:

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

UA>Нет конечно. Но после fatal error компилятор начинает заново все пересобирать.

Можно собирать только проблемный cpp, а не весь проект…

E>>Ты можешь толком пояснить, как устроен интерфейс фабрики?..
UA>Фабрика набор обычных функций-строителей внутри которых вызовы:
UA>

UA>HRESULT win32_fabric::create_myobj(
UA>   //[out,retval] 
UA>   IMyObject** result
UA>)
UA>

То есть это 200 не связанных между собой функций?
От чего бы их в namespace не засунуть, а объявлять по частям…

Другое дело, что не похоже, что всего 200 таких функций достаточно, что бы обрушить восьмёрку.
Больше похоже на то, что у тебя там среди 200 типов есть такие, которые лучше не инстнциировать, а на этой помойке из 200 классов на них нарваться шансы вые, просто…

Re[10]: fatal error C1060: compiler is out of heap space

От:

Дата:

24.01.16 21:54

Оценка:

E>То есть это 200 не связанных между собой функций?
Да

E>От чего бы их в namespace не засунуть, а объявлять по частям…
это же не глобальные функции или я чего то не понял.

E>Другое дело, что не похоже, что всего 200 таких функций достаточно, что бы обрушить восьмёрку.
E>Больше похоже на то, что у тебя там среди 200 типов есть такие, которые лучше не инстнциировать, а на этой помойке из 200 классов на них нарваться шансы вые, просто…

Да есть тяжелые классы которые включают еще по 500, для них я сделал в фабрике forward declarations но что то совет rg45 не срабатывает — компилятор все равно цепляет эти классы компилировать в фабрике.
Только полное их отключение или частичное урезание их функциональности помогает скомпилировать библиотеку.

Re[11]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

24.01.16 21:59

Оценка:

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

UA>это же не глобальные функции или я чего то не понял.

у этой фабрики может быть несколько экземпляров?

UA>Только полное их отключение или частичное урезание их функциональности помогает скомпилировать библиотеку.
Что-то тут не так. А у пользователей те же проблемы будут?

Re[12]: fatal error C1060: compiler is out of heap space

От:

Дата:

24.01.16 22:15

Оценка:

E>у этой фабрики может быть несколько экземпляров?

          object -- sub_object1 (type: sub_object) -- fabric1 (type: fabric) (sigleton)
                 -- sub_object2 (type: sub_object) -- fabric2 (type: fabric) (sigleton)
                       ...           ...
                 -- sub_objectN (type: sub_object) -- fabricN (type: fabric) (sigleton)

В контексте sub_object-а, если фабрика создана то при попытке повторного создания вернется интерфейс на уже созданную фабрику со счетчиком ссылок +1
fabric1, fabric2 и fabricN между собой связи не имеют.

UA>>Только полное их отключение или частичное урезание их функциональности помогает скомпилировать библиотеку.
E>Что-то тут не так. А у пользователей те же проблемы будут?
Это ж не релиз, а рабочие эксперименты.

Re[10]: fatal error C1060: compiler is out of heap space

От:

rg45

Дата:

25.01.16 08:14

Оценка:

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

E>Другое дело, что не похоже, что всего 200 таких функций достаточно, что бы обрушить восьмёрку.

Как я понял, речь идет о подключении 200 хедеров в одну единицу трансляции, и тут уже все будет зависеть от тяжести этих заголовков. Есть подозрение, что над минимизацией заголовков никто там не заморачивался и они тянут за собой кучу «приданного», нужного и ненужного.

—
Завтра сегодня будет вчера

Re[11]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 08:33

Оценка:

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

R>Как я понял, речь идет о подключении 200 хедеров в одну единицу трансляции, и тут уже все будет зависеть от тяжести этих заголовков. Есть подозрение, что над минимизацией заголовков никто там не заморачивался и они тянут за собой кучу «приданного», нужного и ненужного.
Вот мне и интересно, юзверь этой библы тоже будет так страдать, или какой план?

Re[12]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 08:49

Оценка:

E>Вот мне и интересно, юзверь этой библы тоже будет так страдать, или какой план?
Отчего юзверю страдать? Для него все под капотом.

Re[13]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 08:59

Оценка:

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

E>>Вот мне и интересно, юзверь этой библы тоже будет так страдать, или какой план?
UA>Отчего юзверю страдать? Для него все под капотом.

Он эти 200 классов в одном месте и фабрику видит?

Re[14]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 09:06

Оценка:

E>Он эти 200 классов в одном месте и фабрику видит?
Нет конечно, наружу только COM-интерфейсы торчат.

Re[15]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 09:18

Оценка:

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

UA>Нет конечно, наружу только COM-интерфейсы торчат.

А может тогда и внутри этот супер-монстр не нужен?

Re[16]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 09:24

Оценка:

E>А может тогда и внутри этот супер-монстр не нужен?
Он же имплементирует COM-интерфейс. Можно его разбить на несколько файлов — но это как я говорил последнее решение, пока что делаю оптимизацию заголовков.

Re[17]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 09:27

Оценка:

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

UA>Он же имплементирует COM-интерфейс. Можно его разбить на несколько файлов — но это как я говорил последнее решение, пока что делаю оптимизацию заголовков.

Это 200 интерфейсов к одному объекту?

Re[18]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 09:45

Оценка:

UA>>Он же имплементирует COM-интерфейс. Можно его разбить на несколько файлов — но это как я говорил последнее решение, пока что делаю оптимизацию заголовков.
E>Это 200 интерфейсов к одному объекту?

Это же не просто объект, это фабрика.

Re[19]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 12:11

Оценка:

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

UA>Это же не просто объект, это фабрика.

Опять не понятно. Пользователю доступен интерфейс этой фабрики или нет? Если доступен, то почему у него проблем не будет, а у вас они есть?
Если не доступен, то зачем вам вообще этот всемогутер понадобился?

Re[2]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 12:20

Оценка:

BFE>У вас в хедерах случайно нет циклических зависимостей?
Нету.

Re[3]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 12:22

Оценка:

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

BFE>>У вас в хедерах случайно нет циклических зависимостей?
UA>Нету.

А продвинутых шаблонов?

Re[4]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 12:35

Оценка:

E>А продвинутых шаблонов?
Шаблоны все стандартизированы и их уже давно никто не менял.

Re[21]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 12:53

Оценка:

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

E>>Опять не понятно. Пользователю доступен интерфейс этой фабрики или нет? Если доступен, то почему у него проблем не будет, а у вас они есть?
E>>Если не доступен, то зачем вам вообще этот всемогутер понадобился?

UA>Ты вообще понимаешь разницу между интерфейсом и его реализацией которая под капотом?
UA>P.S. COM библиотека может использоваться например из Visual Basic и там никаких С++ классов юзер вообще не увидит, а только COM-интерфейсы.

1) Ты так и не сказал, видна ли фабрика со стороны пользователя. Если видна, и это так надо в интерфейсе этой библиотеки, то ок, но если не видна, то зачем она понадобилась по капотом? Какова цель её заведения? В чём выгода?

2) Если интерфейсы можно описать просто, то почему фабрику нельзя? Зачем ей в хедере нужно что-то кроме интерфейсов?

Re[22]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 13:07

Оценка:

E>1) Ты так и не сказал, видна ли фабрика со стороны пользователя. Если видна, и это так надо в интерфейсе этой библиотеки, то ок, но если не видна, то зачем она понадобилась по капотом? Какова цель её заведения? В чём выгода?
Фабрика видна в виде COM-интерфейса, ее реализация под капотом.

E>2) Если интерфейсы можно описать просто, то почему фабрику нельзя? Зачем ей в хедере нужно что-то кроме интерфейсов?
Фабрика наружу это и есть COM-интерфейс, но под капотом необходимо привязать интерфейс к реализации поэтому внутренняя фабрика должна сделать CreateInstanc-ы.

P.S. Текущая проблема вообще никак не касается юзера.

Re[6]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 13:09

Оценка:

BFE>А макросов разбирающих списки аргументов?
Нету.

Re[23]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 13:23

Оценка:

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

UA>Фабрика видна в виде COM-интерфейса, ее реализация под капотом.
То есть фабрика — это такой COM-объект, у которого есть примерно 200 функций «дай такой объект» и «дай сякой объект»? Так?

E>>2) Если интерфейсы можно описать просто, то почему фабрику нельзя? Зачем ей в хедере нужно что-то кроме интерфейсов?
UA>Фабрика наружу это и есть COM-интерфейс, но под капотом необходимо привязать интерфейс к реализации поэтому внутренняя фабрика должна сделать CreateInstanc-ы.

Ну у тебя же, как бы есть 200 методов, относительно независимых. Каждый плодит свой объект. Ну описываешь их в общем хедере, а реализации разносишь по разным cpp’шникам?

UA>P.S. Текущая проблема вообще никак не касается юзера.
Мне странно, что у юзера она гарантированно не возникает, а на вашем конце не только возникает, но и её трудно обойти…
Мне кажется, что у вас в коде есть ненужная очень избыточная связность… Или нужная, но в любом случае значительно большая, чем в интерфейсах.
Зачем она нужна? Какую проблему решает?

Re[11]: fatal error C1060: compiler is out of heap space

	От:	B0FEE664
Дата:	25.01.16 13:24
	Оценка:

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

E>>То есть это 200 не связанных между собой функций?
UA>Да

E>>От чего бы их в namespace не засунуть, а объявлять по частям…
namespace не нужен

UA>это же не глобальные функции или я чего то не понял.

То, что это не глобальные функции ничего не меняет. Совет тот же — компилировать эти функции в разных *.cpp файлах.

И каждый день — без права на ошибку…

Re[24]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 13:41

Оценка:

UA>>Фабрика видна в виде COM-интерфейса, ее реализация под капотом.
E>То есть фабрика — это такой COM-объект, у которого есть примерно 200 функций «дай такой объект» и «дай сякой объект»? Так?
Да.

E>Ну у тебя же, как бы есть 200 методов, относительно независимых. Каждый плодит свой объект. Ну описываешь их в общем хедере, а реализации разносишь по разным cpp’шникам?
Так и сделал но компилятор вместо того чтобы отложить все равно цепляет. Я так понимаю это для компилятора не приказ как компилировать, а скорее всего лишь рекомендация.

UA>>P.S. Текущая проблема вообще никак не касается юзера.
E>Мне странно, что у юзера она гарантированно не возникает, а на вашем конце не только возникает, но и её трудно обойти…
E>Мне кажется, что у вас в коде есть ненужная очень избыточная связность… Или нужная, но в любом случае значительно большая, чем в интерфейсах.
Оптимизацией связности и занимаюсь собственно.

Re[25]: fatal error C1060: compiler is out of heap space

От:

rg45

Дата:

25.01.16 14:25

Оценка:

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

E>>То есть фабрика — это такой COM-объект, у которого есть примерно 200 функций «дай такой объект» и «дай сякой объект»? Так?
UA>Да.

Да??? А не один метод, позводяющий создать объект по имени или CLSID?

—
Завтра сегодня будет вчера

Re[25]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 14:40

Оценка:

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

UA>>>Фабрика видна в виде COM-интерфейса, ее реализация под капотом.
E>>То есть фабрика — это такой COM-объект, у которого есть примерно 200 функций «дай такой объект» и «дай сякой объект»? Так?
UA>Да.

E>>Ну у тебя же, как бы есть 200 методов, относительно независимых. Каждый плодит свой объект. Ну описываешь их в общем хедере, а реализации разносишь по разным cpp’шникам?
UA>Так и сделал но компилятор вместо того чтобы отложить все равно цепляет. Я так понимаю это для компилятора не приказ как компилировать, а скорее всего лишь рекомендация.
Не понял, что цепляет? Зачем в хедере фабрики вообще видеть что-то, кроме интерфейсов?

UA>>>P.S. Текущая проблема вообще никак не касается юзера.
E>>Мне странно, что у юзера она гарантированно не возникает, а на вашем конце не только возникает, но и её трудно обойти…
E>>Мне кажется, что у вас в коде есть ненужная очень избыточная связность… Или нужная, но в любом случае значительно большая, чем в интерфейсах.
UA>Оптимизацией связности и занимаюсь собственно.

Для начала стоит ответить себе на вопрос, ради чего вообще эта связность понадобилась. Может тут не оптимизация нужна, а просто переделать так, что бы лишних связей не было в принципе?

Re[8]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 14:46

Оценка:

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

BFE>Тогда всё это выглядит крайне подозрительно. Так не бывает.
Бывает. Если они, например, сделали cpp, который зависит от всех или почти всех хедеров в большой-пребольшой системе. Ну и ещё с шаблонами, которые стандартизованные, наверное чего-то намутили, то всё возможно…

ТС там что-то писал, про хедер фабрики, который зависит от хедеров содержащих описания 200 классов, некоторые из которых, в свою очередь, зависят от хедеров, содержащих описания 500 классов…

Ещё может так быть, что какие-то хедеры много раз включаются, и где-то } не закрыта, так что получается такой бесконечно вложенный nested класс…
Я так понял, такая беда стряслась недавно, раньше всё как-то влезало…

Re[10]: fatal error C1060: compiler is out of heap space

От:

Erop

Дата:

25.01.16 15:27

Оценка:

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

BFE>в декларации, в .hpp, перед классом win32_fabric, вместо строчки class IMyObject; у них стоит даже не честный #include «IMyObject.hpp», а полный #include «CMyObject.hpp»

Вроде как ТС именно про это и написал. Только я так и не понял, зачем они так сделали… В чём выгода?

BFE>Я думаю, что всё намного проще. Под лозунгом «один хеадер на всех, сэр!», в win32_fabric.hpp собраны все хедеры всего проекта…
Я тоже так думаю. Но я не понимаю двух вещей.

1) Нафига у фабрики 200 методов? Можно же просто по ID класса IUNKNOWN* получать и кастить. Ну, на крайняк, можно завернуть это в 200 методов с кастом, тока не понятно на кой это надо всё. Если бы делал так, по-простому, то просто был бы какой-то класс-фабрика с инфраструктурой для аллокации ресурсов, и куча функций — генераторов объектов, которым на вход дают фабрику, на выходе IUNKNOWN*, и все их статическими регистраторами добавляют в какой-то мап из ID-класса в указатель на функцию… Никаких лишних связей, празитических хедеров и т. д…

2) Даже если им (1) не канает от чего-то, то почему не сделать всё тоже самое, но руками? Ну то есть написать эти 200 GetXXX в хедере, в котором объявлено 200 интерфейсов (в стиле struct IXXX; ), в объекте описать инфраструктуру для аллокации ресурсов, а функции разложить по 200 cpp-файлам?

Но у ребят какой-то сильно более связный путь выбран. ТС не говорит ни какой, ни зачем…
Загадочно это всё…

Re[9]: fatal error C1060: compiler is out of heap space

От:

Дата:

25.01.16 16:01

Оценка:

Ты думаешь такое сейчас реально? Все фэйловые коммиты я просмотрел.

Re: fatal error C1060: compiler is out of heap space

	От:	_NN_	www.nemerleweb.com
Дата:	04.02.16 11:22
	Оценка:

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

А нельзя сделать просто регистрацию и тогда фабрике не нужно ничего включать ?
Скажем

// SomeBase.h
class ISomeBase {}

// registration.h
#include "SomeBase.h"

// Необязательно именно так глобально, можно более деликатно но идея думаю ясна
using FactoryMethod = std::function<std::unqiue_ptr<ISomeBase>();
extern std::unordered_map<IID, FactoryMethod> globalmap;

class RegisterMe
{
  RegisterMe(IID iid, FactoryMethod factory) { globalMap[iid] = factory; }
};

// registration.cpp
#include "registration.h"
std::unordered_map<IID, std::function<std::unqiue_ptr<ISomeBase>()> globalmap;

// a.h
class A : ISomeBase
{
 ... 
}

// a.cpp
#include "a.h"

// Можно завернуть в макрос или даже автоматом через наследование (на форуме полно разных вариантнов есть)
static RegisterMe register(IID_IA, [](){return make_unique<A>();});

// b.h
class B
{
}

// b.cpp
#include "b.h"

static RegisterMe register(IID_IB, [](){return make_unique<B>();});

// factory.h
#include "SomeBase.h"

std::unqiue_ptr<ISomeBase> Create(IID iid);

// factory.cpp
#include "factory.h"
#include "registration.h"

std::unqiue_ptr<ISomeBase> Create(IID iid)
{
 return globalmap[iid](); 
}

Итого фабрика вообще не знает ничего про реализацию.
Легко добавить новый класс без необходимости менять код фабрики.

Re[2]: fatal error C1060: compiler is out of heap space

От:

Дата:

04.02.16 12:18

Оценка:

_NN>А нельзя сделать просто регистрацию и тогда фабрике не нужно ничего включать ?

Самодеятельность мне не подходит потому что используется ATL обертка для поддержки (dispatches, thread models, connection points, extend interfaces), а там нужно следовать определенным правилам как например в этом примере.

Re[3]: fatal error C1060: compiler is out of heap space

	От:	_NN_	www.nemerleweb.com
Дата:	04.02.16 13:15
	Оценка:

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

_NN>>А нельзя сделать просто регистрацию и тогда фабрике не нужно ничего включать ?

UA>Самодеятельность мне не подходит потому что используется ATL обертка для поддержки (dispatches, thread models, connection points, extend interfaces), а там нужно следовать определенным правилам как например в этом примере.

А фабрика тогда при чём ?
Приведите полную картину что ли.

Я так понимаю, что если я создам 200 таких классов в одном cpp файле , то компилятор должен вылететь ?

Re[4]: fatal error C1060: compiler is out of heap space

От:

Дата:

04.02.16 13:23

Оценка:

_NN>Я так понимаю, что если я создам 200 таких классов в одном cpp файле , то компилятор должен вылететь ?
Выходит типа того. Фабрика подтягивает все определения, но 200 это только на самом верхнем уровне, а всего по библиотеке наберется тысячи полторы.

Re[6]: fatal error C1060: compiler is out of heap space

От:

Дата:

04.02.16 14:13

Оценка:

_NN>Итак я создал 200 классов такого рода и компилятор съел без проблем.
_NN>Мне кажется что-то вы недоговариваете.

Не 200 нужно, а полторы тысячи. И сами классы компилировать без вызовов CreateInstance смысла никакого не имеет.

Re[7]: fatal error C1060: compiler is out of heap space

	От:	_NN_	www.nemerleweb.com
Дата:	04.02.16 14:32
	Оценка:

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

_NN>>Итак я создал 200 классов такого рода и компилятор съел без проблем.
_NN>>Мне кажется что-то вы недоговариваете.

UA>Не 200 нужно, а полторы тысячи. И сами классы компилировать без вызовов CreateInstance смысла никакого не имеет.

Мне тупо сгенерировать 1500 классов вместо 200 ? Думаю компилятор выживет.

Re[8]: fatal error C1060: compiler is out of heap space

От:

Дата:

04.02.16 14:39

Оценка:

UA>>Не 200 нужно, а полторы тысячи. И сами классы компилировать без вызовов CreateInstance смысла никакого не имеет.
_NN>Мне тупо сгенерировать 1500 классов вместо 200 ? Думаю компилятор выживет.

С CreateInstance? Нашел еще подобное обсуждение

здесь

Автор:
Дата: 13.10.08

Re[9]: fatal error C1060: compiler is out of heap space

	От:	_NN_	www.nemerleweb.com
Дата:	04.02.16 14:57
	Оценка:

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

UA>>>Не 200 нужно, а полторы тысячи. И сами классы компилировать без вызовов CreateInstance смысла никакого не имеет.
_NN>>Мне тупо сгенерировать 1500 классов вместо 200 ? Думаю компилятор выживет.

UA>С CreateInstance? Нашел еще подобное обсуждение здесь

Автор:
Дата: 13.10.08

Да не проблема нагенерировать сколь угодно

Такого типа устроит ?

void f()
{
    CComObject<CA1> c1; c1.CreateInstance(0);
 ...
    CComObject<CAn> cn; cn.CreateInstance(0);
}

Re[10]: fatal error C1060: compiler is out of heap space

От:

Дата:

04.02.16 15:09

Оценка:

_NN>Такого типа устроит ?

_NN>

_NN>void f()
_NN>{
_NN>    CComObject<CA1> c1; c1.CreateInstance(0);
_NN> ...
_NN>    CComObject<CAn> cn; cn.CreateInstance(0);
_NN>}
_NN>

Нет конечно.

Делай как MS:

CComObject<CMyCircle>* pCircle;
HRESULT hRes = CComObject<CMyCircle>::CreateInstance(&pCircle);
ATLASSERT(SUCCEEDED(hRes));

// Increment reference count immediately
pCircle->AddRef();

// Decrement reference count when done
pCircle->Release();
pCircle = NULL;

Re[11]: fatal error C1060: compiler is out of heap space

	От:	_NN_	www.nemerleweb.com
Дата:	04.02.16 15:50
	Оценка:

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

Я сделал так и всё собирается.
Хотите весь проект ?



void f()
{



    CComObject<CA0>* pA0;
    HRESULT hRes0 = CComObject<CA0>::CreateInstance(&pA0);
    ATLASSERT(SUCCEEDED(hRes0));

    // Increment reference count immediately
    pA0->AddRef();

    // Decrement reference count when done
    pA0->Release();
    pA0 = NULL;

....


    CComObject<CA1499>* pA1499;
    HRESULT hRes1499 = CComObject<CA1499>::CreateInstance(&pA1499);
    ATLASSERT(SUCCEEDED(hRes1499));

    // Increment reference count immediately
    pA1499->AddRef();

    // Decrement reference count when done
    pA1499->Release();
    pA1499 = NULL;

Re[12]: fatal error C1060: compiler is out of heap space

От:

Дата:

04.02.16 16:34

Оценка:

_NN>Хотите весь проект ?
Нет. И какой был расход памяти у твоего компилера?

Re[13]: fatal error C1060: compiler is out of heap space

	От:	_NN_	www.nemerleweb.com
Дата:	04.02.16 17:15
	Оценка:

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

_NN>>Хотите весь проект ?
UA>Нет. И какой был расход памяти у твоего компилера?

Private bytes дошел до 608Мб.
Virtual bytes доходит до 1Гб

Re[14]: fatal error C1060: compiler is out of heap space

От:

Дата:

04.02.16 17:24

Оценка:

_NN>Private bytes дошел до 608Мб.
_NN>Virtual bytes доходит до 1Гб

Скорее всего компилит каждый класс линейно (так как нету иерархии интерфейсов), а не одним скопом как у меня — но все равно спасибо за инфу.

Re[15]: fatal error C1060: compiler is out of heap space

	От:	_NN_	www.nemerleweb.com
Дата:	04.02.16 17:28
	Оценка:

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

_NN>>Private bytes дошел до 608Мб.
_NN>>Virtual bytes доходит до 1Гб

UA>Скорее всего компилит каждый класс линейно (так как нету иерархии интерфейсов), а не одним скопом как у меня — но все равно спасибо за инфу.

Сделать иерархию ?
Я думаю дело не в этом.

Мне кажется стоит выделить минимальный пример и понять что не так.

Re[16]: fatal error C1060: compiler is out of heap space

От:

Дата:

04.02.16 17:41

Оценка:

_NN>Мне кажется стоит выделить минимальный пример и понять что не так.
Пока что только так:

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

Re: fatal error C1060: compiler is out of heap space

	От:	Слава
Дата:	04.02.16 18:15
	Оценка:

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

UA>Возможно есть еще какой то волшебный ~~пендаль~~ опция компилятору?

1) Попробовать intel compiler
2) Попробовать gcc
3) Взять 64битный компилятор и арендовать сервер с 128гб оперативки.

Re[18]: fatal error C1060: compiler is out of heap space

От:

Дата:

07.02.16 12:11

Оценка:

_NN>Мне всё же не ясно зачем подключать все заголовочные файлы в один cpp ?
_NN>ATL этого не требует.

CreateInstance требует.

Re[19]: fatal error C1060: compiler is out of heap space

	От:	_NN_	www.nemerleweb.com
Дата:	07.02.16 12:13
	Оценка:

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

_NN>>Мне всё же не ясно зачем подключать все заголовочные файлы в один cpp ?
_NN>>ATL этого не требует.

UA>CreateInstance требует.
Что значит требует ?
Поясните примером кода что ли.

Re[13]: fatal error C1060: compiler is out of heap space

	От:	B0FEE664
Дата:	08.02.16 12:28
	Оценка:

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

BFE>>но если вы скажете, что данная проблема не решается разбиением кода по файлам — не поверю.
UA>Не решается, потому что в древовидной архитектуре все равно есть место (уровнем выше) где эти разбиенные файлы встречаются вместе.

Неужели

Автор: UA
Дата: 08.02.16

BFE>>Вот если бы у вас линковщик падал, то тогда, можно было бы сказать — всё, приплыли. А так — реорганизация кода решает. Даже переписывать не надо.
UA>И снова ты не прав, линкер рухнул первым по out of memory и почему то на границе 3GB (три!!! не четыре — возможно баг MS-а), но опция /OPT:NOREF пока помогает сбавить темп использования памяти линкером до 2.5GB.

Интересно. И насколько это раздувает объектник?

И каждый день — без права на ошибку…

Re[14]: fatal error C1060: compiler is out of heap space

От:

Дата:

08.02.16 12:42

Оценка:

BFE>Неужели

Автор: UA
Дата: 08.02.16

Я бы назвал это хаками, потому что в идеале я не обязан был делать этого.

UA>>И снова ты не прав, линкер рухнул первым по out of memory и почему то на границе 3GB (три!!! не четыре — возможно баг MS-а), но опция /OPT:NOREF пока помогает сбавить темп использования памяти линкером до 2.5GB.
BFE>Интересно. И насколько это раздувает объектник?

Пока меня это не заботит.

Re[3]: fatal error C1060: compiler is out of heap space

От:

LaptevVV

Дата:

08.02.16 15:01

Оценка:

UA>Не знаю как другие, но MS-овский 64битный компилятор не умеет компилировать под Win32, а только под Win64.
Что-то у вас в консерватории подправить надо.
Я в одной и той же студии 2012 одну и ту же прогу компилирую и как 32, и как 64.
Обе работают.
Я что-то делаю не так?

Хочешь быть счастливым — будь им!
Без булдырабыз!!!

Re[5]: fatal error C1060: compiler is out of heap space

От:

LaptevVV

Дата:

08.02.16 15:43

Оценка:

LVV>>Я в одной и той же студии 2012 одну и ту же прогу компилирую и как 32, и как 64.
LVV>>Обе работают.
LVV>>Я что-то делаю не так?
UA>32 битный компилятор может собирать под x32 и под x64, а вот 64 битный только под x64
А зачем и как ты их различаешь? Их там два?
Я студию установил и более не парюсь — просто меняю целевую платформу.
Студия сама разбирается…
Я работаю на Windows 7.
Компилять требовалось для Windows XP, Win7-8.
Требовалось включать всю возможную оптимизацию.
Когда требовалось для XP, я еще в CodeBlock компилял с помощью g++ — тоже при всех включенных оптимизациях.

Теперь вот хочу из студии вылезть и перейти в ручной режим (как в старые добрые времена… ) с использованием MinGW-64.

Хочешь быть счастливым — будь им!
Без булдырабыз!!!

Re[6]: fatal error C1060: compiler is out of heap space

От:

Дата:

08.02.16 15:49

Оценка:

UA>>32 битный компилятор может собирать под x32 и под x64, а вот 64 битный только под x64
LVV>А зачем и как ты их различаешь? Их там два?
Да. Я так понимаю что когда то придет время что x32 мы больше не увидим, а так те кому нужен только x64 заранее все протестируют и переход будет безболезненным.

Wait...

Переместить
Удалить
Выделить ветку

Пока на собственное сообщение не было ответов, его можно удалить.

Источник

Comments

Description

Findings

Question

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 компилятору не хватает размера кучи

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