Как Вы склеиваете Lua к коду C++?
В дополнение к рассмотрению каталога, содержащего «заголовки систем», -isystem изменяет список поиска заголовков, помещая аргумент каталога в начало каталогов заголовков системы. Если каталог уже существует в списке поиска, он удаляется из его текущего местоположения.
Начиная с (по крайней мере) GCC 6.1.1, некоторые заголовки C ++, такие как cmath, используют #include_next для обезьяны -patch C ++ для стандартных заголовков C. См. . Почему & lt; cstdlib> сложнее, чем вы думаете для получения дополнительной информации. Например, cmath имеет строку:
#include_next
#include_next, в отличие от обычного оператора #include, запускает поиск файла в следующей записи в пути поиска каталога include, а чем в верхней части пути поиска. Поскольку -isystem /usr/include перемещает /usr/include в путь поиска до каталога, содержащего cmath, math.h не может быть найден.
Подробно, путь поиска для команды g++ -I /usr/include -
/usr/include/c++/6.1.1
/usr/include/c++/6.1.1/x86_64-pc-linux-gnu
/usr/include/c++/6.1.1/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include-fixed
/usr/include
(/usr/include - системный каталог, аргумент -I ничего не делает.)
cmath находится по пути /usr/include/c++/6.1.1/cmath, который является первым элементом путь поиска. math.h можно найти в
/usr/include/math.h
/usr/include/c++/6.1.1/math.h
Использование #include_next в cmath гарантирует, что копия math.h в /usr/include/c++/6.1.1 пропущена и что используемая копия - /usr/include/math.h .
С g++ -isystem /usr/include путь поиска -
/usr/include
/usr/include/c++/6.1.1
/usr/include/c++/6.1.1/x86_64-pc-linux-gnu
/usr/include/c++/6.1.1/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include-fixed
Теперь использование #include_next пропускает /usr/include/c++/6.1.1, а также /usr/include, который находится над ним в путь поиска. В результате компилятор не может найти любую копию math.h.
Чтобы подвести итог, будьте осторожны при использовании -isystem для его побочных эффектов с ошибкой; если включенная директория уже находится в пути поиска, порядок пути может быть изменен, и GCC может сообщать об ошибках.
Должно быть что-то вроде следующего Makefile:
llvm.include.dir := $(shell $(LLVM_CONFIG) --includedir)
include.paths := $(shell echo | cc -v -E - 2>&1)
ifeq (,$(findstring $(llvm.include.dir),$(include.paths)))
# LLVM include directory is not in the existing paths;
# put it at the top of the system list
llvm.include := -isystem $(llvm.include.dir)
else
# LLVM include directory is already on the existing paths;
# do nothing
llvm.include :=
endif
Это устанавливает make переменную llvm.include как -isystem или ничего, в зависимости от того, действительно ли она нужна или нет.
4 ответа
Отвечать на мой собственный вопрос частично:
Luabind: после того как Вы знаете, как связать методы и классы через этот неловкий шаблонный синтаксис, это довольно просто и легко добавить новую привязку. Однако luabind оказывает значительное влияние производительности и не должен использоваться для приложений реального времени. Приблизительно в 5-20 раз больше служебное, чем вызов C функции, которые управляют стеком непосредственно.
Я не могу действительно согласиться с голосованием 'самокрутки', связывание основных типов и статических функций C к Lua тривиально, да, но изображение изменяет момент, Вы начинаете иметь дело с таблицами и таблицами метаданных; дела идут более хитрые очень быстро.
LuaBind, кажется, делает задание, но у меня есть философская проблема с ним. Для меня походит, если Ваши типы являются уже сложными то, что Luabind является в большой степени шаблонным, не собирается делать Ваш код немного легче следовать, поскольку мой друг сказал, что "Вам будет нужен Травяной Затвор для выяснения сообщений компиляции". Плюс он зависит от Повышения, плюс время компиляции получают серьезный хит, и т.д.
После попытки нескольких привязки Tolua ++ кажется лучшим. Tolua, кажется, не очень в разработке, где, поскольку Tolua ++, кажется, хорошо работает (плюс половина учебных руководств 'Tolua', там, на самом деле, 'Tolua ++' учебные руководства, доверяйте мне на этом:) Tolua действительно генерирует правильный материал, источник может быть изменен, и это, кажется, имеет дело со сложными случаями (как шаблоны, объединения, неназванные структуры, и т.д., и т.д.)
Самая большая проблема с Tolua ++, кажется, отсутствие надлежащих учебных руководств, задавать проекты Visual Studio или то, что командная строка немного хитра для следования (Вы соединяете каналом/регистрируете, не может иметь пробелов - в Windows по крайней мере и так далее) однако, для меня это - победитель.
Я не пользуюсь никакой библиотекой. Я использовал БОЛЬШОЙ ГЛОТОК для представления библиотеки C некоторое время назад, но там было слишком много служебным, и я прекращаю использовать его.
Профессионалы являются лучшей производительностью и большим количеством управления, но его взятиями больше времени для записи.
Используйте необработанный Lua API для Вашей привязки - и сохраните их простыми. Возьмите вдохновение в самом API (библиотека AUX) и библиотеки авторами Lua.
С некоторыми сырыми данными практики API является наилучшим вариантом - максимальная гибкость и минимум ненужных издержек. Вы имеете то, что Вы хотите и не больше, способ, которым Вам нужен он, чтобы быть.
Если необходимо связать автоматизированные генераторы использования крупных сторонних библиотек как tolua, tolua ++ (или даже самокрутка для конкретного случая). Это освободило бы Вас от физического труда.
Я не рекомендовал бы использовать Luabind. В данный момент это - остановленная разработка (однако начинающий возвращаться к жизни), и если Вы встретили бы некоторый угловой случай, можно быть самостоятельно. Также Luabind в большой степени использует шаблонное метапрограммирование. Это может (и не может) быть недопустимым, в зависимости от точки зрения.