Устранение ошибок компилятора с помощью многих вложенных операторов #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?

0

Решение

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

Напишите typedef, он не потребляет никаких ресурсов (кроме использования пространства имен)
и это все еще присутствует для человеческих глаз, читающих обработанные файлы:

typedef int BookmarkFilename1_h_Start;

Для дополнительного удобства навигации добавьте еще одну закладку в конце каждого заголовка:

typedef int BookmarkFilename1_h_End;

Затем, чтобы найти номер строки в заголовке (если он очень длинный), вычтите номер строки закладки (в предварительно обработанном файле) из номера строки ошибки в pp-файле. Затем добавьте номер строки закладки в исходный заголовок.
Помимо использования многострочных макросов (с \ продолжение), это должно дать вам имя файла и оригинальный номер строки.

В случае, если ваш toolchain / builddenvironment жалуется на использование intзамените его на любой другой принятый уже видимый тип.

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

0

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector