Fatal error c1014 слишком много включаемых файлов глубина 1024
В Разделе D.1.4 вы найдете информацию об ограничениях компилятора, а в Разделе D.3.3-ограничения периода выполнения.
D.1.4. Ограничения компилятора.
Для работы с компилятором Microsoft Quick-C вам нужно иметь достаточное количество памяти для обработки временных файлов, используемых для обработки. Требуется память приблизительно в два раза большая, чем размер исходного файла.
D.3.1. Исключительные ситуации операций с плавающей точкой.
С помощью назначений управляющего слова сопроцессора 8087/80287, следующие исключительные ситуации маскируются и потому не происходят Исключительная Стандартное маскирующее действие
Информацию о том, как изменить управляющее слово операций с плавающей точкой, смотрите в справочных страницах, посвященных _control87, в документе "Справочное руководство по библиотеке процедур Microsoft C".
Кроме того, следующие ошибки не возникают в коде, сгенерированном с помощью компилятора Microsoft Quick-C или полученном посредством стандартной СИ-библиотеки:
Исключительные ситуации при операциях с плавающей точкой имеют следующий формат:
Номер Исключительные ситуации при операциях с плавающей точкой
D.3.3. Ограничения периода выполнения.
Пять стандартных потоков открываются автоматически (stdin, stdout, stderr, stdaux, stdprn), оставляя еще 15 потоков для нужд программы.
Предупреждения также обозначают возможные проблемы в выполняемом файле. Компановщик LINK строит выполняемый файл. Предупреждения имеют следующий формат:
Для просмотра ошибок компановщика нажмите ENTER, либо отметьте "мышью" командную кнопку OK. Ошибки последнего прохода компановщика хранятся в файле с именем LINK.ERR. В следующем списке приведены ошибки, возникающие во время компановки объектных файлов с помощью Microsoft Overlay Linker, LINK.
Ошибка: слишком много включаемых файлов
Народ подскажите что могло случится с Microsoft Visual C++ 2010 экспресс выпуск. До этого как.
Fatal error C1034: iostream: не указан путь поиска включаемых файлов
Пытаюсь скомпилировать файл на с++, но выдаёт такую ошибку, пожалуйста, помогите Вот код: .
Это очень грубая ошибка!
Во-вторых, функция pow(), объявлена для переменных типа double.
В третьих, cin,cout,endl принадлежат пространству имен std. Потому стоит написать или
добавьте using namespace std; и заменить void main() на int main().
Добавлено через 2 минуты
В старых компиляторах это не ошибка
Опять же, в старых компилятора это объекты глобальной зоны, а не пространства имён std.
Добавлено через 2 минуты
metaluga145, хотя то, что вы сказали, для девятой студии имеет определённый смысл.
Про старые компиляторы согласен.
Про функцию pow() не согласен! довольно принципиально,что за параметры ей дадут. И компилятор VS2010 точно ругается на pow(int,int);
все равно почему то не хочет работать( та же сама ошибка.. math.h(3) : fatal error C1014: слишком много включаемых файлов: глубина = 1024
Добавлено через 58 секунд
VC C++ 2008
А с чего ты взял, что я говорю именно об этом компиляторе?
metaluga145, gcc не ругается.
Добавлено через 45 секунд
maksimka95, покажи "новый" код.
вот код, пишет что "1>c:\program files (x86)\microsoft visual studio 9.0\vc\include\math.h(2) : fatal error C1014: слишком много включаемых файлов: глубина = 1024"
double p,q,r,T1,T2,S1,S2,n,h,Int,R4;
double I(double t)
return pow(p*pow(t,2)+q*t+r,2);
>
S2 = I(T1+h);
for(int k = 2; k < n; k += 2 )
S2 += I(T1+(k+1)*h);
S1 += I(T1+k*h);
>
Int = I(T1)+I(T2)+4*S2+2*S1;
Int *= h/3;
>
____
помогите пожалуйста..
GLib-ERROR **: Creating pipes for GWakeup: Слишком много открытых файлов
День добрый! Моя программа после 40-45 минут беспрерывной работы (а это создание потоков и работа.
слишком много аргументов в вызове функции или как создать много файлов на рабочем столе
Мне нужно создать на рабочем столе очень много файлов вот команда для создания 1 файла wchar_t.
ERROR: слишком много знаков в символьной константе
как понимать? пробовал и так и так не работает, почему? что делать? const char login =.
error C2078: слишком много инициализаторов при создании массива
Создаю текстовый массив. Выдает ошибку "error C2078: слишком много инициализаторов". При создании.
Слишком много файлов открыто 16-разрядными приложениями
Не запускаются приложения из-под учетной записи администратора. При перезагрузке системы появляется.
[Linker Fatal Error] Fatal: Could not open ~CBuilder6\Projects\Project1.exe (error code 5)
Инсталировал с++ builder 6. Запустил програму и попробывал компилировать пустую форму, чтобы.
Я использую выпуск Visual Studio 2008 Express и продолжаю получать следующую ошибку:
"Cascadedisplay.h(4) : fatal error C1014: too many include files : depth = 1024 .
Очевидно, я делаю что-то очень неправильно с включаемыми файлами, но я просто не вижу, что именно.
По сути, у меня есть класс интерфейса, StackDisplay , из которого я хочу получить CascadeDisplay в другом файле:
а затем в CascadeDisplay.h:
задан 13 марта '10, 09:03
Я бы попытался избежать включения в один заголовок другого. - kenny
Я бы удалил эту статическую функцию из базы. Ему здесь не место. Это может быть бесплатная функция (например, в пространстве имен), объявленная в «CascadeDisplay.h». - Заголовки, включающие друг друга, просто не будут работать. - UncleBens
Я считаю, что здесь, вероятно, есть недостаток дизайна, который идет глубже, чем ваша опечатка в заголовке. - Greg D
@UncleBens, я использовал статическую функцию, пытаясь подражать Скотту Мейерсу в пункте 31 Эффективного C++. Однако, возможно, я неправильно понял, откуда он взялся. - BeeBand
В качестве примечания, вы должны переименовать свои определения защиты заголовка. Идентификаторы, содержащие двойное подчеркивание or начиная с одного подчеркивания, за которым следует символ верхнего регистра (или все, что начинается с одного подчеркивания в области пространства имен (вне классов и функций), зарезервировано для реализации. Компилятор вероятно не определяет __CASCADE_DISPLAY_H__ , но это возможно, и это было бы законно. Используя что-то вроде CASCADE_DISPLAY_H_ вместо этого будет гарантировано отсутствие конфликтов ни с чем, что использует компилятор или стандартная библиотека. - jalf
D.2.1. Неисправимые ошибки командной строки.
Ошибки периода выполнения подразделяются на четыре категории: 1.Исключительные ситуации при выполнении операций с плавающей точкой математическим сопроцессором 8087/80287 или эмулятором. Данные ситуации описаны в Разделе D.3.1.
3 ответа
В любом случае, почему ваш «базовый» класс требует ссылки на CascadeDisplay ? Это не кажется правильным. Подумайте о том, чтобы заменить ваш вызов для создания нового CascadeDisplay вызовом чистой виртуальной функции в StackDisplay , которую ваш подкласс должен реализовать соответствующим образом.
IE, что-то вроде (и простите, у меня нет компилятора C ++, чтобы это проверить):
Грег, я использовал ваш код, и он отлично компилируется. Я использовал эту ссылку на CascadeDisplay в базовом классе из-за пункта 31 в Эффективном C ++. Скотт Мейерс сделал это, так что я думал, что сделаю. Однако ваше решение действительно лучше.
Сказав это, ваше решение не позволяет мне вызывать make_cascade_display() указателя StackDisplay , не делая его статической функцией. Если я сделаю это, я получу жалобу на незаконный вызов нестатического make_display() из статического make_cascade_display .
Я считаю, что это часть трудности объединения двух ролей в одном классе. В общем, я считаю, что «создание» объекта отличается от «использования» объекта, и поэтому я обычно предпочитаю создавать отдельный фабричный класс, а не использовать фабричный метод - особенно в C ++. Обходной путь гетто для сохранения статичности вашего метода может включать создание статического устанавливаемого свойства в StackDisplay, которое является указателем функции на эквивалент метода make_display.
Вторая строка должна быть:
Кроме того, имена, содержащие двойное подчеркивание, зарезервированы для реализации, вам не разрешается создавать такие имена в своем собственном коде. То же самое касается имен, которые начинаются с одного подчеркивания и заглавной буквы.
3 ответы
В любом случае, почему ваш «базовый» класс требует ссылки на CascadeDisplay ? Это не кажется правильным. Рассмотрите возможность замены вашего звонка на создание нового CascadeDisplay с вызовом чистой виртуальной функции в StackDisplay что ваш подкласс должен реализовать соответствующим образом.
IE, что-то вроде (и простите, у меня нет под рукой компилятора С++, чтобы проверить это):
ответ дан 13 мар '10, в 12:03
Грег, я использовал твой код, и он отлично компилируется. Я использовал эту ссылку на CascadeDisplay в базовом классе из-за статьи 31 в Effective C++. Скотт Мейерс сделал это, так что я думал, что сделаю это. Однако ваше решение действительно лучше. - БиБэнд
Сказав это, ваше решение не позволяет мне позвонить make_cascade_display() на StackDisplay указатель, не превращая его в статическую функцию. Если я это сделаю, то получу жалобу на незаконный вызов нестатического make_display() от статики make_cascade_display . - БиБэнд
Ах, я считаю, что это часть сложности объединения двух ролей в одном классе. В общем, я считаю, что "создание" объекта отличается от "использования" объекта, и поэтому я обычно предпочитаю создавать отдельный фабричный класс, а не использовать фабричный метод - особенно в C++. Обходной путь гетто для сохранения статичности вашего метода может включать создание статического устанавливаемого свойства в StackDisplay, которое является указателем функции на эквивалент метода make_display. - Грег Д
Вторая строка должна быть:
Кроме того, имена, содержащие двойное подчеркивание, зарезервированы для реализации, вам не разрешается создавать такие имена в своем собственном коде. То же самое касается имен, которые начинаются с одного символа подчеркивания и заглавной буквы.
Я получаю следующие ошибки, которые я не могу решить.
Пример заголовочного файла из проекта: bike.h
Переместите свои включения в оператор IFNDEF. Вы рекурсивно включаете свои файлы
Теперь я получаю кучу таких ошибок: 1> k:\school\c++\project_2\project_2\mecanicien.h(18): error C2065: 'Fiets': необъявленный идентификатор
Решение проблемы include-guards не обязательно решает все проблемы рекурсивного включения (как показано в ответе Sharpless512). Я чувствую, что этот ответ неполный в его нынешнем виде.
- как я указал в своем ответе, а Гривес в комментарии чуть выше моего, вам, вероятно, придется использовать предварительные объявления, хотя это не единственный метод решения подобных проблем.
На мой взгляд, я бы предположил, что у вас возникла проблема с циклическим включением. Один из ваших заголовков Datum.h , Wielrenner.h , Onderhoud.h случайно не включает Fiets.h ? Или они включают файл, который включает его?
Вы можете избежать этого, убедившись, что ваш заголовок, включая любые включенные заголовки, защищен препроцессором, включая защиту, например.
Это предотвратит включение вашего файла в единицу компиляции более одного раза.
Вы можете обнаружить, что ваш инструмент сборки включает опцию отображения дерева включения, которое должно помочь вам узнать, что происходит.
В начале каждого заголовочного файла добавьте защиту включения:
Чтобы убедиться, что каждый заголовок включен один раз для каждой единицы компиляции.
Теперь, в вашем конкретном случае, вполне вероятно, что если вы решите эту одну проблему, вы увидите другую: я предполагаю, что из-за большой глубины включений и относительно небольшого количества файлов у вас где-то есть цикл включения. Например, bike.h может включать cyclist.h, который, в свою очередь, снова включает bike.h, и вы получаете бесконечный неразрешимый цикл. Чтобы обойти это, посмотрите, например, "forward Declaration".
Я никогда не достигал лимита на количество включаемых файлов, и в настоящее время я работаю над 1M LOC. Я бы предположил, что у вас есть цикл включения: файл X включает Y, Y (прямо или косвенно) включает X.
Во-вторых, поместите свои включения ВНУТРИ защиты включения:
В-третьих, почему бы вам не объявить необходимые классы в заголовках, а затем включить их в исходники?
Я использую Visual Studio 2008 Express edition и получаю следующую ошибку:
"Cascadedisplay.h(4) : fatal error C1014: too many include files : depth = 1024 .
Очевидно, что я делаю что-то не так с включаемыми файлами, но я просто не могу понять, что именно.
По сути, у меня есть интерфейсный класс StackDisplay , от которого я хочу получить CascadeDisplay в другом файле:
А затем в CascadeDisplay.h:
Я бы удалил эту статическую функцию из базы. Ему здесь не место. Это может быть бесплатная функция (например, в пространстве имен), объявленная в «CascadeDisplay.h». - Заголовки, включающие друг друга, просто не будут работать.
Я считаю, что здесь, вероятно, есть недостаток дизайна, который идет глубже, чем ваша опечатка в заголовке.
@UncleBens, я использовал статическую функцию в попытке подражать Скотту Мейерсу из пункта 31 Эффективного C ++. Возможно, я неправильно понял, откуда он.
В качестве примечания, вы должны переименовать свои определения защиты заголовка. Идентификаторы, содержащие двойное подчеркивание или , начинающееся с одного подчеркивания, за которым следует символ верхнего регистра (или что-либо, начинающееся с одного подчеркивания в области пространства имен (вне классов и функций), зарезервировано для реализации. Компилятор вероятно не определяет __CASCADE_DISPLAY_H__ , но может, и это было бы законно для него. Использование чего-то вроде CASCADE_DISPLAY_H_ вместо этого гарантировало бы не конфликтует ни с чем компилятор или стандартная библиотека использует.
Читайте также: