Могу ли я предположить, что игровой движок -- это небольшая часть конкретного игрового проекта и тот прессинг багов и нереализованных хотелок, про который упоминает автор статьи, относится не к игровому движку?
https://en.cppreference.com/w/cpp/links/libs -- этот список никакой не "официальный" Не знаю как сейчас, а несколько лет назад на cppreference можно было зарегистрироваться и внести изменения в wiki-страничку со списком библиотек. Так что там список того, что успели и не поленились добавить на эту wiki-страничку. Попасть в список awesome-cpp чуть сложнее, там (емнип) PR отправлялся и этот PR ждал пока его примут.
Потому что ее нет, вот и кажется, что это манна небесная. А как появится, как распробуем, так и начнем мечтать еще о чем-то недоступном в ожидании чуда :)
Я хочу сказать, что в интернете уже столько развенчаний мифов о UB с наглядными примерами того, как UB стреляет по ногам, что нужно быть очень высокого мнения о себе чтобы пускаться в рассуждения о детерминизме компилятора.
Названия в CAPS_LOCK-е принято давать в C-шных макросах. Поэтому если вы у себя в проекте подключаете заголовок из чисто-сишной либы, то к вам могут прилететь макросы, о которых вы даже не подозреваете. И ваш код начнет вести себя непредсказуемо (хорошо хоть, что в основном во время компиляции).
Я так когда-то наступил на грабли с названием LOG_ERR (или чем-то подобным).
Названия перечислений и константные значения, на сколько я помню, принято указывать заглавными буквами.
Семантика слова reset подразумевает установку первоначального значения.
Как бы reset означает сброс того, что было установлено раньше. Будет ли результат reset-а начальным значением или нет -- это уже от предметной области зависит.
Тогда как со стороны он выглядит конструктивной критикой. И решение ваше простым не является, и по поводу именования методов полностью согласен с предыдущим оратором.
ЗЫ. С собственными решениями всегда так. По началу они нравятся, хочется поделиться с народом удовольствием о того, что удалось придумать, сделать и заставить работать. Однако, не редко, годика эдак через три-четыре-пять, сам уже бываешь не рад и осознаешь, что нужно было делать проще.
А вы уверены, что в C++ эта штука не является UB? ЕМНИП, обращение к неактивному элементу union-а в C++ -- это UB.
И еще я не уверен, что в C++ есть гарантия того, что распределение битовых полей идет от самых младших битов к старшим. Вроде как ничего не мешает распределять и от старших битов к младшим и это зависит от платформы и компилятора.
Что пока в стандарте C++ нет чего-то полезного всегда можно попробовать сделать это через Ж дендро-фекальным методом, чтобы благодарные потомки, кому не повезет сопровождать подобный код в будущем, вспоминали автора этих наворотов незлым тихим словом.
то позаботьтесь хотябы о виртуальном деструкторе в этом базовом классе, иначе все эти ваши std::shared_ptr до лампочки.
Разделяю ваше мнение по поводу уровня статьи и подозрения о том, что автор плохо знает C++. Но как раз в случае с std::shared_ptr наличие виртуального деструктора в базовом классе не всегда необходимо, т.к. shared_ptr умудряется вызывать деструктор именно того класса, который был в shared_ptr передан: https://wandbox.org/permlink/yNve1UFjSbaJCHx6
Хочется верить, что автор статьи знает про эту особенность и намеренно ее использует. Но, боюсь, это у него случайно получилось.
Вообще-то спецификация исключений из C++98 не проверялась в compile-time (это не был аналог checked exceptions из Java). Проверка делалась в run-time и вызывался std::terminate если вылетало исключение другого типа. Но сам компилятор по рукам за попытку бросить исключение из функции с декларацией throw не бил вообще.
Короче говоря, была абсолютно бесполезная и, местами, даже вредная штука.
В плюсы позднее завезли частный случай с noexcept, но это для экономии на спичках.
Это как бы вообще не аналог. Ну вот совсем. И назначение у noexcept другое, а именно -- показать насколько безопасно вызывать функцию/метод в специфических контекстах (например, в деструкторах, секциях catch, в других noexcept-функциях, вроде swap или move operator).
Вообще говоря, это очень плохо, потому что фактически неизвестен полный тип функции, а именно какие исключения она может вышвырнуть.
Если проект нормальный, то все исключения там (прямо или косвенно) наследуются от std::exception. Так что это не такая большая проблема, как об этом говорят.
У вас не получилось донести свою мысль (если таковая вообще была).
Можно предположить, что вы недовольны тем, что после появления STL разработчики на C++ стали активно использовать шаблоны. Возможно вы про это.
Ну так у меня для вас плохие новости. Шаблоны в C++ появились еще до появления STL, и начали широко использоваться (насколько это допускали тогдашние компиляторы) еще до того, как STL вошла в стандарт C++. И даже до того, как этот самый стандарт C++ был принят.
Звучит так, что "долгоживущий код" -- это редкость.
А зачем их брать? Или вы их тоже ревьювите?
Могу ли я предположить, что игровой движок -- это небольшая часть конкретного игрового проекта и тот прессинг багов и нереализованных хотелок, про который упоминает автор статьи, относится не к игровому движку?
https://en.cppreference.com/w/cpp/links/libs -- этот список никакой не "официальный"
Не знаю как сейчас, а несколько лет назад на cppreference можно было зарегистрироваться и внести изменения в wiki-страничку со списком библиотек. Так что там список того, что успели и не поленились добавить на эту wiki-страничку. Попасть в список awesome-cpp чуть сложнее, там (емнип) PR отправлялся и этот PR ждал пока его примут.
А насколько в игрострое распространены случаи, когда однажды написанная кодовая база затем эксплуатируется и развивается на протяжении 10 и более лет?
Стандарт с C++20, но там есть свои особенности.
Потому что ее нет, вот и кажется, что это манна небесная. А как появится, как распробуем, так и начнем мечтать еще о чем-то недоступном в ожидании чуда :)
Я хочу сказать, что в интернете уже столько развенчаний мифов о UB с наглядными примерами того, как UB стреляет по ногам, что нужно быть очень высокого мнения о себе чтобы пускаться в рассуждения о детерминизме компилятора.
Похоже, вы сейчас пытаетесь мне объяснить, что UB в C++ном коде -- это нормально? Ну ну, ну ну.
Если бы.
Названия в CAPS_LOCK-е принято давать в C-шных макросах.
Поэтому если вы у себя в проекте подключаете заголовок из чисто-сишной либы, то к вам могут прилететь макросы, о которых вы даже не подозреваете. И ваш код начнет вести себя непредсказуемо (хорошо хоть, что в основном во время компиляции).
Я так когда-то наступил на грабли с названием LOG_ERR (или чем-то подобным).
В Java :)
Что-то мне подсказывает, что вы еще очень молоды.
Как бы reset означает сброс того, что было установлено раньше. Будет ли результат reset-а начальным значением или нет -- это уже от предметной области зависит.
Вновь поддержу предыдущего оратора. set устанавливает, reset сбрасывает.
Т.е. если кто-то вызывал:
то я ожидаю, что условная функция проверки
is_setвернет true:Тогда как reset ведет к тому, что
is_setвернет false:Как признак set/unset будет хранится внутри -- это безразницы, хоть ноликом, хоть единичкой.
PS. И да, не стоит в C++ давать идентификаторам названия в ИСКЛЮЧИТЕЛЬНО_ВЕРХНЕМ_РЕГИСТРЕ. Прямой путь к проблемам при интеграции с C-шным кодом.
Тогда как со стороны он выглядит конструктивной критикой. И решение ваше простым не является, и по поводу именования методов полностью согласен с предыдущим оратором.
ЗЫ. С собственными решениями всегда так. По началу они нравятся, хочется поделиться с народом удовольствием о того, что удалось придумать, сделать и заставить работать. Однако, не редко, годика эдак через три-четыре-пять, сам уже бываешь не рад и осознаешь, что нужно было делать проще.
А вы уверены, что в C++ эта штука не является UB?
ЕМНИП, обращение к неактивному элементу union-а в C++ -- это UB.
И еще я не уверен, что в C++ есть гарантия того, что распределение битовых полей идет от самых младших битов к старшим. Вроде как ничего не мешает распределять и от старших битов к младшим и это зависит от платформы и компилятора.
Что пока в стандарте C++ нет чего-то полезного всегда можно попробовать сделать это через Ж дендро-фекальным методом, чтобы благодарные потомки, кому не повезет сопровождать подобный код в будущем, вспоминали автора этих наворотов незлым тихим словом.
Разделяю ваше мнение по поводу уровня статьи и подозрения о том, что автор плохо знает C++.
Но как раз в случае с std::shared_ptr наличие виртуального деструктора в базовом классе не всегда необходимо, т.к. shared_ptr умудряется вызывать деструктор именно того класса, который был в shared_ptr передан: https://wandbox.org/permlink/yNve1UFjSbaJCHx6
Хочется верить, что автор статьи знает про эту особенность и намеренно ее использует. Но, боюсь, это у него случайно получилось.
Вообще-то спецификация исключений из C++98 не проверялась в compile-time (это не был аналог checked exceptions из Java). Проверка делалась в run-time и вызывался std::terminate если вылетало исключение другого типа. Но сам компилятор по рукам за попытку бросить исключение из функции с декларацией throw не бил вообще.
Короче говоря, была абсолютно бесполезная и, местами, даже вредная штука.
Это как бы вообще не аналог. Ну вот совсем. И назначение у noexcept другое, а именно -- показать насколько безопасно вызывать функцию/метод в специфических контекстах (например, в деструкторах, секциях catch, в других noexcept-функциях, вроде swap или move operator).
Если проект нормальный, то все исключения там (прямо или косвенно) наследуются от std::exception. Так что это не такая большая проблема, как об этом говорят.
И вот прямо в пространстве имен
std::?Что-то мне подсказывает, что это вряд ли была распространенная практика.
И еще больше подозрений, что внезапно замолчавший @mmMike имел в виду именно такие случаи.
Вы пришли на публичную площадку и высказались так, что вас оказалось непросто понять. Например (лишнее поскипано):
Что такое "STL класс"?
STL -- это standard template library. Как кто-то может взять и определить класс из standard template library?
У вас пытаются выяснить что вы имеете в виду, вы не можете ничего внятного ответить. Выяснить же пытаются для того, чтобы понять что вы сказали.
Если вам пофиг на то, что ваши же слова пытаются воспринять всерьез, то OK.
У вас не получилось донести свою мысль (если таковая вообще была).
Можно предположить, что вы недовольны тем, что после появления STL разработчики на C++ стали активно использовать шаблоны. Возможно вы про это.
Ну так у меня для вас плохие новости. Шаблоны в C++ появились еще до появления STL, и начали широко использоваться (насколько это допускали тогдашние компиляторы) еще до того, как STL вошла в стандарт C++. И даже до того, как этот самый стандарт C++ был принят.
Так а при чем здесь STL вообще?