Процесс компиляции
Похоже, что ваша игра начинается с
death=false
И поэтому ваши астероиды никогда не появляются, потому что этот цикл пропускается. Вероятно, вы должны изменить цикл while на:
while (!death)
5 ответов
От источника до исполняемого файла обычно два процесса этапа для C и связанных языков, хотя IDE, вероятно, представляет это как единственный процесс.
1/Вы кодируете свой источник и выполняете его через компилятор. Для компилятора на этом этапе нужны Ваш источник и заголовочные файлы другого материала, с которым Вы собираетесь связаться (см. ниже).
Компиляция состоит из превращения Ваших исходных файлов в объектные файлы. Объектные файлы имеют Ваш скомпилированный код и достаточно информации для знания то, в чем другом материале они нуждаются, но не, где найти что другой материал (например, библиотеки LUA).
Соединение 2/, следующий этап, комбинирует все Ваши объектные файлы с библиотеками для создания исполняемого файла. Я не покрою динамическое подключение здесь, так как это усложнит объяснение с небольшим преимуществом.
Мало того, что необходимо указать каталоги, где компоновщик может найти другой код, необходимо указать фактическую библиотеку, содержащую тот код. То, что Вы получаете неразрешенный внешний облик, указывает, что Вы не сделали этого.
Как пример, полагайте, что следующее упростило код C (xx.c) и команда.
#include <bob.h>
int x = bob_fn(7);
cc -c -o xx.obj xx.c
Это компилирует xx.c файл к xx.obj. bob.h содержит прототип для bob_fn() так, чтобы компиляция успешно выполнилась. -c дает компилятору команду генерировать объектный файл, а не исполняемый файл и -o xx.obj определяет имя выходного файла.
Но фактический код для bob_fn() не находится в заголовочном файле, а в /bob/libs/libbob.so, таким образом для соединения Вам нужно что-то как:
cc -o xx.exe xx.obj -L/bob/libs;/usr/lib -lbob
Это создает xx.exe от xx.obj, пользование библиотеками (разыскиваемый в данных путях) формы libbob.so (lib и .so обычно добавляются компоновщиком). В этом примере, -L устанавливает путь поиска для библиотек. -l указывает библиотеку для нахождения для включения в исполняемый файл при необходимости. Компоновщик обычно берет "боба" и находит первый соответствующий файл библиотеки в пути поиска указанным -L.
Файл библиотеки является действительно набором объектных файлов (вид того, как zip-файл содержит несколько других файлов, но не обязательно сжатый) - когда первое соответствующее возникновение неопределенного внешнего найдено, объектный файл копируется с библиотеки и добавляется к исполняемому файлу точно так же, как Ваш xx.obj файл. Это обычно продолжается, пока нет более неразрешенного внешнего облика. 'Соответствующая' библиотека является модификацией текста "боба", она может искать libbob.a, libbob.dll, libbob.so, bob.a, bob.dll, bob.so и так далее. Уместность решена компоновщиком сама и должна быть зарегистрирована.
То, как это работает, зависит от компоновщика, но это - в основном это.
1/Все Ваши объектные файлы содержат список неразрешенного внешнего облика, который они должны разрешить. Компоновщик соединяет все эти объекты и ремонтирует ссылки между ними (твердость как можно больше внешнего облика).
2/Затем для каждого внешнего, все еще неразрешенного, расчески компоновщика файлы библиотеки, ища объектный файл, который может удовлетворить ссылку. Если это находит его, это втягивает его - это может привести к далее неразрешенному внешнему облику, поскольку втянутый объект может иметь свой собственный список внешнего облика, который должен быть удовлетворен.
Шаг 2 Повторения 3/до нет более неразрешенного внешнего облика или никакой возможности разрешения их из списка библиотеки (это - то, где Ваша разработка была в, так как Вы не включали файл библиотеки LUA).
Сложность, которую я упомянул ранее, является динамическим подключением. Это - то, где Вы связываетесь с тупиком стандартной программы (вид маркера), а не фактической стандартной программы, которая позже разрешена во время загрузки (когда Вы выполняете исполняемый файл). Вещи, такие как стандартные элементы управления Windows находятся в этих DLLs так, чтобы они могли измениться, не имея необходимость повторно связывать объекты в новый исполняемый файл.
Шаг 1 - компилятор:
- Вход: Файл исходного кода [s]
- Процесс: Парсинг исходного кода и перевод в машинный код
- Вывод: Объектный файл [s], которые состоят [s]:
- Названия символов, которые определяются в этом объекте, и которые "экспортирует" этот объектный файл
- Машинный код связался с каждым символом, это определяется в этом объектном файле
- Названия символов, которые не определяются в этом объектном файле, но от которого зависит программное обеспечение в этом объектном файле и с которым это должно впоследствии быть связано, т.е. имена, которые "импортирует" этот объектный файл
Шаг 2 - соединение:
- Вход:
- Объектный файл [s] от шага 1
- Библиотеки других объектов (например, от O/S и другого программного обеспечения)
- Процесс:
- Для каждого объекта, который Вы хотите связать
- Получите список символов, которые импортирует этот объект
- Найдите эти символы в других библиотеках
- Свяжите соответствующие библиотеки со своими объектными файлами
- Вывод: единственный, исполняемый файл, который включает машинный код от всех всех Ваших объектов плюс объекты из библиотек, которые были импортированы (связанные) с Вашими объектами.
Два основных шага являются компиляцией и соединением.
Компиляция берет единственные единицы компиляции (это - просто исходные файлы со всеми заголовками, которые они включают), и создайте объектные файлы. Теперь, в тех объектных файлах, существует много функций (и другой материал, как статические данные) определено в определенных местоположениях (адреса). На следующем шаге, соединении, также необходимо немного дополнительной информации об этих функциях: их имена. Таким образом, они также хранятся. Файл отдельного объекта может сослаться на функции (потому что он хочет назвать их, когда кодировать, выполняется), которые находятся на самом деле в других объектных файлах, но так как мы имеем дело с файлом отдельного объекта здесь, только символьные ссылки (их 'имена') к тем другим функциям хранятся в объектном файле.
Затем прибывает связываясь (давайте ограничим нас статическим подключением здесь). Соединение состоит в том, где объектные файлы, которые были созданы в первом шаге (или непосредственно, или после того, как они были брошены вместе в .lib файл) взяты вместе, и исполняемый файл создается. На связывающемся шаге все те символьные ссылки от одного объектного файла или lib другому разрешены (если они могут быть), путем поиска имен в правильном объекте, нахождения адреса функции и помещения адресов на правильное место.
Теперь, для объяснения чего-то о 'экстерне "C"' вещь Вам нужно:
C не имеет перегрузки функции. Функция является всегда распознаваемой своим именем. Поэтому при компиляции кода как C код только настоящее имя функции хранится в объектном файле.
C++, однако, имеет что-то вызванная 'функция / перегрузка метода'. Это означает, что названия функции больше не достаточно для идентификации его. Компиляторы C++ поэтому создают 'названия' функций, которые включают прототипы функции (так как имя плюс прототип однозначно определит функцию). Это известно как 'искажение имени'.
'Экстерн "C"' спецификация необходим, когда Вы хотите пользоваться библиотекой, которая была скомпилирована, поскольку 'C' кодируют (например, предварительно скомпилированные двоичные файлы Lua) из проекта C++.
Для Вашей точной проблемы: если это все еще не работает, эти подсказки могли бы помочь: * двоичные файлы Lua были скомпилированы с той же версией VC ++? * можно ли просто скомпилировать Lua сами, или в решении VC, или как отдельный проект как код C++? * действительно ли Вы уверены, что у Вас есть весь 'экстерн "C"' корректные вещи?
Необходимо войти в установку проекта и добавить каталог, где у Вас есть та библиотека LUA *.lib файлы где-нибудь на вкладке "компоновщика". При установке названный "включая библиотеки" или что-то, извините я не могу искать его.
Причина Вы получаете "неразрешенные внешние ссылки", состоит в том, потому что компиляция в C++ работает на двух этапах. Во-первых, код компилируется, каждый .cpp файл в своем собственном .obj файле, затем "компоновщик" запускает, и присоединитесь ко всему этому .obj файлы в .exe файл. файл .lib является просто набором .obj файлов, объединенных вместе для создания распределения библиотек просто небольшим simplier. Таким образом путем добавления всего "#include" и объявления экстерна Вы сказали компилятору, что где-нибудь будет возможно найти код с теми подписями, но компоновщик не может найти, что код, потому что это не знает, куда те .lib файлы с фактическим кодом помещается.
Удостоверьтесь, что Вы считали REDME библиотеки, обычно они скорее детализировали объяснение того, что необходимо было сделать для включения его в код.
Вы также можете проверить это: КОМПИЛЯТОР, СБОРНИК, ЛИНКЕР И ЗАГРУЗЧИК: КРАТКАЯ ИСТОРИЯ .