Устранение ошибок компилятора с помощью многих вложенных операторов #include
Код, с которым я работаю для своей карьеры, написан на C ++ и построен с использованием DevEnv wrap (1.61) для Visual Studio 15.
Большая часть работы заключается в настройке структур через серию #include операторы, которые заканчиваются очень вложенными, например:
//ObjRTC.h
struct OBJ_RTC
{
OBJ_SETTINGS settings;
OBJ_ESTOPS emergencyStops[maxEstops];
OBJ_MACHINES machines[maxMachines];
OBJ_FOO bar[maxFooBars];
};
.
//ObjMachines.h
struct OBJ_MACHINES
{
bool inUse;
INPUTS inputDevices[maxInputDevices];
OUTPUTS outputDevices[maxOutputDevices];
};
Эти структуры дополнительно определены в других файлах, и мы начинаем объявлять значения в файлах ‘def’.
// DefRTC.h
OBJ_RTC RealTimeController = {
#include "DefSettings.h"#include "DefEstops.h"#include "DefMachines.h"#include "DefFoo.h"};
.
// DefMachines.h
{
{
true,
{ /* list of inputs */ },
{ /* list of outputs */ },
},
{
true,
{ /* list of inputs */ },
{ /* list of outputs */ },
},
{
true,
{ /* list of inputs */ },
{ /* list of outputs */ },
},
},
Если в файлах объявлений есть синтаксическая проблема, то во время компиляции о ней часто сообщают только о том, что она поступила из последней строки DefRTC.h,
Я знаю, что могу начать копировать файлы и вставлять поверх #include строки, которые я сделал, пытаясь решить проблему (значение типа INPUT настроен вместо OUTPUT)
Есть ли способ получить отчет компилятора, откуда произошла синтаксическая ошибка в отношении файла #included?
Решение
Вы можете предварительно обработать файл .c, который выдает ошибки компилятора, и скомпилировать этот предварительно обработанный файл.
Тогда ошибка / предупреждение всегда будет ссылаться на строку в этом файле.
Затем вы можете определить исходный файл, из которого поступают строки, вставив закладки, которые сохраняются после предварительной обработки. Закладки в основном просто отмечают имя файла в одной из первых строк каждого файла.
Как сделать закладку выжившего препроцессора (потому что комментарии и определения препроцесса, конечно, теряются)?
Напишите typedef, он не потребляет никаких ресурсов (кроме использования пространства имен)
и это все еще присутствует для человеческих глаз, читающих обработанные файлы:
typedef int BookmarkFilename1_h_Start;
Для дополнительного удобства навигации добавьте еще одну закладку в конце каждого заголовка:
typedef int BookmarkFilename1_h_End;
Затем, чтобы найти номер строки в заголовке (если он очень длинный), вычтите номер строки закладки (в предварительно обработанном файле) из номера строки ошибки в pp-файле. Затем добавьте номер строки закладки в исходный заголовок.
Помимо использования многострочных макросов (с \ продолжение), это должно дать вам имя файла и оригинальный номер строки.
В случае, если ваш toolchain / builddenvironment жалуется на использование intзамените его на любой другой принятый уже видимый тип.
Для целенаправленной идентификации подозрительных линий вы можете добавить закладки в соседние строки, близкие к подозреваемым. Просто убедитесь, что вы находитесь вне сферы действия чего-либо, то есть в месте, где создание typedef не является проблемой.
Другие решения
Других решений пока нет …