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

Важко знайти щось стосовно заліза, що дратуватиме мене більше за оцих двох хлопців: відео та аудіо (і я, до речі, навіть не про Bluetooth)!

Вирішив я у відпустці зробити на своєму ігровому віндовому компі так, щоб Dolby Atmos працював. Телевізор Samsung, саундбар Samsung, вінда підтримує — що може бути легше?
(Правильна відповідь: легше не ~~вийобуватися~~ вмикати Atmos. Але це нецікаво.)

Значить, схема така: комп через HDMI-дріт йде в саундбар, а саундбар через інший HDMI — у телевізор. Не працює ❌

Ок, тоді комп йде в телевізор, а телевізор у саундбар через HDMI ARC. Інколи працює з жахливим лагом, а інколи чомусь взагалі ні ❌

Тоді комп одним HDMI-дротом йде в телевізор чисто заради відео, а іншим — у саундбар для аудіо. Починаються танці з налаштуваннями, в один момент яких комп взагалі відмовився виводити кудись картинку, а у мене навіть монітора немає. І по RDP почав помилку писати. Ще й Switch тепер на саундбар звук не виводить ❌

Ок, вирішив замовити нові кабелі. Ви ж в темі, що вони всі різні, хоча виглядають однаково? З якимись у вас буде 4K, з іншими ні. 120 Hz? HDR? — Як пощастить. Не забуваємо про довжину ще!

Гірше ситуація тільки з USB-C — ось там взагалі найгірший прояв динамічної типізації прямо у залізі‼️, бо може бути USB 3.0, а може бути 3.2… а може бути чисто живлення… або живлення, але не з тим струмом… а може й живлення в інший бік… або навіть не USB, а HDMI! Чи якийсь Display Port через Thunderbolt. Дуже зручно короч, дякую.

Добре, кабелі новіші отримав, почав знов під’єднувати. І врешті працює тільки варіант, коли сигнал з компа йде у телевізор, а звук з іншого порту телевізора через HDMI ARC — вже у саундбар ✅ Наче логічніше було б, якби сигналу не доводилося робити петлю, але ні.

Затримка трохи лишилася: по відчуттях всього 50–100 мс, і в більшості випадків навіть не помітно, але я знаю, що вона там, і це дратує. Прям сидиш і замість того, щоб слухати діалог персонажів, моніториш їхній ліпсінк.

Інша проблема: перехід з тиші у стан, коли є звуки. Якогось хєра це займає ну секунди 4, їй-богу. Тобто ці чотири секунди звуку просто нема! Для ігор це зазвичай не суттєво, бо там завжди хоча б фонова музика є, але якого хєра‽ Знаєте, що допомогло? Зайти в налаштування звукового пристрою та поміняти драйвер з NVIDIA на вбудований віндовий 🤡🎪

Я дуже сподіваюся, що люди, які це все вигадали, вимушені щодня з цим стикатися і так само страждати!

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…