Почему вы НЕ будете использовать свой движок? (3 стр)

потому что никогда его не допишу

jaguard
что же за игры вы пишете?

Была тема , какие ключевые слова не используете в c++?

И ты , по-моему, не использовал слово class...

Как это НЕ буду?!
БУДУ!
Вот увидите!

slava_mib

Misanthrope

Я вижу исходный код
Я слышу генератор шумов
Если один скажет - делать игру
Миллионы ответят - писать свой движок!

потому что много лет пробовал, не скажу что время потеряно - понял как что работает в двигах.
теперь-то я, как и многие, уже стар для этого д@рьма )), тут хоть бы успеть что-то написать.. ) ковыряю Юнити и Анрыл. мрачновато, конечно,  но...  что-то получается.  хоть Юнька и тормозит у мну изкаробки, если графоний чуть навернуть.  а если убогий - все равно позорные фпс кажет для такого графония.  понимаешь,  что сам мог намного шустрее,  но время..  и возможности..  и фичи..

Дезанизатор
> Была тема , какие ключевые слова не используете в c++?
>
> И ты , по-моему, не использовал слово class...

Хренассе у тебя память. Той теме 8 лет исполнилось :). Только я про class не говорил.

Я по-прежнему почти не использую большую часть тех ключевых слов, что я в той теме указывал: dynamic_cast и прочие *cast, try/throw (использовал throw пару раз чисто для дебага, типа conditional breakpoint), namespace (этот мне в принципе по душе, мало использую в основном от лени), перегрузку операторов и сложные template. Слово template стал в принципе использовать только с текущего проекта для небольшого сахарку, также с этого же проекта стал перегружать оператор () для нескольких простых классов с той же сладкой целью (фактически, геттер). У меня всё так же виртуальные функции имеют быть в единственном классе "GameMode".
По прежнему не выношу визуального вида STL, и в целом бесит оформление кода с подчеркиваниями. По этой же причине ненавижу size_t.

Но не использовать class.. Это уже слишком странно. Без наследования и ООП я бы обошелся, но класс весьма удобен как контейнер для переменных и функций.

Дезанизатор
> что же за игры вы пишете?

Всякие. Шутеры, стратегии, платформеры, аркады..

jaguard
> По прежнему не выношу визуального вида STL, и в целом бесит оформление кода с
> подчеркиваниями.
Я тоже, поэтому написал свою либу на замену STL. Может и тебе пригодится? Она лучше STL не только оформлением кода, но и много чем ещё.

jaguard
> Но не использовать class.. Это уже слишком странно. Без наследования и ООП я бы
> обошелся, но класс весьма удобен как контейнер для переменных и функций.
struct же есть. По-моему как контейнер переменных и функций он лучше подходит, чем class. Там сразу всё public.

jaguard
> Я по-прежнему почти не использую большую часть тех ключевых слов, что я в той
> теме указывал: dynamic_cast и прочие *cast, try/throw (использовал throw пару
> раз чисто для дебага, типа conditional breakpoint), namespace (этот мне в
> принципе по душе, мало использую в основном от лени), перегрузку операторов и
> сложные template.
Я вот до недавнего времени тоже не использовал всё перечисленное кроме перегрузки операторов - её использовал в велосипедных контейнерах и в векторах/матрицах. Но в последний год завернул всю свою либу в разные namespace и пристрастился к сложным шаблонам. До этого думал, что все эти сложности с шаблонами нафиг не нужны, но постепенно стала возникать необходимость, которую я всячески избегал. В конечном счёте я докатился до такого состояния, что теперь не представляю, как без них можно жить. Они позволяют вытворять крутые вещи, используя которые можно неплохо сократить и улучшить код. И это всё дело неплохо инлайнится, поэтому производительность не теряется - можно заворачивать в шаблоны даже самые мелкие вещи. Правда все эти костыли типа SFINAE не очень приятно писать. Но я сделал свой аналог type_traits, менее вырвиглазный.
Исключения не использую, потому что не нашёл области, где они могли быть полезны, а не запутывали бы только код. Я не вижу ничего такого особенного в обработке ошибок, что отличало бы их от любого другого кода так, что для этого потребовался бы специальный механизм исключений. По-моему все ошибки обрабатываются на месте и передавать их выше не нужно. Максимум, что может быть нужно для обработки ошибки - вернуть флаг о том, была ли функция выполнена успешно. А причину можно писать например в лог.
Специальные касты не использовал, но стал использовать скорее потому, что это правила хорошего тона в C++ и чтобы мою либу не критиковали за их нарушение. И ещё потому, что в GCC и Clang есть warning -Wold-style-cast, а я пытаюсь сделать так, чтобы моя библиотека компилировалась без предупреждений даже если её пользователь любит включать всевозможные предупреждения.
dynamic_cast не использую, потому что его наличие указывает на косяки в архитектуре, а я пытаюсь сделать идеальную архитектуру своей библиотеки.

jaguard
> У меня всё так же виртуальные функции имеют быть в единственном классе "GameMode".
Ну вообще это мощный инструмент, если его правильно использовать. Я считаю, что ими часто злоупотребляют, но и не использовать их совсем тоже не очень хорошо. Без них программа становится очень негибкой.

jaguard
> По прежнему не выношу визуального вида STL, и в целом бесит оформление кода с
> подчеркиваниями. По этой же причине ненавижу size_t.
Дружище

А вот в ue4 всё своё, и контейнеры и тайп трейты и делегаты и указатели, и всё по заветам и канонам.

gammaker
> Я тоже, поэтому написал свою либу на замену STL. Может и тебе пригодится? Она
> лучше STL не только оформлением кода, но и много чем ещё.

Я все-таки не настолько ненавижу STL, чтобы брать неизвестную либу с неизвестно какими потенциальными эффектами. Да и нужны мне stl-style контейнеры ну очень редко.

> struct же есть. По-моему как контейнер переменных и функций он лучше подходит,
> чем class. Там сразу всё public.

Не, идеологически struct для POD, если там функции, это уже нарушает смысл.

> шаблонами нафиг не нужны, но постепенно стала возникать необходимость, которую

Я больше 10 лет думал, что не нужны, теперь у меня более спокойное мнение типа "где-то пожалуй и пригодились бы, но без них можно обойтись". Еще через 10 может и посложнее начну писать выркутасы :).

> я всячески избегал. В конечном счёте я докатился до такого состояния, что
> теперь не представляю, как без них можно жить. Они позволяют вытворять крутые
> вещи, используя которые можно неплохо сократить и улучшить код. И это всё дело

Сам код может и улучшается, а вот код, который все это обеспечивает, наверняка write-only какашка, просто иначе не получится.
А я не очень люблю подобный код. Плюс сложные шаблонокостыли провоцируют невнятные или просто жуткие ошибки компилятора (не в смысле компилятор ошибается, а само сообщение об ошибке когда ты какой-нибудь оператор пропустил).

> сделать так, чтобы моя библиотека компилировалась без предупреждений даже если
> её пользователь любит включать всевозможные предупреждения.

Ну в общем не от хорошей жизни. Понятно что C++ касты более безопасны, но если ты понимаешь что ты делаешь, ты не будешь кастовать array в map.

> Ну вообще это мощный инструмент, если его правильно использовать. Я считаю, что
> ими часто злоупотребляют, но и не использовать их совсем тоже не очень хорошо.
> Без них программа становится очень негибкой.

Да я хорошо понимаю, как их можно использовать, и даже был соблазн - но ничего особенного я не потерял. Можно было сделать чуть более красиво в паре мест, но это сущая мелочь.

Но впрочем, я запамятовал - есть еще один класс, где я использовал виртуальные функции весьма к месту - моя реализация behavior tree, там кучка мелких классов, в каждом кода на 2-10 строчек. С другой стороны, это не так чтобы прям кардинально читабельнее, чем длинный switch/case - разница была бы заметнее, если бы каждый класс имел больше одной функции. И при добавлении нового класса мне нужно дописывать код в 5 местах, а с switch/case - только в 2-х.

jaguard
> Я все-таки не настолько ненавижу STL, чтобы брать неизвестную либу с неизвестно
> какими потенциальными эффектами.
Я пока и сам не рекомендую её использовать в продакшене. Но я просто чисто теоретически предположил, что тебе может быть интересно хотя бы взглянуть, хотя бы на примеры в гите. У меня там кроме контейнеров куча других полезностей. Я даже уже давно не позиционирую контейнеры главной фичей либы.
Теперь у меня главная фича - диапазоны. Во-первых, они являются более удачной абстракцией, чем итераторы. А во-вторых, они умеют производить ленивые вычисления. Это позволяет легко и красиво решить проблему, когда у тебя данные в коллекции в одном формате, а алгоритм принимает входные данные в другом формате. Вместо того, чтобы копипастить алгоритм или перегонять структуры из массива в массив, просто передаёшь свой массив и преобразующую функцию\лямбду в нужный формат.
Я не знаю, как для тебя, но для меня это была одна из самых главных проблем, когда я решил провести эксперимент и писать программу для своей учебно-исследовательской работы на STL вместо своей либы. Размер проекта был 3000 строк кода. Проблема заключалась в том, что выходные данные одного алгоритма являлись входными данными для другого, но содержали больше полей, чем ему нужно. В итоге приходилось перегонять массив больших структур в массив структур с меньшим количеством полей. Это был далеко не единственный случай, и я запарился делать это. А ещё замучался сохранять данные в бинарный и текстовый файл, когда у меня в либе есть крутой автоматический сериализатор.

jaguard
> Не, идеологически struct для POD, если там функции, это уже нарушает смысл.
Это в твоём понимании. А по стандарту наличие методов никак не влияет на POD'овость.

jaguard
> Сам код может и улучшается, а вот код, который все это обеспечивает, наверняка
> write-only какашка, просто иначе не получится.
Со своими трейтами в Meta/Type.h выглядит вполне прилично. Разве что сами трейты можно назвать "write-only какашкой", но я всеми силами старался, чтобы всё остальное выглядело как можно лучше. И, я считаю, у меня это вполне получилось.

jaguard
> Плюс сложные шаблонокостыли провоцируют невнятные или просто жуткие ошибки
> компилятора (не в смысле компилятор ошибается, а само сообщение об ошибке когда
> ты какой-нибудь оператор пропустил).
Это скорее проблема STL, потому что она не использует SFINAE. Если "случайно" написать что-нибудь вроде std::copy(4, 8, arr), то компилятор выдаст жуткую ошибку, где с трудом можно будет увидеть, что у int нельзя разыменовывать как указатель. А при вызове моей аналогичной функции, которая проверяет наличие у типа нужных методов и операторов, компилятор просто скажет, что нет соответствующей перегруженной функции. И в зависимости от того, какой компилятор, он может показать список всех кандидатов, которые не подошли. Посмотрев на условия этих кандидатов, которые достаточно аккуратно оформлены, можно понять, почему они не выполняются.

jaguard
> Понятно что C++ касты более безопасны, но если ты понимаешь что ты делаешь, ты
> не будешь кастовать array в map.
В шаблонном коде может много чего случиться. Правда я вроде пока ещё не сталкивался с неверными кастами.

Раз уж пошел разговор. Поцоны, где modern-c++ сейчас вообще применяется? Ну, кроме олимпиадных задачек и всяких вспомогательных библиотек, которые вообще по хер на чем пилить, хоть на фортране. А то куда ни ткни - везде велосипедизм, олд-скульный ортодоксал и сбоку ц торчат. Интересуют продукты масштаба и шоукейса уровня Qt, например.

beejah
> Поцоны, где modern-c++ сейчас вообще применяется? Ну, кроме олимпиадных задачек
> и всяких вспомогательных библиотек
Ну как бы игровые движки. Даже в UE4 C++ вместо своего скриптового сделали.
Ну и в науке вроде C++ популярен, особенно там, где нужны высокопроизводительные вычисления. Биоинформатика например.

gammaker
> UE4
Так вроде говорили, там своя инфраструктура, с велосипедами.

beejah
Там не используется std и странный кодестайл. В остальном с++, как он есть.
И низкий уровень Юньки тоже на нем. Не говоря уж про кучу менее популярных двигов. Это жабы в геймдеве не сыщешь, а с++ повсюду.

Не понимаю за что вы ненавидите STL, вполне хорошая штука.