А ще питають такі:
— А на чому писати збираєшся?
— На C++ та #QML авжеж! (Хоча зараз думаю, що легше на Python+QML)
— У-у-у-у… Наші люди тільки на сішарпі та ангулярі вміють…

І важко їх звинуватити в чомусь. The #Qt Company просрала можливість зайняти нішу на десктопах (та й на решті систем втрачає позиції). Шкода, бо QML сама по собі дуже прикольна 😢 Але недовго їй лишилось, мабуть.

Щойно написав свій перший у житті концепт 😎 Читається зна-а-а-ачно приємніше за ваші std::enable_if_t.

Чому std::same_as, а не std::convertible_to? Бо хочу уникати зайвих implicit castʼів в цьому випадку.

#cpp #Qt #fmtlib

#Qt 😢

В плюсах доволі нерідко перевантажують метод залежно від того, чи сталим є сам обʼєкт, чи ні. Ну, наприклад, контейнер може оголошувати метод, що повертає ітератор на початок якось так (спрощено):

T* MyContainer::begin();
const T* MyContainer::begin() const;

тобто якщо обʼєкт сталий, то і вказівник повертає такий, через який не можна поміняти те, на що він вказує, а якщо обʼєкт мутабельний, то і вказівник теж.
(Якщо ви не в темі, то отой const, що після дужок, фактично відноситься до неявного this, який потрапляє в метод).

Але в QHash (хеш-мапа в #Qt) оператор для доступу до елемента по ключу, як ми сьогодні з друганами виявили в ході обговорення, якогось хєра оголошений отак:

T& operator[](const Key& key);
const T operator[](const Key& key) const;

На перший погляд, все ок 🙂 Окрім того незначного факту, що константний оператор якогось хєра повертає не const T& (тобто не референс), а const T 🤯 Іншими словами, воно щоразу те значення, яке ви дістаєте з хеш-мапи по ключу для читання, зайвий раз копіює.

Фішка в тому, що ніхто в C++ ніколи не повертає const T, бо це безглуздо. Повертають або просто T, або const T&. Тож я вангую, що це баг, про який компілятор вам ніколи нічого не скаже, бо з його погляду все в порядку.

Зайве нагадування про те, що всі ці бібліотеки, котрими тисячі або навіть мільйони людей користуються, пишуть не якісь суперпрограмісти, а такі ж посередні, як ми всі з вами 😎😂