C++-комітет продовжує підглядати в спеку Haskell обговорювати нові потенційні фічі для мови. Цього разу (документу вже рік насправді) дійшло до плейсголдерів _, щоб зручно було користуватися зіставленням із взірцем (паттерн-матчінгом), якого звісно досі нема, або, наприклад, розпаковувати кортежі на кшталт:

auto [x, y, _] = f();

Тут типу третє значення нам не суттєве, тож можна використати _, щоб не вигадувати імʼя, а потім боротися з ворнінгами про те, що воно не використовується, додаючи [[maybe_unused]].

Та C++ би не був собою, якби все було так прозоро. Ніщо не заважає вам і зараз використати _ як імʼя змінної:

auto [x, _] = make_pair(1, 2);
cout << x << "," << _ << endl;  // використання

Тож це працюватиме й надалі. Однак інколи хочеться зробити так двічі в одному скоупі, а structured binding — це визначення нової змінної, а не просто запис у ту, що вже існує:

auto [x, _] = make_pair(1, 2);
auto [_, y] = make_pair(3, 4);

Зараз такий код генерує error: conflicting declaration ‘auto _’, бо це повторна декларація змінної, а от з новим пропоузалом перестане.

Тобто можна навіть вручну скільки завгодно разів оголошувати змінну _, і жодних проблем… доти, доки не спробувати звернутися до змінної _ у цьому ж скоупі. Якщо вона оголошена один раз, то можна, а якщо декілька, то це помилка:

auto _ = 42; // Оголошення
auto _ = 0;  // Повторне оголошення
{
    auto _ = 1; // Новий скоуп. Оголошення з шадовінгом
    assert( _ == 1 ); // Можна прочитати
}
assert( _ == 42 ); // Не можна прочитати 🙂

В принципі, очевидно, еге ж?) А, до речі… У неймспейсі двічі не можна оголосити:

namespace a {
    auto _ = f();  // Ок
    auto _ = f();  // Помилка
}

Все логічно, короч 🤡 Ні, заждіть, це не жарт. Все справді логічно, якщо над цим поміркувати достатньо довго! Але капець, як же втомлює тримати подібні нюанси в голові весь час.

З іншого боку шанси, що це увійде в C++26, все одно низькі ) Може в C++32…

Взяв я собі ж R1, як вже згадував. Тижні три чи чотири лежав у мене — ліньки було розпаковувати.

Відтоді, як я його замовив, в інтернетах вже зʼявився 1000001 відос про те, який це скам. І скоріш за все так воно і є. Та я не жалкую, бо разом з ним я отримав річну передплату на Perplexity (власне, за ціною річної передплати). Тож сприймаю це як безплатний пристрій 😅

Що сказати по самому девайсу… Пластик відчувається якимсь дешевим, але загалом пристрій дуже solid. Українською запити ігнорує, але коли просиш перекласти щось з української іншою мовою — робить це без проблем. Концептуально дуже схоже на кишенькову Amazon Alexa, тільки розумнішу й водночас менш спроможну. Alexa хоча б світло може вимкнути 😁

З інтеграцій є тільки Spotify/Apple Music, Uber, DoorDash, Midjorney та Suno. Я ще не настільки сказився, щоб логінитися під своїми акаунтами на чиїхось ремоут-компах, тож протестувати, мабуть, не вийде. Та й нагадую, що їхня хвалена LAM (Large Action Model) наразі виявилася пачкою кривих скриптів під Playwright.

Ютубери та інші тиктокери вже так затролили їхню ШІ-шку, що коли показуєш Реббіту в камеру коробку від харчової добавки, що ветеринар виписав коту, й просиш розказати, що це, воно замість інформації видає текст на хвилину про те, чому воно не може давати мені медичні поради, і як це все небезпечно, і наскільки воно відповідальне і т.д. Доволі useless короч.

Поживу якийсь час з оригінальною прошивкою, а потім може буду джейлбрейкати чи хз.

Ніхто не вміє робити теги правильно. І я теж, але обговорімо.

Взяти, наприклад, Paperless. Це така система для керування та пошуку по відсканованим документам. Автори кажуть: «теки ми не зробили, бо є теги». Типу, хочеш згрупувати декілька елементів — використовуй тег. І в принципі норм, а шо, хоча відчувається якось неприродно час від часу.

В іншій програмі — у Raindrop, де я зберігаю закладки — можна і теги додавати, й ієрархічні колекції створювати. За наявності ієрархії мозку одразу стає легше, бо є якась структура, по якій можна просуватися, варто лише початок обрати. Це корисно, якщо щось шукаєш, і не певен, що саме, або якщо просто хочеш глянути, а що є взагалі.

Та з ієрархією неодмінно настане момент, коли не зрозуміло, в яке місце додавати новий елемент, а дублікати створювати не хочеться. Ось є у мене ієрархія тек по мовах програмування: ну, там… C++, Haskell, JavaScript, Red тощо. І тут я хочу зберегти посилання на бібліотеку Slint, яка є і для C++, і для Rust. Тож в яку теку її додавати? Або, уявімо, що теки були не по мовах, а по категоріях: DB, Network, UI й т.і. Тоді куди тут додавати Qt, якщо він чудово справляється з усіма ними? Ну ви зрозуміли. У такому випадку зазвичай як раз достатньо обрати якийсь один варіант для утворення ієрархії, але для пошуку всі характеристики краще перелічити як теги.

Тут виникає інша проблема. Якихось характеристик, властивих поточному обʼєкту може бути ну дуже багато! І ніколи не знаєш, які треба додати, а які не обовʼязкові — дізнаєшся це, вже коли намагаєшся знайти щось, і не виходить 😖 Одного разу я автоматизував собі додавання усього, на що я ставлю зірочку на ґітгабі, у Raindrop зі збереженням тегів. І тепер у мене 2500+ тегів, з яких, мабуть, 80% зустрічається в _одиничному_ екземплярі серед усіх 1600+ закладок. Бо люди на ґітгабі теж не знали, які теги варто додати, а які ні.

Або ще проблема. Ось є у мене в закладках якісь відеоредактори: чи має бути тег #відеоредактор, чи все ж #відео та #редактор? Чи може всі три одночасно?

А ще дратує, коли якісь суто технічні обмеження для тегів створюють: тільки маленькі літери, без пробілів, без дефіса, без інших символів тощо. А якщо немає цих обмежень, то теж погано: починаєш думати, чи маленькими літерами все писати, чи великими? Має бути #javascript чи #JavaScript, чи може #js або #JS?

Obsidian, в якому я це пишу, пішов далі й дозволив ієрархічні теги. Це в принципі вирішує низку проблем. Наприклад, я можу створити тег #редактор/відео і швидко знайти саме відеоредактори, але також можу і побачити взагалі всі (уявімо, що там текстові, аудіо-, графічні й т.і.), якщо шукатиму чисто по #редактор. Зручно? Зручно.

А втім… Зваживши все, що я написав раніше, чи бачите ви проблему?

Саме так! Це ж та сама ієрархія, але вже серед тегів. Тобто й обмеження, й решта проблем всі ті ж самі. Візьмемо #arduino, наприклад. Куди його покласти: в #залізо чи у #бібліотека для C++? Адже насправді воно і те, й інше.

Тож вже напрошується єдиний правильний висновок: треба дати можливість тегати теги!

І тоді при пошуку можна буде брати як той тег, що безпосередньо був обраний користувачем, так і теги, які йому належать. Якщо ви шукаєте щось по тегу #залізо, то ймовірно хочете побачити там і те, що стосується #arduino. Якщо у вас є тег #FreeRTOS, то він сам може бути протеганий як #Amazon, #real time, #MIT license, тоді як #real time стосуватиметься #operating system, а #MIT license належатиме до #open source. Тоді шукаючи за тегом #Amazon ви автоматично знайдете все, що цим тегом явно позначено не було, але було позначено як #FreeRTOS.

Звісно, є й зворотна сторона. Наприклад, ви шукаєте #open source, і воно, розмотуючи ланцюг, знаходить тег #FreeRTOS, яким ви позначили щось, що стосується FreeRTOS, але само по собі при цьому зовсім не обовʼязково open source.

Окрім можливості тегувати самі теги, треба ще зняти обмеження на використання будь-яких символів у них, а також обовʼязково дати можливість визначати для тегів псевдоніми.

Це я мрію зробити собі прогу для каталогізації мотлоху, що у мене є, тож розмірковую з приводу організації.

Я сам кіберспортом не цікавлюся, а ось технологіями навколо — інколи буває. Сьогодні про клавіатури хочу сказати.

Наразі вже певний час триває (повторний) розквіт механічних клавіатур, який для мене особисто почався більше 10 років тому з купівлею клавіатури на Cherry MX Blue. У ті часи перемикачів в принципі було 4 доступних: сині, коричневі, чорні та червоні. Ще пара людей могла щось чути про Topre, та то скоріш виключення. Зараз же перемикачів існують сотні: ті, що клікають при натисканні, ті, де відчувається «сходинка», лінійні, тихі та не дуже, з різним зусиллям, від різних виробників, побудовані за різними принципами тощо. Зʼявляються регулярні порівняння, відбуваються холівори, та довгий час незмінним лишався один факт: перемикач лишався просто перемикачем — тупо boolean ввімкнено/вимкнено. Решта вже снобізм та смаки, як на мене. (У мене до речі Gazzew Boba U4, якщо це комусь про щось скаже. Мій вердикт — норм 🙂).

На моєму обрії все змінилося, коли на кікстартер вийшла Wooting зі своєю клавіатурою one. Сама по собі вона була не надто цікава на відміну від оптичних перемикачів, на яких вона базувалася. Оптика дозволила не просто реєструвати факт натискання, а реагувати на глибину. Я сам граю майже виключно іксбоксовим геймпадом 🎮, тож для мене цілком нормально контролювати в іграх дії, як-от швидкість руху, дуже точно, не кажучи вже про можливість відчувати те, що відбувається на екрані, завдяки haptic feedback. І це сильно відрізняється від досвіду гравців на клавіатурі та миші, де ти ніби перебуваєш у пласкому цифровому світі — наче деякі відчуття заблокували. (Але у людей там свій фан, не будемо кейборд-шеймити тут 😂).

Так ось… а тут раптом клавіатура на оптичних сенсорах! Звісно, ця функціональність має додатково використовуватися авторами гри, наприклад, щоб зробити плавний перехід між ходою та бігом, тож може це одна з причин, чого я довгий час згадок про Wooting не чув. Втім, з цікавого, зокрема для ігор, була можливість налаштовувати так звану точку спрацьовування — момент, коли, власне, перемикач реєструє зміну свого стану — тоді як інші механічні перемикачі мали цю точку сталою.

Чого здатність повільно ходити в грі не може зробити, так це продати комусь клавіатуру. Тому Wooting вигадала невеличку оптимізацію під назвою Rapid Trigger, яка потенційно давала відчутну перевагу у змагальних іграх. Ідея у тому, що замість перемикання у якійсь конкретній точці світч реагує на зміну напряму руху. Іншими словами, ви натиснули кнопку, й щойно почали її відпускати, як клавіатура перестала слати для неї івенти. Якщо знов донизу пішло, знов надіслали. Це дозволяє ніколи не натискати та не відпускати кнопку до кінця, що стає в пригоді в іграх. Razer, SteelSeries та інші теж «надихнулися» та зробили у своїх пристроях таке.

Wooting пішла ще далі. По-перше, виявилося, що оптичні сенсори не дуже точні при максимальному натисканні. А по-друге, вони… бруднилися 🚯 Тож компанія перейшла на сенсори на ефекті Холла. Але цікавішою була їхня подальша оптимізація Rapid Trigger, яку вони назвали Rappy Snappy. Тут вже стало очевидно, що цільова авдиторія — це саме геймери. Короч, ідея у тому, що можна повʼязати дві кнопки з «протилежними» діями, наприклад, вліво/вправо або вгору/вниз, та реєструвати натискання тільки однієї з них — тієї, що натиснута глибше — бо мати їх обидві одночасно натиснутими все одно несе небагато сенсу в більшості ігор (бо у такому випадку гра зазвичай ігнорує обидві).

І ось не так давно Razer відповіла на це власною варіацією під назвою Snap Tap. Замість того, щоб покладатися на те, наскільки глибоко кнопки натиснуті, вони реагують на останню зміну стану (натискання/відпускання). Таким чином можна, наприклад, тримати одну кнопку завжди натиснутою, а іншою змінювати напрям руху.

Що там ще цікавого навигадували? Хтось в темі?

Це трохи нагадує мені так-званий one-pedal drive, що нині є в деяких гібридних та електроавтівках. Там ідея у тому, що натискання педалі — це прискорення, а відпускання — це гальмування. Я якось пробував, й мені не зайшло. Та мабуть все впирається у звичку.

Тут чувак у сусідньому каналі (Я вже рекомендував? Рекомендую!) пише, мовляв, подивіться, як програмували у 90-х… скільки коду треба було написати, щоб зробити просту програму.

Ну, я подивився. А там приблизно те саме, що я й зараз пишу 😅😭 Тільки розмірність вікон та координати значно менші )

Щось десь краєм вуха чув про GraalVM, але сильно не цікавився. Виявляється, можна нині скомпілювати джаву в нативний бінарь без JVM, і це дає реальний приріст як по CPU, так і по пам'яті 👇

Мені тут клауд зі світлинами підказує, що 13 років тому я з двома друганами брав участь у DOU-хакатоні.

Він проходив в офісі Ciklum, куди ми приїхали без жодних ідей, просто потусуватися. Але врешті написали гру 👇

На все відводилася 1 доба, а ми перші пару годин тільки роздуплялися, чи варто взагалі хоч щось починати та, якщо так, що саме. Одним зі спонсорів була GlobalLogic, яка роздавала свої блокноти. Тож під враженням від нещодавно зіграної Eufloria я запропонував зробити якусь схожу гру прямо «у тому блокноті». Накарлякав у ньому щось, пофоткав, трохи обробив у фотошопі та нарізав спрайтів. Чуваки поки почали писати код.

Я на той час віддавав перевагу C++, мій інший дружбан писав на C#, а третій взагалі прийшов з прикладної математики, тож вирішили писати все на Java як чомусь середньому для всіх 😁

За задумом це мала бути RTS, та ми не встигли зробити для того нормальний луп, тож це перетворилося на TBS, де треба було постійно клацати Next turn 😅 Гра проти компа. Гравцю та супернику дається по одній планеті + можливість будувати юніти: харвестери та файтери. Харвестери добувають ресурси з інших планет, а файтери фігачать ворожих юнітів (можна селектити та направляти їх).

Після доби кодінгу, бозна-скільки спожитого редбула та цигарок, прийшов час фінальних презентацій. Досі згадую інколи той момент, бо він показав, що люди дуже емоційно оцінюють речі. Чи була наша гра обʼєктивно цікавою з геймерської чи з програмерської точки зору? Та ні, звісно. Але вона мала креативний вигляд, завдяки чому після голосування ми й взяли третє друге місце.

А перше місце до речі посіли мої знайомі, які написали на #Haskell транслятор коду з #Pascal у JS. У одного з них була триста років тому написана мультиплеєрна TurboPascal-гра на співпрограмах (корутинах) під DOS, яку він схотів перенести у браузер. Врешті гра не запрацювала, бо воно їм там нагенерило 70 МБ коду чи щось таке, й жоден браузер не стягнув, але якісь простіші приклади вони продемонстрували тоді. Короч, люди також радше емоційно, ніж раціонально проголосували, бо вау-ефект був сильніший ))

А як щодо того, щоб підписати відкритого листа про додавання української локалізації у новий Dragon Age, який має вийти цього року? Або хоча б ретвіт зробіть: https://x.com/dragonUAge/status/1820469915830391057 А краще й те, й інше.

Дуже хочеться бачити українську частіше та більше 🤝

Деякі люди думають, що ініціалізація в C++ — це складна тема. Зовсім ні! Ось ці 4️⃣ (так, чотири!) статті чудово пояснюють всі або майже всі її види: раз, два, три, чотири. (Особисто я визнав поразку на середині третьої).

Що ж робити? Як користуватися інструментом, яким ви не повністю володієте та розумієте? Та так само, як ви щодня робите у побуті!

Візьмемо фен, наприклад. Його можна вимкнути та вимкнути. Працює він від електроструму, тож базові знання вам підказують, що, мабуть, не варто кидати його у ванну з водою. Також всередині ймовірно є якийсь мотор з лопатками, тож інтуїція має підказати вам не пхати туди нічого, що могло б заблокувати їхній рух. Впевнений, це навіть в інструкції написано.

Але ок, фен не так складно влаштований. Ось пральна машина — це вже серйозний винахід. Там треба і підʼєднати правильно, і транспортувальні болти витягти, і вирівняти, щоб не хиталася — засетапити короч. А потім кожну сесію треба правильно інітити, щоб воно давало очікуваний результат. При цьому аргументи для сесії треба перевіряти перед запуском, ну, щоб вони не важили забагато там та взагалі були очікуваного типу. І шо, хіба треба 15 років вчитися, щоб користуватися? Та нє — мануала на декілька сторінок достатньо ж.

Ось і з C++ та сама історія. Чи корисно знати всі нюанси, що описані в стандарті мови? Ну, наче так. А чи обовʼязково їх всі знати? Та наче ні.

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

Думаю, набуття досвіду — це, між іншим, і є зменшення кількості сумнівів.