когда редактируешь проект, надо выбирать вариант сборки ,который редактируешь. Ты наделал мешанину из путей, смешав релиз и дебаг варианты, ещё и сломав стандартные зависимости.
Сперва создай мастером стандартное консольное приложение, выводяее хело ворлд и убедись, что оно компилируется. А потом уже добавляй туда свои файлы и корректируй main функцию.
yatanai, благодарю, нагуглил. С++20 пока не пользуюсь.
Всё-таки, подобный код чаще обозначает ошибки проектирования, чем реальную необходимость.
Правда я не понимаю, зачем делать memcpy, если этим же static_assert можно было проверять размерности перед reinterpret_cast. Скорее всего что-то связанное с выравниванием памяти. Но всё это обнаруживается при падении при первом же использовании... Ладно, возвращаясь к теме.
Размещающий new всё-равно будет требовать корректное выравнивание, особенно для вещественных чисел. Не буду утверждать, что будет падение при обращение к памяти, может просто будут дополнительные операции и сильное падение производтиельности.
Если смущает временная переменная dst и её копирование, которое компилятор может быть не заоптимизирует, то можно сделать свой вариант bit_cast, но с двумя аргументами, второй из которых будет ссылкой на dest. Байтовое копирование останется, но не будет временной переменной.
Савва Насыров, речь не про компилятор, а про IDE. Это разное. А если прям выпендриваться, то это ошибки компоновщика, а не компилятора. Ошибки из-за того, что срр файлы с классами EventArg не компилируются вообще, либо объектные файлы куда-то в другое место скомпилировались. Через CMake генерируете файл проекта, открываете его в IDE и видите все свои ошибки создания проекта, каких файлов не хватает и почему не компилируется.
Савва Насыров, Рекомендую испоьзовать какую-нибудь IDE, а не через командную строку собирать. Собирать проекты вручную вам потребуется примерно ноль раз в жизни, не в девятнадцатом веке живём, всё-таки. Под виндоус проще всего в Microsoft Visual Studio. Community Edition бесплатная с офф.сайта скачивается. Там любой пример или туториал посмотри и будет понятно, как добавлять файлы в процект, как компилировать, отлаживать и прочее.
Савва Насыров, Я не пользуюсь mingw, не знаю тонкостей сборки. По кодам ошибки видно, что срр файлы с EventArgs не компилировались. А судя по первой строчке, компилируется только файл terminal.cpp. А надо, чтобы компилировались все срр файлы.
Савва Насыров, деструктор теперь правильный!
static переменные надо в срр файл добавить. В хэдере только их объявления в классе. Инициализацию (вне класса) надо в срр файл перенести.
Савва Насыров, Код классов не пишется в заголовке. Это ты так написал. В хэдере нужно писать определение класса, а реализацию в срр файле. То есть в хэдере только объявление функций должно быть.
pluspwnz, И тебе спасибо за приятные слова :)
Но у этого решения есть минусы. Некотоыре античиты считают любые макросы читерскими программами и может из игры выкинуть. Перед запуском стимовских игрушек может потребоваться или выключать макросы или вообще закрывать программу. Это если будут проблемы с античитом.
Хочешь - поднимай, не хочешь - не поднимай. Вот коммиты лучше для каждой фичи делать отдельно, а не пачкой.
По идее, каждый релиз дистрибутива лучше делать с разной версией, чтобы пользователи могли понять, что нужно обновиться.
Очень подозреваю, что инициализация строк пытается выполниться до инициализации рантайм библиотек, поэтому строки не отрабатывают. Если сделаешь их членами класса Info (не статическими) и инициализируешь в get_instance, аналогично объекту Core, то 100% проблем не будет, потому что не будет уже никаких зависимостей ни от чего. Заодно уберёшь глобальные переменные - сплошные плюсы!
Могу ошибаться, но порядок инициализации глобальных статических переменных не определён. То есть строки могут создасться до VER_MAJOR.
в остальном вроде extern правильно используется и должно бы работать.
Сперва создай мастером стандартное консольное приложение, выводяее хело ворлд и убедись, что оно компилируется. А потом уже добавляй туда свои файлы и корректируй main функцию.