Почему возникает ошибка C1014 «Too many include files: depth 1024»?

Question

[Quark]

Никак не могу понять что это означает.Данная ошибка возникла после того,как я создал новый DLL и переместил в него часть своего кода,после чего это ошибка возникла в этой новой DLL и ещё в одной библиотеке.Погуглив ошибку( https://stackoverflow.com/questions/2438247/why-am... ) я понял,что она возникает из-за отсутствия примерно такой конструкции:

#ifdef MAINTYPES_API_EXPORTS
#define MAINTYPES_API extern "C" __declspec(dllexport)
#else
#define MAINTYPES_API extern "C" __declspec(dllimport)
#endif

Однако эта констукция у меня есть во всех моих .h файлах из DLL

Так-же,при существовании этих строк:

#include "Graphic_Library.h"
#include "Graphic_Library.cpp"

моя подсветка ломается и перестаёт работать.Помогает только их удаление,но,удалив,я получаю целую кучу ошибок(сами знаете почему).

Прилагаю код этой самой новой DLL.Сообщите,если понадобится что-нибудь ещё:
.h
https://pastebin.com/1dMpaG08

.cpp
https://pastebin.com/dgn5eJW0

Заранее спасибо за помощь с решением вопроса

Comments

[xorknown]

А зачем вы для cpp файла делаете include?
#include "Graphic_Library.cpp"

Answer 1

[Александр Ананьев]

https://stackoverflow.com/questions/2582521/fatal-...

Comments

[Quark]

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

Answer 2

[res2001]

Поставьте первой строкой в заголовке
#pragma once
Возможно это избавит вас от ошибки.

И зачем вы делает
#include "Graphic_Library.cpp"
не понятно.
Это может говорить о том, что интерфейс, подключаемый в заголовочном файле вы не доработали, или какие-то другие ошибки. Подобная конструкция, конечно, не является ошибкой сама по себе, но, как правило, так не делают.

Comments

[Quark]

Graphic_Library.cpp содержит определение класса Mesh.Без этого я не мог прописать определение класса GameObject

[res2001]

Quark, Вынесите объявление класса в заголовок, он для этого и предназначен.

[Quark]

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

[res2001]

Quark, Кто вам мешает оставить в заголовке только объявления.
А все определения (или только те, что считаете нужным) оставить в cpp? Вообще стандартная практика так-то.

PS: В прошлом посте ошибся с определениями, конечно. Исправился.

[Quark]

res2001, Насколько я понял вы предлагает вынести некоторые классы(тот-же Mesh) в мой Main_Types DLL?Да,я думал об этом,и да,я могу так сделать,но это будет крайне не логично,чего я пытаюсь избежать.

[res2001]

Quark, Я не в курсе архитектуры вашей библиотеки. Из приведенных исходников трудно сделать каких-то выводов.

Когда вы создаете библиотеку, то у вас есть некоторые экспортируемые типы, данные и функции (методы), которые должны быть видны из вне (пользователям библиотеки). А так же есть другие типы, данные и функции, которые являются внутренними для библиотеки и их не надо показывать на ружу.
В связи с этим у вас должен быть заголовочный файл (или несколько файлов) для внешних пользователей (для программ, которые будут использовать библиотеку) и другие заголовочные файлы для внутреннего использования (они нужны только для сборки самой библиотеки).
Вы сами, как разработчик библиотеки, определяете, что надо экспортировать, а что не надо.
Во внешней программе, использующей библиотеку нужно подключать только файлы заголовков для экспорта, внутренние заголовки вообще не нужны внешней программе и они должны/могут быть не доступны во время сборки внешней программы.
Если библиотека не большая, то в принципе, может не быть внутренних типов и данных, тогда нет смысла во внутренних заголовочных файлах.

Еще несколько замечаний:
Использовать etxern C не логично для классов и структур С++, т.к. в Си нет классов и структуры там отличаются от структур в С++. Если вы хотите, что бы ваша библиотека могла использоваться в программах на Си, то нужно поступать несколько по другому. А плюсовые программы смогут использовать вашу библиотеку и без extern C.
Не зачем в классе/структуре для каждого метода писать модификатор доступа (public), это же не Java.

[Quark]

res2001, Библиотеки у меня небольшие(не более 300 строчек кода),поэтому в каждой из них всего по одному .cpp и .h.

Моя проблема была в том,что все библиотеки изспользовали пару других библиотек,которые использовали их же.На данный момент я переделал архитектуру и теперь это выглядит так:
1)Первоначальное определение базовых типов
2)Отправка их во все библиотеки,которые их используют
3)Отправка типов из 2 действия в одну библиотеку,где я из них собираю более сложные типы
4)Отправка всего этого в проект с моей консольной игрой.

На счёт "extern C":
Данную конструкцию я использвал потому что делал библиотеку по туториалу от microsoft.Вот вам ссылка,если хотите посмотреть:
https://docs.microsoft.com/en-us/cpp/build/walkthr...

[res2001]

Quark,

На счёт "extern C"

Обратите внимание - по ссылке extern C используется только с обычными функциями (не с типами, не с данными и не с членами классов).
extern C - заставляет компилятор не использовать плюсовый name mangling для указанных объектов. Вместо него используется сишный манглинг. Это вносит определенные ограничения на использование возможностей С++, например в этом случае не возможна перегрузка функций (т.к. она реализована за счет плюсового name mangling).
Т.к. в Си нет классов, а Си структуры - это совсем не С++ структуры, то классы и структуры С++ вообще нет смысла экспортировать, если планируется использование библиотеки в программах на Си. Экспортируйте только стандартные типы.
Почему важен сишный name mangling - потому что его поддерживает не только Си, но и куча других языков программирования, которые способны использовать динамические библиотеки. А плюсовый mangling используют только плюсы, на сколько я знаю.

Но вы же пишете библиотеки для себя. И, видимо, будете их использовать только в С++ программах. В этом случае можно вообще не использовать extern C. И тут у вас нет ограничений на экспорт структур и классов.

https://en.cppreference.com/w/cpp/language/languag...