Костыли на костылях и норм

в интернете ничего не теряется :)

врядли потерялось. даже у меня все локалраннеры сохранились

новые напишем

тоже мне проблема

Почему компилер ругается на функции в хидере, если у них не прописан inline? Несмотря на то, что эта функция дльаше юзается только в одном cpp файле?

Точнее msvc не ругается и все работает, а g++ не нравится

Если хеддер полключается в нескольких файлах то будет несколько одинаковых функций. Компилятор не знает, какую использовать

Вообще хидер не должен включаться больше одного раза же

Каждый файл компилится отдельно и получает эту функцию. А при линковке они перекрываются и все палает

Хеддер не велючается больше одного раща в рамках одного файла

Компилятор не знает в какие еще cpp-файлы включается хедер, потому что он обычно компилирует один cpp-файл за раз. Если этот хедер включается еще куда-то, а потом это вместе линкуется, будет ODR violation, что есть UB.

Все ясно

А если прописать инлайн то копия функции будет в каждом файле? Или она реально инлайнится?

копия, компилятор может инлайнить функции и без этого, а может не инлайнить и с inline

Я впервые участвовал и сделал вывод про себя, что РАИК - это про борьбу с внутренним перфекционизмом. Это про скорость без багов, т.е. спортивное программирование с очень небольшой добавкой промышленного программирования (код надо понимать не 2 часа, а 20 дней, но это не сильно отличается, если все 20 дней с ним живёшь). А архитектура - не нужна, не окупается. У тебя все 20 дней в голове прочные структуры, которые удерживают архитектуру, нет необходимости выражать это в коде (некому передавать, даже себе в будущем не надо, все 20 дней - это здесь и сейчас). И гибкость. Это когда видишь красивое вкусное алгоритмичное решение, а нужно смотреть игры и делать быстро 5 костылей вместо этого. А потом ещё 5, чтобы не снесло вниз конкурентами, и ещё, и ещё. Это вообще больно промышленному программисту или архитектору. Но очень полезная практика гибкости. Именно в этой задаче это было сильно заметно. И ещё задачи мало выходили за пределы простых олимпиадных алгоритмов, даже специалист в этой области GreenTea проиграл тем, кто спортсмен и много разнообразных эвристик фигачил. Очень хотелось бы уже почитать статьи, конечно. Для себя сделал выводы быть более гибким и искать простые грязные быстрые эффективные улучшения, меньше думать об архитектуре. У меня тоже по неопытности и по привычке было немало размышлений об архитектуре, и в конце концов пришёл к тому, что никакие паттерны не нужны, кроме декомпозиции (ну разве что словарик usedEntities между подсистемами передавать, если это можно назвать паттерном), да и то необязательно, потому что декомпозиция 20 дней в голове, и этого достаточно.

Понял, спасибо

Кстати, кто как связывает данные с юнитами? Я вот на С++ пишу, и не мог хранить прямо в Entity, потому что у меня их было несколько копий. Поэтому сначала хранил в мапе, но это неудобно, поэтому сделал внутри сущности указатель на структуру , которую держу у себя внутри стратегии.

Ну вот поэтому я задумался, может это не моё, накидывал костылей я ровно два дня потом видеть это не мог, поэтому переписал все со стратегией с шаблонным методом для бфс, с фабрикой для юнитов

Я мало чего хранил, но unordered_map для id -> data хватило. Там оврхед ничтожный по сравнению с BFS-ами и венгерским алгоритмам. Ну ещё есть прямой доступ id->Entity (массив).