І що?
Зато темплейти, «і навіть» ламбди «з коробки» ))

А що там «розкривати»? Всі мови програмування однакові якщо вимкнути ексепшени та RTTI, то С++ це «Сшка з синтаксичним цукром» ))

А то, що люди називають «Arduino scripting language», то ніразу не скріпти а «самий справжній» C++ ))

Там дискусія давніша, зліша і фундаментальніша...

Є правило: той, хто вносить «брейкінг ченджз», повинен поправити й всі місця де він поламав... зокрема якщо така зміна в Сшці, то тепер Сшний автор повинен буде фіксити й депендент частини на Rust які зміна поламає, отже, власне, знати Rust, що й викликає відповідний супротив...

А самі Rust розробники теж дуже «не в захваті», що ніде не специфіковані явно оті лайфтайм та овнершип штук, з якими вони взаємодіють з Rust... Єдина порада «наслідуй існуючий драйвер, фоловай його конвеншенам», що, насправді, зовсім нічого не говорить про оті лайфтайми (певно, їх не знають й самі Сшні розробники, а це велика печалька:))

PS: Окрема «баттхертна» тема: а що тепер для dkms треба буде не лише Cшка а й Rust на кожній машині?

І що? Я ж досяг того, чого хотів: не перезбирав ядро і навіть не витрачав час на продуманий підбір «ергономічно подібного» девайсу, не ходив фізично нозями на «Нову пошту» :)

Я оживив «старий та древній» девайс абсолюно «без ніяких зусиль» за допомогою, можна сказати, сучасного софта))

Альтернативи: продовжувати запускати «старовинну та непідтримувану» 7ку, або ж забруднити екологію викинувши «цю древність» (що для мене неприпустимо не з «екологічних міркувань» а того, що цей естетичний девайс дорогий як згадка про «хороші часи»))...

Так, я розумію, що зараз навіть телефон потужніший, але такий девайс з «людською» qwery клавою вже є в моїй хаті й одразу ергономічно такий, як мені й треба...
сумарний затрачений час на «витягти з полочки і поставити Лінух» менше, ніж обирати ще один телефон, потім чекати доставки та йти фізично нозями на «Нову Пошту» й його там отримувати :)

Ні реклами, і непроханих атдейтів, абсолютно контрольоване середовище, що (вже тепер, власне це для мене й було відкриттям, й втому зміст мого послання) сетапиться без «танців з бубном командним рядком» :)

Прошу пана, а які саме конфіги? Чого бракує в умовному «Linux Mint», просвітіть?

Щоб підсумувати: вже давно минули ті часи, коли треба було довго «щось шаманити» з конфігами...
Той карикатурний імідж «хакерської ОС для красноглазіків, гроблення часу ночами налаштовуючи» — неправда!

А це, що можна оживитити старе залізо (навіть зовсім старовинне 32бітне) — ПРАВДА!

Натхненний статтею я вліпив собі MX Linux на старенький ASUS Eee PC, й воно дійсно все робе з коробки включно з вайфаєм та фаєрфоксом й українська клава без проблем... і шрифти, й масштабування, й розміри іконок файлменеджера, й все решта легко налаштовується через їхні MX Tools без необхідності знати про всякі .xinitrc та /etc/X11...

Єдина «зрадонька»: відео Ютуба (як і пише стаття) фігово тягне (й, звісно, на Eee PC нема Nvidia)), але, як виявилося, правдива причина «тормозів» — Ютуб за ті довгі роки вже «пакращив» свої кодеки й тепер треба ставити екстеншен enhanced-h264ify (я спецом не зносив 7ку і ставив Лінух в окремий розділ, то виявляється навіть в 7ці у Хромі з Ютубом теж біда)...

Навчити рідних ходити в соцмережі з того фаєрфокса і дивитися фоточки з інших дисків можна без проблем. Головне «оверкам» ту фішку, що операційка «запихає» тебе в «хоум діректорі»,
але це компенсується тим, що «диски» тепер «самі монтуються» в папочку /media ))

PS. при завантаженні MX-23.5_386 з флешки воно каже «фігвам», але загугливши месідж, перша підказка «натисни TAB» і тоді натайпати live :)
PS№ 2. Убунта з її «снапом» та своєрідним підходом — зло!

Прошу пана, огласітє вєсь спісак, а можна «Minimal, Reproducible Example», тоді це буде або чудові поcиденьки в пошуках рейскондішена, або ж чудовий аргумент в розмовах за кастомний алокатор))

Реалізація HeapAlloc живе в юзер спейсі (окрім власне виклику VirtualAlloc), отож, теоретично можна навіть додебагати до «а що ж там нетак»...

Власне я погоджуюся з добродієм «юнит тест», в тому, що HeapAlloc/HeapFree вже достатньо «вилизали» за ці всі роки існування, тому найімовірніше «тут щось нете»... або якась «дуже специфічка вінда», що «живе в контейнері», чи взагалі wine, можливо упіймано якийсь невдалий момент між апдейтами вінди...

Іншими словами «таку бажище» мали б віднайти та зарепортити «вже давним давно», й вона легко знаходилася б гуглом...

Гортаючи «по діагоналі», вже думав, що включу цю статтю в рекомендації для С++ джуніків на нашому проекті... але ні, не включу...
і не тільки через задовгу «мотиваційну» частину, але і...

void printArrayUntilGoal(vector<int> arr, int goal)
{
	for(int i = 0; i < arr.size(); ++i)

...
Поглянемо на перший приклад — O(N) TC. Що ми можемо сказати про SC? Чи витрачається додатковий простір? Ні, бо логіка «бігає» по вхідному масиву. Тому можна сказати так: даний алгоритм має O(1) SC.
...

void printArray(vector<int> arr)
{
    vector<int> a = arr;

...
Створюється новий масив, такого ж самого розміру, як і вхідний, та копіюються всі дані. На результат цей «move» ніяк не вплине.
...
SC — стало O(N), а було О(1)

не було... бо ж той параметр він vector<int> arr в обох випадках...
логіка «бігає» по тому вхідному масиву, що вже і так копіюється в С++ або мув або копі конструктором при виклику функцій...
копі конструктор — ворст кейс, тому SC відповідає O(N) а не O(1) навіть в першому прикладі...
(про референси/поінтери/ітератори/рейнджі вже тут й не згадую))

У С++ int змінна завжди займає 4 байти

неправда, бо стандарт специфікує тільки мінімальну бітність, а не точне число в «tab:basic.fundamental.width»
що для int складає 16 біт... (й, на умовній Ардуінці він таки й буде саме 16біт, два байти!))

далі гуглити ILP32, LLP64, LP64 версус ILP64 та SILP64 (тут int 64 біти == 8байтів а не 4)

а також про сstdint/stdint.h та що таке (u)int32_t i тд

--------------------------

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

в загальному великий + за україномовний технічний контент (якого нам так дуже бракує, щоб люди не заглядали «за поребрик»), але, все ж, бажано «вчити матчастину» ))

Правда! І «бітрікс» туди саме... та зараза пролізла всюди, не лише в Україні, ще й в світі багато де...

А з українських проектів, щоб замінити «запоребрикову» для програмування знаємо... хм, хіба «Мавка» (так і називається))

«Всі мови програмування однакові» (якщо вони «Тюрінг компліт»), і на кожен тип цвяхів — свій молоток...

Сучасний Пайтон з його тайп анотейшенами — улюблена тула (там, де йому вистачає швидкодії...))

C++ то ненависть (бо «комітет» то лебідь, рак та щука люди що писали ще на MFC) та любов (адже, насправді той C++ можна «транформувати», обравши інший сабсет під свої задачі, де улюблений сабсет, то «C з класами та ламбдою, й темплейтами замість макросів»).
(майбутня любов, то, напевно ж, Rust))

Але от щоб саме «мова програмування» і вона була прекрасна, саме як мова програмування, це... Lua!
Легко вчити (якщо маєш книжку PIL)) та дуже легко заембедити в свою аплікуху! Особливо якщо порівняти з абсолютним безумством процесу білда деяких роздутих «знаменитих» ЖС енжінів від «великих корпорацій» (та з їх огидним, божевільним API для «ембеддінга», з усіма отими «ізолейтами», «контекстами», та рештою переускладненого сміття, що дуже потрібно «великій корпорації», але не для моїх юзкейсів))!

Корутини в Lua дозволяють природньо уникнути цирку з «заразою» від async/await, як то відбувається в JS та Python (в Lua coroutine.yield може трапитися де завгодно у вкладених викликах без «інфікування» усіх вкладених функцій хворобою async/await! Корутини в Lua можуть робити yield та resume будь-де, що веде до більш гнучкого асинхронного коду)

«Протокол ітерації» в Луа простий і легко співпрацює з coroutine.wrap (замість винайдення окремої спеціальної «фічі» у вигляді «генераторів» на додачу до потворних «async/await» як то є заведено в JS/Python)...

Краще б в бравзері була Луа замість ЖС!

dlopen (LoadLibrary) також будуть брати участь?

та їх ніколи і не було тих «норм»

найбільша біда в тому всьому зоопарку, то те, що корутини юзають динамічну пам’ять,
і якщо для ламбди можна зробити sizeof() і (якщо постаратися) навіть поюзати її на такій платформі де «забанили» new, то С++20 корутина, вона «сферичний кінь у вакуумі» з повністю прихованим стейтом, і до неї тоді ще треба прикручувати алокатор...

В тому плані навіть данвя «Сшна» ідея від Simon Tatham що аб’юзить Duff’s device www.chiark.greenend.org.uk/...​~sgtatham/coroutines.html то вона виглядає юзабельніше (якщо запхати «стейт» такої «корутини» в клас), ніж нативні корутини імені С++20...

Привіт, а де побачити всі теги/теми, щоб не вгадувати і не вписувати вручну в URL...

Ось тут в цьому дописі є «Теми: tech, мета-топік», а де побачити всьо решта?

UPD: сам запитав, сам і знайшов, походу ось тут dou.ua/forums/tags

усі три різні тули «убивці» намагаються «замістити» різні астекти C++ які вирішуються на самому С++...

Вбивця 1. Spiral

це лише «ще один спосіб оптимізації», чому «в недалекому майбутньому» компілятори (їх автори) теж «не додумаються до того»? так і не зрозуміло...

Вбивця 2. Numba

ем... і як запустити Numba наприклад на... Ардуінці (так, Ардуінка, це також С++!)

Вбивця 3. ForwardCom

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

-------------------------

в статті нема відповіді «нащо вбивати С++»?
тут, звісно, хтось закине всі оті посилання на «авторитетів», там де матюки Лінуса, та інші приколи, або, навіть на творіння yosefk під назкою «C++ FQA Lite», що було актуально років 10-20 тому (і років 10-20 тому це все вже можна було обійти) але конструктивного обгрунтування «тула X замінить весь C++ та не буде складніше за С++» так і нема... лише «така то тула може замінити такий то аспект С++ в такому то юзкейсі»...

опитування 2022 Annual C++ Developer Survey «Lite»
каже що
«Memory safety: Bounds safety issues (read/write beyond the bounds of an object or array)»
цікавиться «аж» 14% учасників опитування
то, отже «такі проблеми» всі решта або «вже порішали» або ж «думають що порішати» (що, насправді сумно)

1. Багатопарадигмова мова

чиста правда, тільки біда, що той «сабсет парадигм» який обрали в наших «кузнях кадрів» затряг десь так років 20тому

2. Управління пам’яттю

теж перевага, тільки біде в тім, як це комбінують з «багатопарадигменістю» (зовсім не вдало)
варто було б згадати і те, що укрування динамічною пам’яттю також може бути автоматичним
shared_ptr... і таке інше
(а те, що тут назвали «автоматичний», очевидно варто було б уточнити «в стекові»)

3. Нульова абстракція

правильніше сказати «ми не платимо за те, що не використовуємо»

4. C++ сумісна з попередніми версіями протягом десятиліть

а ще вона може побачити всі «Сшні» хедери численних ембеддед платформ «з коробки»,
без необхідності описувати це вручну!

5. Детерміноване руйнування

правда, але примушувати людину писати класи-вропери довкола кожного ресурсу — знущання!
благо на пітхабі можна віднайти чимало самопсних «велосипедів» для «go-lang like defer» різної складності та зручості

6. Перевантаження оператора

Перевага тоді, воли оператори використовуються за принципом «найме5ншого здивування»,
«мова в мові» boost spirit, це для багатьох більше антиприклад, як не робити «DSL»

але в загальному перевантаження операторів (вкупі з перевантаженням функцій та ADL) дуже спрощує роботу, якщо не намагатися щоразу винайти «свою DSL на перевантажених операторах»

7. Невизначена поведінка

а ось це не перевага, а прокляття...
так, воно дозволяє компілятору робити «класні оптимізації»,
але треба вмикати ворнінги по максимуму і вважати на strict aliasing

8. Можливість використання функції друга

ем... знову ж таки, прекрасна фіча, але біда, що в наших «кузнях кадрів» мудрому використанню не вчать

9. Узагальнене програмування

це «аб’юз» тієї фішки, що темплейти в С++ «раптом» виявилися turing complete функціональної мовою програмування з «паттерн матчінгом» за параметрами шаблона...

для «непосвяченого» в «фунціональщину» такі трюки — правдиве пекло...
а для посвяченого — «недомова»...

проте чудова штука, коли не хочеться використовувати сторонні тули кодогенерації, обійтися без макросів і не бавитися з пребілд степом...
(і навіть незамінна там, де, інакше б довелося «парсити С++»)

10. Мова середнього рівня

100% тільки тут біда в тому, що опонерти з обох «таборів» (високорівневого ти низькорівневого) обирають фічі «протилежного табору» для своєї атаки!

насправді ж можна юзати і для ембедда (як «С з класами»), так і для високорівневих штук слідуючи функціональному стилю, проте для щього, знову ж таки треба досвід та підготовка, з чим в наших «кузнях кадрів» — біда...