Именно по этой причине грамотные программисты предпочитают выравнивать звездочки вправо, а cv-спецификаторы - влево.
А другие не менее грамотные программисты предпочитают east-const. ИМХО: читая код сверху вниз гораздо приятнее прыгать по типам прямо, а не зигзагом. Наличие const при этом имеет второстепенное значение.
С нецелыми коэффициентами могут быть погрешности округления, из-за которых интерфейс на границах контролов будет моргать. В целом подход с логическими/физическими пикселями, принятый на вооружение Qt и WxWidgets, меня полностью устраивает.
В C++20 вместе с этим оператором завезли ещё такой breaking change: при упорядочивании двух std::pair с помощью operator< будет использоваться operator<=> на компонентах этой пары. Это может выстрелить в классах, у которых есть операторы неявного приведения, потому что operator<=> предпочтёт другой operator<=>, даже если в классе уже есть написаный руками operator<, а для сравнения нужно приведение типов.
Странно видеть такой код в новом стандарте, после того как со всех утюгов доносилось про божественность deducing this и как классно будет жить без C, R и T в CRTP.
https://habr.com/ru/companies/jugru/articles/506104/
Больше похоже на остатки отладочного кода. Так и вижу внутри какой-нибудь printf, который впоследствии удалили.
Только в отладке.
А что случилось с полпозалом про
_? Почему вместо него решили сделатьauto [a [[maybe_unused]], b] = foo();?Ребята из LLVM не сидят в сторонке и тоже пилят свой libc:
https://libc.llvm.org/
А другие не менее грамотные программисты предпочитают east-const.
ИМХО: читая код сверху вниз гораздо приятнее прыгать по типам прямо, а не зигзагом. Наличие const при этом имеет второстепенное значение.
Why?
Практика показывает, что если какой-то пуш с рекламой очень хотят отправить, то на категорию кладут огромный болт.
Так не пойдет, если таргетов несколько.
Уберите ссылку на Bromite из статьи, он уже год как заброшен. Вместо него Cromite.
С нецелыми коэффициентами могут быть погрешности округления, из-за которых интерфейс на границах контролов будет моргать.
В целом подход с логическими/физическими пикселями, принятый на вооружение Qt и WxWidgets, меня полностью устраивает.
В C++ да, в C нет.
... и получить на выходе Qt! /s
4K это такая штука, про которую если на этапе проектирования забыть/забить, то потом придется всё перелопачивать.
В C++20 вместе с этим оператором завезли ещё такой breaking change: при упорядочивании двух
std::pairс помощьюoperator<будет использоватьсяoperator<=>на компонентах этой пары. Это может выстрелить в классах, у которых есть операторы неявного приведения, потому чтоoperator<=>предпочтёт другойoperator<=>, даже если в классе уже есть написаный рукамиoperator<, а для сравнения нужно приведение типов.Data members как пример того, где может понадобится информация о типе.
Ок, я совсем забыл про data members (facepalm)
Странно видеть такой код в новом стандарте, после того как со всех утюгов доносилось про божественность deducing this и как классно будет жить без C, R и T в CRTP.
С такой целью в boost недавно завезли boost-compat. А ещё разработчики компиляторов собираются бэкпортировать
import stdв C++20.В rhel7 есть devtoolset12, так что можно смело пользоваться
std::to_chars.В основном всё упирается в финансирование для CI.