Как стать автором
Обновить
86
0.2
Евгений Охотников @eao197

Велосипедостроитель, программист-камикадзе

Отправить сообщение

Назначенная инциализация мастхев, но насколько знаю она из мира Си и не совсем стандарт до С++23(?)

Стандарт с C++20, но там есть свои особенности.

почему все так носятся с рефлексией?

Потому что ее нет, вот и кажется, что это манна небесная. А как появится, как распробуем, так и начнем мечтать еще о чем-то недоступном в ожидании чуда :)

Я хочу сказать, что в интернете уже столько развенчаний мифов о UB с наглядными примерами того, как UB стреляет по ногам, что нужно быть очень высокого мнения о себе чтобы пускаться в рассуждения о детерминизме компилятора.

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

Похоже, вы сейчас пытаетесь мне объяснить, что UB в C++ном коде -- это нормально? Ну ну, ну ну.

а не от ваших личных предпочтений

Если бы.

Названия в CAPS_LOCK-е принято давать в C-шных макросах.
Поэтому если вы у себя в проекте подключаете заголовок из чисто-сишной либы, то к вам могут прилететь макросы, о которых вы даже не подозреваете. И ваш код начнет вести себя непредсказуемо (хорошо хоть, что в основном во время компиляции).

Я так когда-то наступил на грабли с названием LOG_ERR (или чем-то подобным).

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

В Java :)

Очередная придирка по пустяку

Что-то мне подсказывает, что вы еще очень молоды.

Семантика слова reset подразумевает установку первоначального значения.

Как бы reset означает сброс того, что было установлено раньше. Будет ли результат reset-а начальным значением или нет -- это уже от предметной области зависит.

Особенно в свете вашего же тезиса о годах спустя

Вновь поддержу предыдущего оратора. set устанавливает, reset сбрасывает.
Т.е. если кто-то вызывал:

bits_collection.set(Condition::INITIALIZED);

то я ожидаю, что условная функция проверки is_set вернет true:

bits_collection.set(Condition::INITIALIZED);
assert(bits_collection.is_set(Condition::INITIALIZED);

Тогда как reset ведет к тому, что is_set вернет false:

bits_collection.reset(Condition::INITIALIZED);
assert(!bits_collection.is_set(Condition::INITIALIZED);

Как признак set/unset будет хранится внутри -- это безразницы, хоть ноликом, хоть единичкой.

PS. И да, не стоит в C++ давать идентификаторам названия в ИСКЛЮЧИТЕЛЬНО_ВЕРХНЕМ_РЕГИСТРЕ. Прямой путь к проблемам при интеграции с C-шным кодом.

А ваш комментарий - придирки по пустякам

Тогда как со стороны он выглядит конструктивной критикой. И решение ваше простым не является, и по поводу именования методов полностью согласен с предыдущим оратором.

ЗЫ. С собственными решениями всегда так. По началу они нравятся, хочется поделиться с народом удовольствием о того, что удалось придумать, сделать и заставить работать. Однако, не редко, годика эдак через три-четыре-пять, сам уже бываешь не рад и осознаешь, что нужно было делать проще.

А вы уверены, что в 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. Так что это не такая большая проблема, как об этом говорят.

И вот прямо в пространстве имен std::?

Что-то мне подсказывает, что это вряд ли была распространенная практика.

И еще больше подозрений, что внезапно замолчавший @mmMike имел в виду именно такие случаи.

Вы пришли на публичную площадку и высказались так, что вас оказалось непросто понять. Например (лишнее поскипано):

я имею в виду чужие исходники (прикладные не либы) где определяется STL класс...

Что такое "STL класс"?

STL -- это standard template library. Как кто-то может взять и определить класс из standard template library?

У вас пытаются выяснить что вы имеете в виду, вы не можете ничего внятного ответить. Выяснить же пытаются для того, чтобы понять что вы сказали.

Если вам пофиг на то, что ваши же слова пытаются воспринять всерьез, то OK.

У вас не получилось донести свою мысль (если таковая вообще была).

Можно предположить, что вы недовольны тем, что после появления STL разработчики на C++ стали активно использовать шаблоны. Возможно вы про это.

Ну так у меня для вас плохие новости. Шаблоны в C++ появились еще до появления STL, и начали широко использоваться (насколько это допускали тогдашние компиляторы) еще до того, как STL вошла в стандарт C++. И даже до того, как этот самый стандарт C++ был принят.

Так а при чем здесь STL вообще?

Хотите про объективную реальность и ощущения - давайте.

Про ощущения: есть у меня сомнения в вашем психологическом здоровье (в медицинском смысле), но их высказывание на таком ресурсе, как Хабр, приведет разве что к заминусовыванию кармы, так что оставлю их при себе.

Заодно и про логику

Про реальность: вы не можете в логику, что прекрасно видно по тексту вашего комментария.

Соответственно: оставить здесь комментарий чтобы пнуть вас в ваше очередное заблуждение -- это еще куда ни шло. А вот пытаться вам что-то объяснить... Ну уж нет. Не за бесплатно. Да и за деньги вряд.

Кто знает, ничего не скажет, промолчит, улыбнется мбыть только.

Некоторые даже пытались общаться с автором. Чтобы сделать вывод, что лучше впредь таких ошибок не повторять.

Или Вы считаете, что потоки работают параллельно?

Те, которые являются единицами диспетчеризации в многозадачных ОС с поддержкой вытесняющей многозадачности, и на CPU с несколькими вычислительными ядрами -- да. Это как бы объективная реальность данная нам в ощущениях.

Я предлагаю сравнить инструменты доступные Микеланджело и современному профессиональному художнику.

Это у тех, кто пишет маслом по холсту? Ну сравните. Интересно какой прогресс в кистях и палитрах вы обнаружите. Хотя химический состав красок, наверняка, далеко ушел вперед.

Скорее народная мудрость.

Какая именно?

Так и вы пришли учить Java-ов сейчас )

И тут бы ссылку на мои слова о том, где я бы говорил хоть что-то о том, как следует программировать на Java.

1
23 ...

Информация

В рейтинге
2 484-й
Откуда
Гомель, Гомельская обл., Беларусь
Зарегистрирован
Активность