Здравствуйте, dead0k, Вы писали:
RF>>#define C 299792.458
D>Экая прелесть! D>А кто эту либу написал? Мне чтобы бежать сразу как встречу.
Предупреждаю на всякий случай про #define I в стандартной библиотеке C
Defined in header <complex.h>
#define I /* unspecified */
(since C99)
И это еще считай повезло, что
The macro is not named i, which is the name of the imaginary unit in mathematics, because the name i was already used in many C programs, e.g. as a loop counter variable.
На Visual C++ 2012 разрабатывается решение. В состав решения находится проект MathLib, в котором находятся файлы Types.h и Defconst.h . В файле Types.h определены типы ( например, typedef long double LDouble ), а в файле Defconst.h определены константы, в частности, определена константа
#define C 299792.458
Также в этом решении есть проект Orbit, который использует эти два файла (Defconst.h и Orbit.h).
При компиляции в проекте Orbit выдаётся ряд ошибок, связанных с системным файлом winnt.h . В частности, выдаётся ошибка
То есть появляется конфликт имён--в файле winnt.h определено значение C со значением 1 как поле структуры DUMMYSTRUCTNAME, а в файле Defconst.h определена константа C со значением 2999792.458 .
Как разрешить эту проблему? Можно ли её решить без переименования константы C в файле Defconst.h -- например, что-то изменив в настройках Visual C++ ?
В проекте Orbit я в файле stdafx.h поместил заголовки системных .h-файлов, которые у меня используются, а в своих .cpp-файлах и .h-файлах я убрал заголовки этих системных файлов, оставив только #include "stdafx.h" .
И всё заработало!
Здравствуйте, RussianFellow, Вы писали:
RF>Как разрешить эту проблему? Можно ли её решить без переименования константы C в файле Defconst.h
Поменять порядок включений заголовочных файлов чтобы макрос определялся после разбора winnt.
Либо делать undef макросу C перед включением других заголовков.
Либо разделить исходный модуль на части, в которых не использовать одновременно оба заголовка.
Ну и, конечно, можно поправить код и избавится от макросов или хотя бы дать им более уникальные имена.
Здравствуйте, RussianFellow, Вы писали:
RF>Как разрешить эту проблему? Можно ли её решить без переименования константы C в файле Defconst.h -- например, что-то изменив в настройках Visual C++ ?
Константу запихай в namespace и назови const double C = xxx.xxx
Макросы для подобных вещей лучше не использовать.
Здравствуйте, RussianFellow, Вы писали:
RF>На Visual C++ 2012 разрабатывается решение. В состав решения находится проект MathLib, в котором находятся файлы Types.h и Defconst.h . В файле Types.h определены типы ( например, typedef long double LDouble ), а в файле Defconst.h определены константы, в частности, определена константа
RF>#define C 299792.458
Если этот хедер для внутреннего пользования библиотекой, то на кой чёрт ты его включаешь к себе?
Если для внешнего, — на кой чёрт используешь эту библиотеку.
В любом случае, напиши автору библиотеки, что у него руки, как у осьминога — гибкие такие, подвижные, шаловливые, и растут из одного места.
Однобуквенные идентификаторы, даже если это Мировая Константа (в данном случае, судя по значению, это скорость света в СИ) — зло.
Пробегись тупой тотальной заменой исходников (или хотя бы хедеров) библиотеки C на CONST__LIGHTSPEED. Ибо нефиг. Компилятору всё равно, а ты же не будешь вычитывать формулы, которые лежат внутри библиотеки.
А для своих формул напиши хедер с текстом
namespace cosmology {
const double c = CONST_LIGHTSPEED;
const double G = CONST_GRAVITY;
const double g = CONST_EARTH_GRAVITY;
const double e = CONST_ELECTRON_CHARGE;
const double h = CONST_PLANK;
const double h_ = CONST_PLANK_STROKED;
.....
}
Здравствуйте, _NN_, Вы писали:
_NN>Не, ну конечно спасибо, что хотя бы не 'i'. _NN>А чё.
Следует также отметить гуманность авторов библиотеки, которую использует топикстартер. А ведь могли сделать и #define c 299792.458 как это принятов в физике.
Здравствуйте, watchmaker, Вы писали:
W>Здравствуйте, RussianFellow, Вы писали:
RF>>Как разрешить эту проблему? Можно ли её решить без переименования константы C в файле Defconst.h W>Поменять порядок включений заголовочных файлов чтобы макрос определялся после разбора winnt.
Как это сделать? У меня нигде явно winnt.h в моём проекте Orbit не подключается. Но есть вкладка "Внешние зависимости", в которых перечислена куча системных .h-файлов, среди которых есть и winnt.h .
W>Либо делать undef макросу C перед включением других заголовков.
Здравствуйте, RussianFellow, Вы писали:
W>>Либо делать undef макросу C перед включением других заголовков.
RF>Можете привести пример, как это делается?
Здравствуйте, RussianFellow, Вы писали:
W>>Поменять порядок включений заголовочных файлов чтобы макрос определялся после разбора winnt.
RF>Как это сделать?
Поменять порядок строчек с #include.
RF>У меня нигде явно winnt.h в моём проекте Orbit не подключается.
Ну значит по зависимостям он подключается. Например, включение <windows.h> приведёт и к включению <winnt.h>.
Но по большому счёту тебе даже искать кто его включает не нужно — просто переставь свой проблемный Defconst.h в конец списка.
W>>Либо делать undef макросу C перед включением других заголовков.
RF>Можете привести пример, как это делается?
Здравствуйте, RussianFellow, Вы писали:
RF>На Visual C++ 2012 разрабатывается решение. В состав решения находится проект MathLib, в котором находятся файлы Types.h и Defconst.h . В файле Types.h определены типы ( например, typedef long double LDouble ), а в файле Defconst.h определены константы, в частности, определена константа
RF>#define C 299792.458
RF>Также в этом решении есть проект Orbit, который использует эти два файла (Defconst.h и Orbit.h).
RF>То есть появляется конфликт имён--в файле winnt.h определено значение C со значением 1 как поле структуры DUMMYSTRUCTNAME, а в файле Defconst.h определена константа C со значением 2999792.458 . RF>Как разрешить эту проблему? Можно ли её решить без переименования константы C в файле Defconst.h -- например, что-то изменив в настройках Visual C++ ?
Мне интересно кто или что мешает вам прочитать хотя бы одну книгу по языку С?
На русском языке издано уже много книг по языку С.
Учиться методом проб и ошибок — это тупиковый путь.
Здравствуйте, Nikita123, Вы писали:
N>Здравствуйте, RussianFellow, Вы писали:
RF>>На Visual C++ 2012 разрабатывается решение. В состав решения находится проект MathLib, в котором находятся файлы Types.h и Defconst.h . В файле Types.h определены типы ( например, typedef long double LDouble ), а в файле Defconst.h определены константы, в частности, определена константа
RF>>#define C 299792.458
RF>>Также в этом решении есть проект Orbit, который использует эти два файла (Defconst.h и Orbit.h).
RF>>То есть появляется конфликт имён--в файле winnt.h определено значение C со значением 1 как поле структуры DUMMYSTRUCTNAME, а в файле Defconst.h определена константа C со значением 2999792.458 . RF>>Как разрешить эту проблему? Можно ли её решить без переименования константы C в файле Defconst.h -- например, что-то изменив в настройках Visual C++ ? N>Мне интересно кто или что мешает вам прочитать хотя бы одну книгу по языку С? N>На русском языке издано уже много книг по языку С. N>Учиться методом проб и ошибок — это тупиковый путь.
Я уже прочитал достаточно много книжек по C++.
Если что-то ещё читать--то только Страуструпа.
Перекуём баги на фичи!
