Я хочу сказать, что в интернете уже столько развенчаний мифов о 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++ был принят.
Хотите про объективную реальность и ощущения - давайте.
Про ощущения: есть у меня сомнения в вашем психологическом здоровье (в медицинском смысле), но их высказывание на таком ресурсе, как Хабр, приведет разве что к заминусовыванию кармы, так что оставлю их при себе.
Заодно и про логику
Про реальность: вы не можете в логику, что прекрасно видно по тексту вашего комментария.
Соответственно: оставить здесь комментарий чтобы пнуть вас в ваше очередное заблуждение -- это еще куда ни шло. А вот пытаться вам что-то объяснить... Ну уж нет. Не за бесплатно. Да и за деньги вряд.
Те, которые являются единицами диспетчеризации в многозадачных ОС с поддержкой вытесняющей многозадачности, и на CPU с несколькими вычислительными ядрами -- да. Это как бы объективная реальность данная нам в ощущениях.
Я предлагаю сравнить инструменты доступные Микеланджело и современному профессиональному художнику.
Это у тех, кто пишет маслом по холсту? Ну сравните. Интересно какой прогресс в кистях и палитрах вы обнаружите. Хотя химический состав красок, наверняка, далеко ушел вперед.
Скорее народная мудрость.
Какая именно?
Так и вы пришли учить Java-ов сейчас )
И тут бы ссылку на мои слова о том, где я бы говорил хоть что-то о том, как следует программировать на Java.
достаточно посмотреть на инструменты разработки которые большинство использует.
Т.е. вы предлагаете об уровне работ Микеланджело или Рафаэля судить по их кистям и палитрам? O_o
Я опросы не проводил. Но 99% стандартное правило.
Опросы не проводили, но выводы делаете. Отлично.
Про 99% -- это какое такое правило?
У меня опыт С++ тогда тоже был.
Но пришли учить C++ников программировать сейчас.
Высказал свои мысли
Ваш первый комментарий не похож на мысли, он поход на утверждение. Которое было бы желательно чем-то подтвердить. Однако, пока что все идет к тому, что ваши слова это обычный интернетовский бла-бла-бла.
Доказываю делами - опубликованными проектами.
Которые не в опенсорсе и на которые ссылки искать лень. Понятно.
О как... Мне иногда кажется, что современным говнокодерам до программистов из 90-х никогда не дорасти, но я из своей крошечной выборки никаких выводов не делаю. А вы, надо полагать, лично знакомы с кодом большинства программистов, отсюда и такие глобальные выводы.
Зачем, мне грубо говоря метать бисер перед свиньями?
Т.е. вы один здесь такой в белом пОльто стоите красивый?
Здесь бы я вернул ваши аргументы, зачем вы лезете туда, где у вас нет опыта работы?
Как раз опыт работы на Java у меня был.
В моём IoC фреймворке используется, но он ещё не в опенсорц. Ссылку искать лень.
Да, с аргументацией у вас как-то совсем слабенько. Предлагаете просто верить вам на слово?
Я хочу сказать, что в интернете уже столько развенчаний мифов о 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 вообще?
Про ощущения: есть у меня сомнения в вашем психологическом здоровье (в медицинском смысле), но их высказывание на таком ресурсе, как Хабр, приведет разве что к заминусовыванию кармы, так что оставлю их при себе.
Про реальность: вы не можете в логику, что прекрасно видно по тексту вашего комментария.
Соответственно: оставить здесь комментарий чтобы пнуть вас в ваше очередное заблуждение -- это еще куда ни шло. А вот пытаться вам что-то объяснить... Ну уж нет. Не за бесплатно. Да и за деньги вряд.
Некоторые даже пытались общаться с автором. Чтобы сделать вывод, что лучше впредь таких ошибок не повторять.
Те, которые являются единицами диспетчеризации в многозадачных ОС с поддержкой вытесняющей многозадачности, и на CPU с несколькими вычислительными ядрами -- да. Это как бы объективная реальность данная нам в ощущениях.
Это у тех, кто пишет маслом по холсту? Ну сравните. Интересно какой прогресс в кистях и палитрах вы обнаружите. Хотя химический состав красок, наверняка, далеко ушел вперед.
Какая именно?
И тут бы ссылку на мои слова о том, где я бы говорил хоть что-то о том, как следует программировать на Java.
Т.е. вы предлагаете об уровне работ Микеланджело или Рафаэля судить по их кистям и палитрам? O_o
Опросы не проводили, но выводы делаете. Отлично.
Про 99% -- это какое такое правило?
Но пришли учить C++ников программировать сейчас.
Ваш первый комментарий не похож на мысли, он поход на утверждение. Которое было бы желательно чем-то подтвердить. Однако, пока что все идет к тому, что ваши слова это обычный интернетовский бла-бла-бла.
Которые не в опенсорсе и на которые ссылки искать лень. Понятно.
О как... Мне иногда кажется, что современным говнокодерам до программистов из 90-х никогда не дорасти, но я из своей крошечной выборки никаких выводов не делаю. А вы, надо полагать, лично знакомы с кодом большинства программистов, отсюда и такие глобальные выводы.
Т.е. вы один здесь такой в белом пОльто стоите красивый?
Как раз опыт работы на Java у меня был.
Да, с аргументацией у вас как-то совсем слабенько. Предлагаете просто верить вам на слово?