Могу ли я сделать C / C ++ #defines закрытым?

0

Мой проект должен быть C++. Я включаю:

  • бойкий-2,0
  • GTK + -2,0
  • пилон (C++)
  • GenICam

Мой другой вопрос привел меня дальше.

  1. Могу ли я сделать #define частным, так что нет другого исходного файла обыкновения EVER не быть в состоянии использовать приватные Определяет?

Ответ: да, в файлах C или cpp (в то время как их заголовки не раскрывают эти определения)

  1. Должен ли я включать все библиотеки дважды (для обоих компиляторов: GCC C, GCC C++)? (Я буду использовать библиотеки C в файлах cpp). А также для компоновщика?

  2. Я использую "pkg-config --cflags --libs glib-2.0 gtk + -2.0" для исправления некоторых фатальных ошибок "файл не найден". Но я все равно их получаю (например, файл glibconfig.h ~ не найден). Есть ли надежное исправление для этого?

  3. Возможно, проблема в том, что если я сделаю глобальный #define null или что-то, а затем включенные библиотеки, которые могут иметь одинаковые имена определений в моем проекте?

    Я начал проект шаг за шагом, включая одну библиотеку за раз, и исправил проблемы, если они возникли. Затем включите следующую библиотеку и устраните проблемы и т.д. Я использую eclipse, у меня есть защита и смешанные исходные файлы c и cpp.
Теги:
compiler-errors
c-preprocessor

3 ответа

7
Лучший ответ

Единственный способ сделать макрос препроцессора "private" - определить их в исходном файле. Тогда они будут доступны только для этого исходного файла.

Вы должны помнить, что препроцессор (который обрабатывает макросы и директивы #include) - это действительно отдельный шаг, который выполняется до того, как фактический компилятор увидит источник.

Кроме того, когда вы определяете макрос с #define, он фактически не определяется так же, как это делает компилятор и компоновщик. После того, как запущены этапы препроцессора, в результирующем блоке перевода больше нет имен макросов.

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

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

Вы также должны быть осторожны при использовании, например, pkg-config для получения как флагов компилятора, так и компоновщика. Прежде всего вам понадобятся только флагов компилятора (аргумент --cflags) при --cflags исходных файлов в объектные файлы. Затем при связывании вам нужны только флаги компоновщика (флаг --libs для pkg-config), а результирующие флаги должны быть последними в командной строке (потому что компоновщик хочет библиотеки после объектных файлов, зависящих от библиотек).

Поделиться
  • 0
    Разве c файлы не скомпилированы компилятором GCC C, а файлы cpp - компилятором GCC C ++?
  • 0
    @ mini-me Но если вы пишете код на C ++, у вас не будет C-файлов в вашем собственном проекте, не так ли? Приятной особенностью библиотек, созданных на C (или экспортирующих интерфейс C), является то, что они могут использоваться практически из чего угодно, особенно C ++.
Показать ещё 4 комментария
2

Вы можете так

#define X 5
int a = X;
#undef X

Помните, что определение - это препроцессорная директива, а также #incldue. Определение будет игнорировать области действия и будет применяться к любому включенному файлу, который находится между #define и #undef

Обычно это плохая практика и может привести к кошмарам обслуживания. Избежать возможно.

Поделиться
1

Прежде всего, вы можете узнать больше о предварительном процессоре и процессе компиляции, но теперь на ваши вопросы:

1) Могу ли я сделать #define частным, так что ни один другой исходный файл не сможет использовать частные настройки?

Нет такой вещи, как private #define. Однако вы можете использовать #undef для его определения после использования или поместить их только в файлы.c/.cpp.

2) Должен ли я включать все библиотеки дважды (для обоих компиляторов: GCC C, GCC C++)? (Я буду использовать библиотеки C в файлах cpp). А также для компоновщика?

Во время этапа компиляции вам не нужно указывать, какую библиотеку вы хотите связать позже. Компилятор интересуется только файлами заголовков используемой библиотеки.

Затем компоновщику нужны фактические файлы библиотек для связывания ваших объектных файлов с библиотекой.

3) Я использую pkg-config --cflags --libs glib-2.0 gtk+-2.0 чтобы исправить некоторые фатальные ошибки "файл не найден". Но я все равно их получаю (например, файл glibconfig.h ~ не найден). Есть ли надежное исправление для этого?

Вы можете сделать это, правильно настроив свои пути включения. Я не знаю, как это сделать в затмении, извините.

4) Возможно, проблема в том, что если я сделаю глобальный #define null или что-то, а затем включенные библиотеки, которые могут иметь одинаковые имена определений в моем проекте?

Я сомневаюсь, что в случае, если файлы заголовков не найдены, но это как-то напоминает мне

#define true false

и все эти шутки...

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню