також я зустрічав і щось на Rust, ChatGPT допоміг: dialog, ніби-то усі проекти робочі

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

Але навіть Rust я би не сказав, що це супер-проста мова: є проблеми оволодіти. Опір з боку мейнтейнера цьому свідчення.

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

g++ -c -fdump-ada-spec -C /usr/include/time.h

круть, але все ж «However, this option does not expose or include preprocessor macros in the generated Ada specification files. The primary purpose of this option is to create Ada bindings for C or C++ code, focusing on types, functions, and constants, but not on macros»...
втім, може і до Rust буде така опція... gccrs вже є ))

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

Складно. В принципі є Verifiable C, але треба розуміти, що у більшості розробників не дуже добре з математикою.

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

Ці тули довкола Сшки, це ж, походу, треба починати з vst.cs.princeton.edu ... і далі їхня отака книжка а ще й оце

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

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

І ще, книжка пише

Verifiable C is a program logic (higher-order impredicative concurrent
separation logic) for C programs with these restrictions:
• No casting between integers and pointers.
• No goto statements.
• No bitfields in structs.
• No struct-copying assignments, struct parameters, or struct returns.
• Only structured switch statements (no Duff’s device).
• No varargs functions, except limited undocumented support for
calling printf and fprintf.

Та то вже зовсім печалька... Звичайно, я розумію, чому «No struct-copying assignments, struct parameters, or struct returns» (воно ж осуттєво спрощує аналіз), але, все ж, в плані трекання переміщень/клонувань структурок з поінтерами, то таке до могутності Rust далеко не дотягує...

Я бачив таке: listener.c

то є SAL, по ідеї й умовний Cppcheck мав би вміти щось подібне...

Ідея Ada перш за все надійність.

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

Якщо тобі треба щось продуктивне, то ніхто не заважає написати на Сі, та викликати.

Але ж Ada не бачить Cшних хедерів напряму (так само, як й Rust) — сумулька...

(ну так, С#, наприклад, теж не бачить, але там є тренована команда, що то все інтегрує і понаписує правильні DllImport, а в Лінухах досі не можуть домовитися, хто буде мейнтейнити вже готові обгортки для Rust)

Наприклад, VerifyThis Challenge in SPARK — приклад повністю верифікованого методу сортування. Там декілька рівнів, від «відсутність run-time помилок» до «збереження ключових властивостей» та наприкинці «повний доказ функціональних вимог

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

Єдина дивна річ: чому ж така кльова фішка «не злетіла» в широких масах?...

Верифікація вітсутня в Rust взагалі.

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

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

Проблема не в перевірці, проблема у тому, що робити. От у тебе гелікоптер на Марсі в польоті, і у тебе спрацьовує runtime перевірка вихід індексу за межі

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

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

Зробити перевірку runtime взагалі не питання. Але навіть на рівні мови контракти (Eifell, Ada) дозволяють це робити виразніше

Нє, нє, мова не про рантайм, а саме про компайлтайм трекання юнітів по параметрах шаблона в статиці, і якщо ми «метри в секунду» поділимо на «секунди», то воно «допре само» що це «метри в секунді за секунду» або «метри * (секунду^(-2))» й це автоматом закодовується в параметрах шаблону... типу ось такого й подібного (всякі «units» ліби, що (аб’)юзять шаблони, аби разом з типом в статиці тягнути компайл тайм інфу), той самий подібний підхід й до діапазонів тобто все перевіряється абсолютно статично в компайлтаймі, й якщо ми «протягли» всі обчислення через такий bounded::integer то ми точно знаємо діапазон на виході в статиці й воно не впливає на рантайм ну зовсім ніяк...

(тому й якось дивно бачити що Ada зовсім не на перших місцях за продуктивністю)

Дуже великий лонгрід, ...

вечір п’ятниці))

Просто мова програмування С++ подібна Героїну: поначалу прикольно, потім не знаєш як з цього злізти. Тому ніби-то з конструктором переміщення ти отримаєш більш правильний та лаконічний код, але якщо щось не запрацює, то треба буде добре потрахатися.

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

procedure Initialize (Obj : in out Some_Controlled_Type);
procedure Adjust (Obj : in out Some_Controlled_Type);
procedure Finalize (Obj : in out Some_Controlled_Type);

і мова перевіряє щоб викликати Finalize не забули? Чи викликає сама?
а як то все лягає на наслідування? (втім ADA то окремий «всесвіт» з своїми «примочками»... про GNAT я чув й сумні відгуки, тому ніц не скажу)

Можна, але коли щось дозволено, то хтось це використає.

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

плюс верифікація на базі трійок Хоара.

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

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

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

Дійсно «в ідеальному світі» строго математично це все мав би доводити компілятор, та наразі бачу, що конкретно Ada так і не отримала «достатньо реклами», щоб народні маси великі корпорації були так само імпрессед як Rustом)) Хоча знаю, що свого часу вони заімпресили МО в США...

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

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

А згадайте но, як і які партєйки голосували коли в партаменті намагалися прийняти постанову з засудженням агресфї рф проти Грузії...

Якщо усе відразу запрацювало, як замінити vector на vector, то... напевно проблема у конструкторі копіювання. Так, помилитися можна де завгодно, але це ілюстрація, що конструктор копіювання не дуже й інтуїтивно зрозумілий, там просто помилитися, а шукати де помилка може бути гарним квестом.

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

Навіть без ніякого копіювання все оте «ООП на Сшці», й ті «прості речі» з тими всіма «премудростями» то клінічний мазохізм, грубо кажучи (імена «трохи змінені» щоб не палити кантору не порушувати NDA):
struct MyClass instance;
MyClass_init(&instance);
...
MyClass_якатоОперація(&instance);
...
Object_delete(&instance);

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

В конкретному випадку вище бага: валідні пари або MyClass_init/MyClass_dispose або ж MyClass_new/Object_delete,
але тільки не вперемішку та хто ж це відслідкує?
При тому вже всі чудово знають і пам’ятають про валідні пари, знають правила як складати VMT, бо Object_delete то макро, що робить приблизно таке ((Object*)my)->vmt->dispose((Object*)my), а тоді tx_block_release й ви повинні не забути прописати MyClass_dispose в вмтшці (а ще MyClass_dispose повинен викликати ЙогоБазовийКлас_dispose, ага)

А тепер додайте туди MyClass_clone та MyClass_cloneTo, що робить «глибоку» копію (не забудьте MyClass_clone ще викликає СвійБазовийКлас_cloneTo, ще якщо MyClass_clone то потім треба Object_delete, але якщо MyClass_cloneTo то треба MyClass_dispose над тою пам’яттю куди заклонував) + одночасно всі звичайні memcpy, що присутнє, бо автори бавляться в «активні об’єкти» й ті «класи» вони таким способом «подорожують» між тими «активними об’єктами» і вважається що черга «забрала» об’єкт, тому тепер в «нашому» AO його вже не можна «діспоузити» або «делітати» (його вже повинен заделітити «той» АО), але якщо «наш» об’єкт перед «відправкою в чергу» був створений через MyClass_new, то треба не забути звільнити пам’ять, зарелізити блок самому ручками через tx_block_release вже без виклику MyClass_dispose (бо тепер його повинні викликати «там»... коротше Rust би чудово розрулив ту всю «катавасію»)

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

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

А ще помножте на то, що «премудрий та модний» qp фреймворк також має свої власні уявлення про ООП, а ще, що в результаті комбінації двох світів там тайп каст на тайп касті й тайп кастом поганяє... І в кращому випадку, якщо натупити, воно падає одразу, а в гіршому «живе» роками, поки не вилізе в якомусь важко репродюсаємому сценарії або на новій платформі... тому що ніякі Юніт та Інетраційні кейси того не передбачили, навіть попри те що «все зелененьке» покрито в кожній гілці згідно показів пропрієтарної кавередж г@внотули)

І варіанцій такого «г@вноООП» на Сшці вагон, в деяких замість vmt поінтери на функції прямо в структурках, деякі юзають -fplan9-extensions, деякі алокують тільки динамічно (і не з блокпулів, а з байтпулів чи й простим malloc)...
деякі юзають макроси для створення таких «класів», деякі інлайни, деякі вперемішку, хтось викликає методи напряму з VMT хтось добуває VMT макросом, а в когось доквола кожного «віртуального» метода є обгортка, щоб не писати obj->base->base->base->vmt->метод((Object*)obj), а одразу Клас_метод(obj)...
і так далі...
і хочеться запитати «люди, ви *б@нулися?»

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

В деяких «методи» декларуються як
MyClass_якатоОперація(struct MyClass* my, ...);
а в деяких
MyClass_якатоОперація(void* my, ...);
з кастом всередині (тому таким АПІшками можна взагалі передати будь-який поінтер і компілятор ніразу не матюкнеться)...
деяке «г@вноООП» схоже на «пародію на С++» а інше зовсім не схоже, але все одно «г@вно»...

А «в ідеальному світі» можна було б загорнути неподобство в тайпсейф класи, юзати блокпули через темплейт (щоб він одразу видавав пойнтер на потрібний тип «тайпсейф способом» і одразу статично асертив, чи заалокований сайз відповідає сайзу блока в пулі), і не засмічувати файли самописними VMTшками й тими всіма танцями з бубном)...
не юзати нестандартний та непортадельний -fplan9-extensions (його часто юзають, щоб не писати me->base->base->base->якетоПоле або не робити ((ОдразуТойБейсЩоТреба*)me)->якетоПоле і варіації довкола того, типу проміжного локального понтіра)

Коротше можна було б писати на C++ в стилі Ардуінки на «адвансед С з класами і темплейтами» (чим, по суті, і є С++ якщо не юзати ексепшени, RTTI і не зловживати контейнерами з динамічною алокацією)
й всі «фішки» про лок фрі, актор модел і тд чудово збереглися б!

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

Ну... є h2pas який це переводить хідер в модуль на паскалі. Щось таке, напевно, використовувалося у Delphi для перекладу хідерів WinAPI. В принципі, задачу можна вирішити, поставив обгортку над cpp.

Але так, це подарункові граблі.

Звичайно, і щоб парсити Сшку, так щоб порозкривати всі дефайни та тайпдефи з щоб воно залежно від дефайнів порозкривало всі #ifdef та повключало правильні хедери з тих include directories «що треба», то треба щоб той h2pas отримав все готовеньке середовище вже запрепроцешений з тими ж опціями що й ядро файл, і серед того сміття, що натягнулося також і з усіх хедерів міг витягти саме ті АПІшки та структури, які нам треба поюзати в нашому коді... тільки ж біда чорна: що деякі АПІшки, то ніразу не АПІшки, а таки макроси, з них не візьмеш сигнатуру, бо в препроцешеному файлі того взагалі не існує...

Тобто була проблема, хотіли вирішити за допомогою конструктора переміщення, не взлетіло, він трохи порозбиралися, далі було шкода витрачати час, за 15 хвилин він переписав на вказівники.

іншими словами «рут коз» невідомий, й то могло бути що завгодно...
й «звалити все» на С++ — не зовсім вірно (умовний Сшний qsort теж міг би не видати бажаного)

я не бачу жодної проблеми у тому, щоб розробники Rust копіпастили код

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

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

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

Отже, мало заплатили тому діячу, що «зарубав» зміну...
Або ж він попав в ті 10-%, що якраз працюють нахаляву на громадських засадах...

Сортування злітало, конструктор переміщення був написаний для типу елементів контейнера.

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

Для «стандартних контейнерів» це все — коммон кейс, що його вже, мали б «вилизати» в попередні роки... але є багато інших сюрпризів, наприклад, «бійтеся Winsows.h»: якщо алгоритм юзає min або max то у Winsows.h про це своя особлива думка (і не лише в нього) і не лише про min або max, в ще й про small, Yield, ANY, та решту штук (то все макроси й дефайн NOMINMAX та WIN32_LEAN_AND_MEAN не рятує)... але й без вінди всякі «допоміжні» ліби (навіть створені в межах компанії, або на боці замовника й жоден впертюх не поступиться щоб додати префікс) мають свої уявлення про «прості слова», всякі IO, IN, OUT, а ше і далі дефайнять всякі u16, u32 (хоча stdint.h вже давно існує) і навіть буває «канонічні» open, read, write макросами (POSIX плаче кривавими сльозами, вони також ті прості слова юзають) в кращому випадку не скомпілиться/не злінкується, в гіршому «вилізе боком» десь потім...

Я погоджуюся, просто є технічне зауваження, що якщо мова не повна по Т’юрінгу, до певні речі там не напишеш. Але зазвичай такі мови все ж таки дозволяють писати повні по Т’юрінґу програми з додатковими позначками типу unsafe.

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

Не деяких задачах може бути за замовченням навіть краще... Бо restrict проставити інколи досить муторно. Але алгоритм танцующих зв’язків реалізувати складно за вудсутності нормальних двозв’язних цикличних списків.

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

А насправді людей, яким Rust взагалі не цікавий, примушують в цьому розбиратися. От і реакція.

ось це печалька, причому в двох вимірах:
1. Підходи в Rust — перспективна штука (не ручаюся за всю мову, але їхню «рекламу» й приклади я вже давно зацінив). Не знайти якогось рішення щоб «й вовки ситі, й вівці цілі» — велика сумулька...
2. Заставляти перевантажених людей, що й так працюють фактично у громадському проекті нахаляву, навалюючи нові додаткові обов’язки — то знущання.

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

Я про те, що якщо немає формальної спеки, то це питання часу та везіння.

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

Тобто я не проти «формальної» спеки, я про те, що в неї, зазвичай, лізуть коли «щось треба», а от «вивчити» її «всю» практично неможливо (вивчити по ній мову — практично неможливо))

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

«щось тут нете»)) стандартний вектор при std::move переміщує своє представлення, а не свої елементи...

Ну... з цим погралися, не запрацювало, та й вирішили, що немає часу розбиратися.

ем, з чим саме, з вектором? «щось тут нете» (ц)

Це дуже провокаційний вислів, тому треба пояснити яка «однаковість» мається на увазі

Я лише про те, що «всі на світі програми» можна переписати хоч на асемблері, хоч на брейнф@кові... (якщо кількість комірок нескінченна), але, все ж, на деяких мовах писати зручніше, ніж на інших. З того ж (умовно) С++ можна обрати «підходящий сабсет» (той ж RAII, темплейти, й халявне заповнення VMT самим компілятором, замість мейтененса табличок вручну, більша безпека типів і тд) сабсет такий, що чудово лягає і на написання ядер і на ембед...
Але ж ні «релігія не дозволяє»...
натомість всі оті
#define list_for_each_entry(pos, head, member) ...
всякі uthash... та «йо майо», ото такий «дженерік програмінг», ага...

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

гіпотетичний read_guard має таку ж ціну як й пара read_lock й read_unlock, але «поборці за читоту ядра» вперлися що лише окремі read_lock й read_unlock правильно (ну зараз дискусія вже не зовсім про те, але суть не змінилася... не хочуть люди примусового RAII, але деяким навіть опціональне не канає, причому у варіанті C++ інтеграція з існуючою Cшкою взазалі «нахаляву» бо C++ бачить всі хедери як є, й не треба повторювати APIшки переписуванням...)

ну але ок, проїхали, давайте полишимо С++, але ж Rust за продуктивністю практично нічим не гірше а його також «зафукали» як й C++...

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

Але зазначу: «за всі довгі роки» траблів конкретно в розумінні «простими смертними» тої move-семантики, так щоб хтось наплужив саме через то, я не зустрічав ніразу.

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

Всі мови програмування однакові (якшо мова про «Тюрінг комплітнес»), але необхідність «слідкувати», «бути уважним та старанним», то також «складність» в мові (в програмуванні нею), вона є «найгадіша», бо таку складність неможливо «вивчити раз і назавжди», й в кожній ситуації «треба бути уважним по новому», тому, чим більше «бойлерплейту» вимагає програмування — тим гірша мова! Тому «ручками» malloc/free чи new/delete, «старанне та уважне» слідкування за відповідністю між read_lock й read_unlock — клінічний мазохізм... RAII — musthave фішка нормальної мови (і тому Rust класний, бо він насаджує ту фішку силою, а не як опцію!), «хоч якесь» RAII — musthave, або хоча б якийсь defer як в go, хоча б using як в C#, хоча б with як в Пайтоні (а оті всі goto Cleanp; то особливий клінічний затятий мазохізм, втім, як й набивання табличок VMT ручками, коли люди роблять «ООП на Сшці» й всі танці з бубном довкола ініціалізації (та клінапу в правильний момент) таких «класів»...)

____
PS. а лізти в стандарт весь час доводиться якраз для боротьби з нестандартними фічами та «розширеннями» що їх юзають розробники (-fplan9-extensions — це ж треба додуматися до такого, щоб спецом поюзати то, з іншого боку класна фішка, як й __attribute__ cleanup, тільки, нажаль, не в стандарті, втім defer був би ще краще).
Тобто по факту стандарт потрібен лише для тих юзкейсів щоб «натовкти мордочкою»: «це не мій компілятор кривий, то ти поюзав нестандартне розширення»...

Звісно, окрема біда-печаль та джерело траблів — UB, й зокрема strict aliasing (отут якраз, насправді, з «вордінга» в стандарті ніфіга не очевидно які то має «жахливі наслідки» для любителів робити cast, й тому гуглити статті з прикладами — саме то)

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

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

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

То само й про решту мов програмування: формальні спеки — для розробників компіляторів (також для ср@чів, в стилі про JavaScript WTF коли формальна спека приписує дикі, неочевидні та неінтуітивні речі, що «то так і має бути»))...

Неможливо вивчити ЖС читаючи брєд сивої кобили стандарт ECMA-262 (зато теж й всі реалізації ЖС працюють «приблизно однаково», бо ECMA-262 все заспецифікували детально! і це прекрасно)... Але в ЖС є свій MDN, а в С++ — нема... (cppreference не годиться, бо то майже такий же формальний брєд! Стандарт мови — це чудовий ресурс для спору про те «чи то по стандарту», «чи не по стандарті» (щоб доказати впертюхам, що в стандарті ніякого __attribute__ cleanup не існує, і що улюблені багатьма «пакращення» у вигляді -fplan9-extensions, то теж ніразу не стандарт !!!), але формальний ресурс абсолюстно непридатний для навчання мові програмування)...

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

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

та тих макрів існує вагон й маленький візочок, навіть самописних на проектах, без притягування «монтстра» Boost та без потворного BOOST_SCOPE_EXIT_END, а так, що синтаксично виглядає буквально майже як go... не «маже», а краще ніж в go« у вигляді DEFER{то, що треба задеферити} без якиких лєвих func))

... але, все ж, «нативна» фішка була б веселіше))

Все вірно, тому й кажемо про сабсет... ;)

C++ 11 move semantic, в ней 264 страницы

Автор просто заробляв гроші за кількість сторінок...
А зрозуміти ідею «move semantic» легко «на побутово-інтуітивному рівні» без вникання в божевільні деталі glvalue, xvalue, prvalue і тд... «move semantic» — то є спосіб перевантажити за темпорарі значенням (звісно «представлення переміщується» не так елегантно й довершено, як передача овнершипа в Rust, але, втім, інтуітивно дуже проста штука)...
...легко запам’ятати конкретний юз (й цього, зазвичай, достатньо), ніж всю ту божевільну «механіку» внутрішньої термінології С++, як воно мапується на правила мови))

«професійні книжкопісатєлі», здається, самі не програмують, тільки читають С++ стандарт й одразу пишуть свої книжки... а якщо читати стандарт, то дійсно нічого незрозуміло, проте все то само про, наприклад, до... ЖС. ECMA-262 читати практично неможливо й практично нічого незрозуміло з того брєда, зате є MDN, де не пишуть такої фігні, й можна зрозуміти мову побутово-інтуітивно))

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

Те, що Лінус «вперся» проти С++ ніразу не значить, що С++ в ядрі «принципово неможливий»! Якщо переступити через «затяті принципи» й обрати правильний сабсет «плюсів», той, що «C з класами без RTTI та ексепшенів» тоді навіть деякі «модні штуки» типу отих всіх Result та Either цілком можливі, бо вони, насправді, недалеко втікли від std::optional та std::variant))

Так, так, я знаю що Result правильно трекає юзедж і все таке, а всякі [[nodiscard]] це «нето», але факт в тому, що своєю впертістю проти «плюсів» те лінухове ком’юніті злосно обіср@лося (так само, як воно зараз обіср*ться ще й своєю впертістю проти Rust)

PS. Втім, в «неприйнятті» C++ також є заслуга й самих «плюсів»: вірніше того, як їх викладають, і як то «зазвичай прийнято» все робити в такому стилі, ніби то була Джава...

Насправді «няшно С-шний» варіант не менш жахливий, «statement exprs» то нестандартне розшинення (та й typeof з’явився лише в С23, а до того був лише розширенням деяких компіляторів)...

Тобто якби Лінукс написаний... «не на Сшці»
(втім, я погоджуся, що решення Лінуса про -fno-strict-aliasing вірне, щоб не аплаїти «модну Сшну фішку»))

А далі... виникає ситуація

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

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

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

Так, але це сумно та нецікаво (звісно, за бабло клієнта — все що забажаєте))...

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

PS. Фанати Rust мають рацію: примусити кожного явно описувати час життя та правила овнершипа — єдиний спосіб тримати лад на великих проектах...

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

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

Навіть якщо вся кодова база на C++ але бінарі компіляться різними тімами (аплікуха з плагінами), різними компіляторами, то воно не працюватиме, й зовнішній інтерфейс повинен бути Сшним з Сшними АПІшками й простими Сшними структурками...

Втім, це не скасовує того, що зручно поюзати «синтаксичний цукор» всередині модуля :)

В «няшній Сшці» його і далі нема...
всі оті __attribute__(( cleanup(( чототам )) )) - то нестандартна самодіяльність авторів компіляторів...

втім С++ також бракує «такого defer як в go» щоб не городити класи...
що, втім, вирішується через макроси (й то може виглядати «майже як go»)

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

Особливо печально коли ото люди «перевинаходять» VMT й «ручками» заповнюють ті всі таблички, танці з бубном довкола ініціалізації і так далі...

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