Как предотвратить бесконечный цикл, связанный с файлами?

Ясно. Имеем дело с зацикливанием. Циклический граф. Как я понимаю, исходник будет обрабатываться в два этапа: вставка include'ов, затем компиляция. Можно попробовать многоэтапную развертку. Введем запрет на импорт самого себя: в main.asm нельзя написать include main.asm. Кроме того, будем вести список всех импортированных файлов. Затем используем такой алгоритм:

Код (Text):

1. 1. Найти в исходнике все include.
2. 2. Если include'ов нет - завершить работу, иначе перейти к пункту 3.
3. 3. Проверить имена импортируемых файлов (имена файлов не должны
4. совпадать с именем исходника, в именах не должно быть двух одинаковых,
5. сравнить с именами ранее импортированных файлов).
6. 4. Если совпадающих имен нет - вставить все импортируемые файлы в
7. исходник, добавить имена в список импортированных файлов и
8. перейти к пункту 1, в противном случае выдать ошибку.

Вот такое решение.

---------------

Еще можно просто отказаться от вложенных include'ов.

---------------

А еще можно просто оставить все как есть: оставить этот вопрос на совести
программиста. А что? В Си, например, именно так.

 

s3dworld

Да неужели? Ошибка случаем не "out of stack space", а?

Вообще отсутствие контроля повторного (в том числе и рекурсивного) включения include'ов — это не баг, а фича. Практическое применение у неё, правда, несколько сомнительно, но теоретически возможно. Поэтому в намеренном её устранении смысла маловато. Хотя как раз под fasm у меня специальный макрос для контроля повторного включения таки предусмотрен.

 

s3dworld

Человеку, который задается такими примитивными вопросами, рано делить фичи такиз продуктов, как студия, на достойные и недостойные.

 

Кстати, насчет зацикливания. Совершенно не факт, что рекурсивный (особенно косвенно) иклюд обязательно должен приводить к зацикливанию. Один крайний случай, который уже упомянули - это стандарт в Сишных хедерах #ifndef #define #endif полностью на весь файл.
Но могут ведь быть и другие случае, специально созданные разработчиком, с ветками условной компиляции, когда один и тот же файл в зависимости от оределенных в данный момент дефайнов будет генерить разные вещи и инклюдить разные более глубокие иклюды.

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

А в некоторых яхыках (скажем, в PHP) вообще специально существуют разные директивы иклюда - include и include_once.

 

Как вариант автоматического отсечения инклюдов - повторным вхождением считать не только путь к файлу, а путь к файлу в совокупности со всеми определенными на данный момент дефайнами из тех дефайнов, что анализируются в данном иклюде. Если путь тот же, а значения дефайнов другие - отсекать не следует.

 

Monogen
Для Windows полное имя к файлу я получу, а для Linux как?

l_inc
> Да неужели? Ошибка случаем не "out of stack space", а?
Она, но она возникает сразу же, а не когда память закончится. Считаешь что за меньше чем за секунду смогла бы закончиться память в 2 ГБ?

_DEN_
> Человеку, который задается такими примитивными вопросами, рано делить фичи такиз продуктов, как студия, на достойные и недостойные.
Конечно, особенно с учётом того что Visual C++ 2010 постоянно глючит (слетает IntelliSense), а так всё нормально, молодцы.

Dmitry_Milk
Спасибо что сказал, я совсем упустил этот момент, что нужно смотреть на условия препроцессора.

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

 

l_inc
Под си реукрсивные включения давольно хорошая фича, из одного file.c включая как заголовочный можно прогенерить тучу кодеса ... практически импел полиморфа на файлах.

 

s3dworld

Какие ещё 2 ГБ? Речь идёт о памяти стека, которой там всего-то 64К. Так что не просто смогла бы, а именно закончилась.
Кстати, насчёт 2 ГБ за секунду. 2 ГБ fasm сплошным куском выделить не сможет, т.к. в его АП кроме собственно ассемблируемого кода ещё куча всего лежит, но вот 1,5 ГБ консольная версия вполне может задействовать для компиляции. Так вот эти 1,5 ГБ вполне можно заставить fasm израсходовать за секунду.

 

shchetinin
Не то, чтобы я не верил, но на практический пример с удовольствием бы взглянул.

 

l_inc
Еслть проект либа вот только название не помню, идет в cygwin X (потры) по работе с ресинками. Там хорошо показано какой смысл включать .c как хедеры при чем в один и тот же .h после чего включать в .c и так далее .. вообще если будет время может вечером семпел накатаю.

 

shchetinin
как там сэмпл?

 

punxer
Честно говоря лень .. просто лень ...