На захист C++

Якщо почитати що в WWW пишуть свідки революційно асинхронного JavaScript, поціновувачі геніального Go і такого неймовірно безпечного Rust, то можна виділити дві тези:

  • C++ (або інша непопулярна мова як наприклад, олдфажний Pascal) підвласна лише геніям які змогли опанувати цю мову лише через 30 і 3 роки безперестанного навчання.
  • Програми на C++ пищать та псують текст пищать та псують оперативну памʼять.

В звʼязку з цим хочу звернути увагу на те що довкола нас мʼяко кажучи немало програм на C++, написані вони аж ніяк не пробірочними геніями з закритих академмістечок і за всі роки користування компʼютером нічого страшного я не пригадую.

І друге: псують памʼять і справляють враження недоробленої кустарщини чомусь саме скрипти на JavaScript та інші подібні середовища де програмісту нібито не треба слідкувати за памʼяттю і все робиться якось саме по собі. Випадки коли, яка—небудь вкладка в браузері доїдає другий гігабайт оперативки не те щоб рідкісні. Або внутрішнє життя програм на Java за яким інколи можна спостерігати, коли програма нічого не робить, але все таки щось там відбувається що видно по графіку використання ЦП.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

краще б новий режим до c++ додали замість rust

До речі, ж питаннячко щодо конкурентів.
Ктось знає, нафіга гугль якийсь карбон пиляє, якщо вже раст є ?

А нафіга гугл пиляв го, коли існував php, а нафіга гугл розробляв дарт, коли є джаваскріпт?

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

Ну конкретно дарт розроблявся для заміни джаваскріпта, і намагання гуглом завендорлочити розробку під їх браузер. Бо вони і дарт зробили, і ангуляр на цьому ж дарті писали, але потім шось пішло не так. Власне флаттер писали чуваки, яких гугл кікнув з команди розробки дарт-ангуляр.

а на місце жабаскріпта — тайпскріпт!!!

Краще не треба.

а шо не так?
Чи ви з тієї категорії розробників, які супресять ворнінги тайпскріпта, а коли качаєш собі проект і починаєш перевіряти код, то там мінімум 6 помилок у коді у логікі використання хуків?
github.com/...​4#issuecomment-3643542330

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

Коли дивився авторський огляд відносно хісторі мов програмування B (typeless) -> NB -> C (statically typed) — там доволі ясно з чим такий перехід було пов’язано. А відносно statically typed TS — в чому саме недоліки у порівнянні з JS вбачають?

Якщо ви вішаєте на ногу гірю, то бігати з нею стає не зручно. TS дорожчий за JS, як би парадоксально це не звучало.

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

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

Втретє, ви не можете ніяк впливати на швидкодію коду, робити оптимізації, бо у вас «компіляція». Значить будете пожежу тушити ресурсами користувача.

Це якась нова форма троллінгу писати такі комменти, які не мають більше 10% спільного з реальністю?

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

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

Може кави?

TS дорожчий за JS, як би парадоксально це не звучало.
Втретє, ви не можете ніяк впливати на швидкодію коду, робити оптимізації, бо у вас «компіляція». Значить будете пожежу тушити ресурсами користувача.

Це якесь грунтовне нерозуміння шо таке TS і з чим його їдять.
programming-language-benchmarks.vercel.app/typescript-vs-javascript

TS фактично виконує перевірку типів на відповідність деклараціям, далі все це компілюється у чистий JS.

Можете навести якісь приклади де ви побачили те, про що написали?

Можете навести якісь приклади де ви побачили те, про що написали?

Легко. Проблема не в тілі функції, проблема в кількості методів, класів, модулів, які треба створити, щоб код був красивий з точки зору статичної типізації. Кожний зайвий інстанс їсть памʼять, вимагає роботи GC, на виклик функції будуть витрачатися дорогоцінні ресурси (які ви звісно ж не цінуєте, а батарейку мобіли чи планшету берегти все ж таки треба). І оптимізувати кол стек, наприклад, ви не зможете.

По-друге, ви мусите більш ретельно обдумувати архітектуру,

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

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

Ваші аргументи зрозуміли, те, що ви любите писати Г-код, це зрозуміло, і те, що є ще армія таких як ви — це теж зрозуміло.
Одне не зрозуміло, чому ви вирішили що це правильно? Ви вже визнали, що такі речі як архітектура вам не зрозуміло навіщо існують, на цьому можна завершувати діалог, нє?

TS знижує поріг входу у проект для нових розробників

Ніхто не доводив це. Просто популярна казка, яку всім напарюють як загальновідомий факт.

запобігає виникненню помилок

Чергова байка для пересічних. В світі мільйони проектів написаних з використанням мов зі статичною типізацією. Назвіть хоч один складний проєкт, який активно розвивається та не містить жодної помилки.

пов’язаних з неправильними типами

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

дозволяє робити рефакторінг не через одне місце.

Проекти зі слабкою повʼязаністю та в яких використовуються DSL рефакторити ще простіше. Легкий рефакторінг — результат архітектурних рішень, а не типізації в мові програмування. Я вам можу привести дуже багато принципів, як можна досягати ще кращого рефакторінгу з будь-якою мовою програмування та будь-яким рівнем розробників.

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

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

Одне не зрозуміло, чому ви вирішили що це правильно?

Досвід. Практика.

Ви вже визнали, що такі речі як архітектура вам не зрозуміло навіщо існують

Звідки така впевненість? Може все діаметрально протилежне? Не спадало таке на думку?

інфраструктура для транспайлінгу

то не лише про TS а й JS в JS також досі транспайлять...

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

JS також досі транспайлять...

Це трохи інша проблема. Я тільки мініфікую. Та вирішив повністю відмовитися від будь-якої збірки за допомогою нодівських бібліотек, на кшталт вебпака, гульпа та іншого. Не ефективно в моєму випадку.

«вебасемблі прийде, порядок наведе»))

:D Не можна одну проблему вирішувати за рахунок створення іншої...

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

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

Бо як продати своє костильне чудо чуваку, який за 5 хвилин і одну команду може тебе звільнити за результатами ревью коду, якість якого не налізає ні на жоден стандарт?

то це максимально не стосується комерційних проектів з якими працюють, переважно, низькокваліфіковані розробники.

Ви зараз намагаєтеся знайти кореляцію там, де її не існує за замовчуванням. Якщо у вас є низькокваліфіковані кадри, то вам треба давати їм задачі відповідної складності, щоб вони не могли нічого «зламати». Тобто давати інструменти по рівню кваліфікації. І мова йде не про статичну типізацію, чи динамічну, а про фреймворки в першу чергу. Кращим варіантом взагалі буде обрати Domain Specific Language (DSL), який дозволяє досягати результату на високому рівню, приховуючи всі деталі реалізації від розробника.

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

Бо як продати своє костильне чудо чуваку, який за 5 хвилин і одну команду може тебе звільнити за результатами ревью коду, якість якого не налізає ні на жоден стандарт?

Наче й слова знайомі, сенс сказаного не зрозумілий. Навіщо ви сюди ще код ревʼю додали?

Це нормально, шо не зрозумілий.
Людина, яка скаржится на те, що її змушують продумувати архітектуру і малює відсотки овкрхеду по рантайму через використання ТС — наврядше зрозуміє Про що мова.
Але я пізніше більш груниовно дам відповідь на попередній ваш коментар.

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

Це мені пише людина, яка у якості аргументу за чистий JS приводить наступне:

По-друге, ви мусите більш ретельно обдумувати архітектуру, яка стає більш імперативною, ніж функціональною.

Ваш рівень я ще зранку побачив.

Адекватна людина обговорює обʼєкт. Неадекватна — субʼєкт.

Засоби розробки це один з головних бізнесів головного стоптегічного конкуркнта Google — корпорації Microsoft.
Це маркетингово необхідно. Поміттє Intel, AMD та ARM — концетруються лише на С, С++ та Fortran, разом із ассемблерами.

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

Так у Pascal свій комітет, стандарт древній ISO/IEC 7185:1990 Pascal
А так є FreePascal, Delphi — насправді він жвивий навідміну від Borland і т.д.
Питання не стільки в мовах скільки у виробниках засобів розробки. Скажімо GCC — це Red Hat/IBM та Google які вписались, ICC — це Intel/The Portland Group. Clang — Apple та Berklay. У Microsoft — усе своє. А Borland, Digital Mars і т.д. — і інші фірми без таких потужних маркетингових можливостей спочили.
Якось менеджер з яким я працював нині маркетинг директор в JetBrains в Мюнхені писав статтю про те як це працює. Як вивели на ринок той же Kotlin і що це чистої води маркетниг.

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

Були би ядра Unix написані на Pascal — усі робили би. Власне в Пентагоні і Карнегі-Меллон зовсім не дураки, коли топлять за «не С».
З іншого боку коли Кен Томпсон та Деніс Річі робили ядро саме на С, то це зовсім не тому, що вони так собі були в розробці мов програмування і ніхто їм не заважав викорастити щось по типу PL/1 чи Algol 68. Вони саме робили — те що і зробили.

Паскаль согласно позиции того же Вирта был дальше улучшен в направлении Modula (аж до 3-й). Я не включаю сюда Оберон, потому что он намеренно был сделан больше как единый флакон, чем универсальный язык — во времена, когда всё уже задавлено было C с потомками. Но масса детских болезней Паскаля была исправлена в Modula.

Паскаль же сам вырвался на свободу по известному принципу — в IT побеждает не лучшее, а первое минимально приемлемое (впрочем, такое много где).

Если сейчас смотреть в ту сторону, то нужно сделать нечто среднее между Modula-3 и Ada, без особых тяжеловесностей последней, но с максимальной защитой от типовых граблей, для чего упор на мощную типизацию.

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

Я вже не памʼятаю, на Паскалі свої ліби писати можна було, чи ні?

В лінії TP — BP — Delphi все було.
В стандарті ANSI (досить пізньому) теж було, але інакше.
В базовому зразку 1970-х не було нічого такого.

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

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

Ну, в першому Делфі не було особливо куди розганятися...

Паскаль слохпнувся, бо майкрософт переманив чуваків з борланда робити дотнет, а сам борланд ходив по рукам. Відбувся бізнес так сказати. Жирна мегакорпа з’їла корпу поменше. 1 в 1 як ситуація з гуглом і престо, а потім сиквел з гуглом і оригінальним еджом.

Мовний ландшафт буде сильно мінятися в наступні роки. Років через 10 популярними залишаться ті мови, на яких дуже добре пишуть AI-агенти.

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

Я думаю будуть мови над високого рівня, які вже формальний до якогось рівня промпт, аля то юзер сторі наприклад, будуть компілювати безпосередньо в миншинний код.
Оперувати на такому відносно низькому рівні абстракцій, як то цикли та оператори вибору, потреб більше не буде — відповідно вирішиться проблема ІТ бізнесу, кратно збільшити виробничисть праці без критичної втрати якості і підвищення ціни.
З точки зору бізнесу, уявіть — що ви можете створити прототип по факту із пітчу власної ідеї, за лічені дні. А до того, вам би довелось кликати цілу ватагу профільних спеціалістів, брати на роботу менеджерів для організації їх роботи тощо. Хочеш якись Uber або Netflix або Facebook і за день на тобі — усе що треба з точки зору софту, йди тестуй бізнес ідею.
Єдине але — переважна кількість людей логікою Аристотеля не володіє і формулювати структуровано свої складні мислі не здатна, тобто програмісти все ще будуть порібні, вони будуть більше схожими на бізнес аналістів.

:) getting momentum behind excerpting

уявіть
бізнес ідею
із пітчу
формулювати свої складні мислі
безпосередньо в миншинний код
бізнес аналістів
без критичної втрати якості і підвищення ціни
логікою Аристотеля

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

Чому «страждають»? І як ви порахували 100500 варіантів, дуже цікаво.

Чому «страждають»?

en.wikipedia.org/wiki/Most_vexing_parse
це тільки перше що легко знайти.

І як ви порахували 100500 варіантів, дуже цікаво.

Це 100500 позначає 19. youtu.be/h-zy1hBqT74

Ну це якщо після C++20 ще чогось не додали.

і чьо? це якийсь діалект плюсів?

c++ russia

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

Якщо ви не знаєте, хто такий Джосаттіс

Якийсь новий кумир мілленіалів? )) Чи просто автор книжок, один з сотень чи тисяч?

це тільки перше що легко знайти.

Counterintuitivе, в цьому проблема? ))) Ну а я вважаю польську нотацію контр-інтуїтивною, а також всякі Ерланги зі Скалами. Не подобається — обирай іншу мову. Це лише твоя проблема. А для вирішення проблем двозначних конструкцій синтаксису, давно існує typedef та using. Писати в поганому стилі можна будь-якою мовою, і це також не проблема мови, а проблема поганого володіння нею.

Ну це якщо після C++20 ще чогось не додали.

І це також, якщо не подобається щось нове — не користуйтесь. Не обов’язково в кожен проєкт пхати все що навигадували в стандарті. Беріть лише те, що знаєте добре.

Counterintuitivе, в цьому проблема? )))

В неоднозначности, що викликана незадовільною проробкою синтаксису. І ні, не всі випадки лікуються через typedef і using, інакше б в C++11 не додали {} для ініціалізації.

Писати в поганому стилі можна будь-якою мовою, і це також не проблема мови, а проблема поганого володіння нею.

Тобто стандартизатори додали засоби виправити ситуацію, а Thomas Anderson, вочевидь, вважає, що вони погано володіють мовою.

Не подобається — обирай іншу мову. Це лише твоя проблема.

Коли треба фактично вибирати з поганого і ще гіршого — а де-де проблема виглядає саме так — вона не тільки моя.

інакше б в C++11 не додали {} для ініціалізації

{} для ініціалізації було додано як загальний засіб, який працює в будь-якому випадку (особливо коли тип є неявним, оголошеним через auto, або як параметр шаблону). Нові засоби потребують нового синтаксису. І так є в будь-якій мові.

Тобто стандартизатори додали засоби виправити ситуацію, а Thomas Anderson, вочевидь, вважає, що вони погано володіють мовою.

Я вважаю, що хтось просто скаржиться на життя, бо воно не таке як має бути))

Коли треба фактично вибирати з поганого і ще гіршого — а де-де проблема виглядає саме так — вона не тільки моя.

Отож)

{} для ініціалізації було додано як загальний засіб

Я про те, що саме через Most Vexing Parse вони були вимушені зробити це через новий синтаксис — вибрали «{}» - а не через те, що було («()»).
А якщо б був нормальний порядок в визначеннях — проблеми б не виникло.
І це разом з новою милицею «using» показує, що синтаксична спадщина C дає проблеми.

Я вважаю, що хтось просто скаржиться на життя, бо воно не таке як має бути))

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

Не подобається — обирай іншу мову. Це лише твоя проблема.

Є купа ніш, де адекватної альтернативи досі не існує.

Браузери можуть бути як приклад? Якщо прийняти за показовий випадок, то який фактор найбільш критичний — об’єм коду, сама мова програмування, чи ще щось?

Ну відстрелити србі ногу в С++ набагато менше способів ніж у С, але коли ви це робите — то відстрелюєте її цілком.

Не згоден. В принципі розробка на Сі досить безпечна, якщо підходити правильно. На C++ багато робиться неявно, наприклад, десь забув std::enable_shared_from_this і лови core dump в деструкторі буфера в лямбді при асинхронних операціях...

В принципі розробка на Сі досить безпечна, якщо підходити правильно

Якщо дотримуватись правил, будь-яка розробка безпечна. Ваш кеп.

якщо забув std::enable_shared_from_this то в тебе просто не буде потрібного методу і воно не скомпілиться

не відходь від канонів:
“THE PROGRAMMER’S QUICK GUIDE TO THE LANGUAGES”
www.stsci.edu/...​~jboia/Public/shootf.html

Як казав один колега, перефразувавши Маркса, «нема такої підлости і ницости, на яку б не пішли автори GCC і Clang заради чергових 2% покращення в нікому не потрібному синтетичному тесті». Бо вони за такі показники отримують гранти.

Щонайменше в моєму звичному світу (Unix всіх типів) саме в цьому головне зло C++. Решта — небажання інших учасників вкладати гроші в те, що їм здається непотрібним саме для своїх користувачів, тому стандарти рухаються і компілятори разом з ними тільки тоді, коли найостанніший зрозумів, що без цього не можна.

Тому — шуміть. Пишіть всюди де можете про проблеми, хай лунає.

Дивно, чому це учасники не хочуть вкладати гроші в те, що їм непотрібно. Дичина якась. І стандартів як на мене, й так занадто багато. Все що треба, вже давно є в C++17.

Дичина якась.

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

І стандартів як на мене, й так занадто багато. Все що треба, вже давно є в C++17.

Ну от наприклад позбавлення від UdB в арифметиці там немає. Може, в C++26 нарешті зроблять хоч половину.

То зроби свої класи, в чому питання? Чому в стандарт, чому не ліба?

Чому в стандарт, чому не ліба?

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

А не розумію, чому компіляторні інтринкси мають бути частиною стандарту. Ну додай __builtin_add_overflow_with_exception
і компілятор буде знати те саме, що й про звичайний +: асоциативно, комутативно.

А не розумію, чому компіляторні інтринкси мають бути частиною стандарту.

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

Ну додай __builtin_add_overflow_with_exception

В стандарт?

Драбина-та висока була?

UdB з’являється через те, що C++ існує для безлічі архітектур, кожна з яких має власні особливості. Якщо треба щоб все було визначено, для цього існує C# з дотнетом.

Ну... C створювався як системна мова програмування, яка дозволяє використовувати всі особливості платформи. Коли ти пишеш операційну систему, то ти не хочеш щоб кожного разу, коли ти додаєш два цілих знакових числа, генерувався допоміжний код навколо, який корегує результат асемблерної операції до стандарту. Так, в сучасному світі складно найти екзотичні архітектури, чи живий там UNIVAC? Ну а C# це взагалі тільки x86 та aarch.

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

Але «чомусь» для беззнакових результат виходу за межі означений, а для знакових — ні. Хоча з точки зору асемблера вони однакові.

І в операційній системі можна явно помітити ті частини коду, в яких хочеться саме relaxed підходу за замовчуванням — і щоб це було не тільки для знакових. Якщо програміст впевнений, то хай розмічає.
А ось у 95% юзерленду оптимальна політика як раз виняток на будь-яку таку ситуацію.

Але «чомусь» для беззнакових результат виходу за межі означений, а для знакових — ні.

Тому що для безнакових результат однаковий на всіх архітектурах. А от для знакових це не так, наприклад, для UNIVAC 1100 мінус один це 0×11111110 (Ones’_complement) Там також є плюс нуль та мінус нуль (всі одинички). В асемблері там чотири різні операції додавання AA, ANA, AMA, ANMA.

А от для знакових це не так, наприклад, для UNIVAC 1100

Дякую, я в курсі про 1sʼ complement («зворотне» кодування в прийнятих тут термінах). Знаю навіть, як згідно йому рахуються контрольні сумми в IP.

Починаючи з C++20 і C23 підтримка всього цього виключена, тільки «додаткове» (0ʼs complement, чи на прийнятому жаргоні 2ʼs complement) кодування відʼємних. І то — останні архітектури, на яких ще було актуально якось інакше, залишились в 1980-х, якщо не раніше. Більш того, LLVM з самого початку декларований був тільки для 2ʼs complement архітектур, тому і Clang може компілювати тільки для них.

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

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

Далі, я просто хочу висловити свої думки з приводу переповнення. Які ніколи не будуть в С/C++ через зворотню сумісність. Але тут Ada попереду планети, Delphi на рівні.

Коли ми працюємо з кількістю, то будь яке переповнення в принципі зазвичай це помилка, при чому не важливо, знаковий чи безнаковий. Тому рішення Rust, коли singed/unsigned ведуть себе по різному, меня не подобається. Єдине виключення це модульні типи. Тому мене дуже дратують попередження signed/unsigned порівняння. Ну камон, якщо UB, то щось раніше пішло не так. А так порівнюй як signed, бо якщо у нас кількість, то я не памʼятаю, щоб вона була більше 2**31. Так, хеші, криптографія, але тут як в Ada модульний тип:

type RingBufIndex is mod 1000;
Все, кожен раз, коли ціле буде зберігатися в змінній типу RingBufIndex, буде взятий модуль і 1005 перетвориться в 5. Типи розрулюють, коли переповнення це помилка, а коли поведінка. До речі, бітові операції дозволені лише з модульними типами.

Далі, char знаковий... Ну знову тут Ada/Pascal, де є Byte для цілих, а є Char, який треба обовʼязово кастувати (або Ord). Зайвий гемор, що треба писати (unsigned)ch >= 0xA0.

Далі, якщо брати Debug-збірки, то всі UB імхо, мають бути або виключенням, або panic, щоб про це ставало відомо. Для вказівників також, не бачу проблему передавати зі вказівником розмір, та перевіряти кожне читання/запис. А якщо брати Release, то тут поведінку мають керувати опції, як в Delphi {$I-}.

Коли ми працюємо з кількістю, то будь яке переповнення в принципі зазвичай це помилка, при чому не важливо, знаковий чи безнаковий.

+100.

Тому мене дуже дратують попередження signed/unsigned порівняння.

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

Ada — да, зроблено значно якісніше.

Зайвий гемор, що треба писати (unsigned)ch >= 0xA0.

Таки не зайвий. Знову реальна ситуація: в лог виводиться щось, по типу
std::cout<<"value:"<<value<<"\n";
Тип цього value змінюють на uint8_t, і лог паплюжиться, бо він сприймається як char і виводиться як один символ.
Тому — типи цілих і символів мають бути розділені без неявної конверсії.

Далі, якщо брати Debug-збірки, то всі UB імхо, мають бути або виключенням, або panic, щоб про це ставало відомо.

Само розділення на debug і release тут дещо некоректне.
Для 95% коду і в релізі всі перевірки мають бути активні. Для 1-2% критичного по часу і в дебагу треба мати можливість їх вимикати. Тільки для решти це має твердо залежати від режиму.

Тому режим має бути контекстний, у стилі, як в C# зараз є

c = (checked) (a+b);

але з більшими можливостями:

func moo(a: int, b: int): int = {
  #next(int_mode(wrapped)) // діє до кінця блоку
  ...
  c = #(int_mode(relaxed)) (a*b+e*f);
}
(ну і так далі)
І ось тут можна додавати залежність від debug/release/etc. де хочуть:
  #next(int_mode(relaxed) if (release))
Точний синтаксис треба буде проробити, але без завдання для всього блоку (функції, одного виразу) чи його решти (до кінця або до наступного режиму) не обійтись.
Можливі режими для арифметики з цілими:
checked (генерує виняток)
checked_with_flag (задана змінна, в яку пишуть 1 при проблемі)
wrapped (усікається)
saturated (береться крайнє) — з допоміжних
relaxed (програміст гарантує непереповнення) — як зараз в C для знакових
Може бути ще якісь.

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

Ось з такою мовою можна вже досить сміло щось серйозне робити...

Тому рішення Rust, коли singed/unsigned ведуть себе по різному, меня не подобається

Можно подробнее?

UdB з’являється через те, що C++ існує для безлічі архітектур, кожна з яких має власні особливості.

З того, що цю можливість стали абьюзити замість тих самих 2% всупереч тому, що хотіли програмісти.

Можно пример архитуктуры, которая требовала, чтоб пустой бесконечный цикл приводил к «проваливанию» в какую-то рандомную функцию?

social.hails.org/...​hailey/112147785725190189

Он может быть и решает, но я б хотел услышать ответ на свой вопрос.

Ось Вам відповідь на ваше питання: isocpp.org/...​files/papers/P2809R3.html
Це було визнано дефектом стандарту і буде пофікшено в С++26.

Т.е. поинт UB в данном случае не в том, что есть «какая-то архитектура, которая имет свои особенности» (о чем говорил предыдущий оратор).

Поинт UB в том, что оно Undefined только в общем случае. В конкретном случае, какой-либо определенной архитектуры и компилятора, любое UB вполне себе defined, и либо документировано, либо может быть определено в процессе тестирования. А без тестирования, все равно никакой продукт права на жизнь не имеет.

Виявляється, лівацтво несе шкоду не лише в політиці, а й в програмуванні ))

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

+100500, але що «C++» що «няшна С-шечка», обоє страждають «стрікт аліазінгом» майже однаково... (ну в Сшечці ще restrict є... а тим, хто в С++ зробив доступ до «нетого» мембера юніона «андефайнед біхевіор» — взагалі треба руки повиривати... й std::bit_cast — лише костиль довкола того)

Ничего не имел против С++ долгое время пока не начал на нем писать. Язык простой (типа си-подобный), и в нем за последние 50 лет почти ничего не поменялось (ну епта, 50 лет работало и нахрена его менять ?). А, ну смарт поинтеры завезли и можна в forEach() поиграть, а так все по старому. Ждем модульной компиляции, а то строчку кода поменяешь и ждешь час билда. Из претенций — в мире с++ полно задротов. Ну хотябы требование к форматированию что бы код влазил в 80 знаков, типа имена мы уже как в джава пишем ЭтоДогоеИмяОбъясняетВсеПроЭтотКласс, а лимит 80 знаков никуда не делся, все как 50 лет назад короче !!! И еще по дибильному юнит тесты пишутся, везде есть мок фреймворки и т.д. В мире с++ люди предпочитают фейки, и что бы еще в фактори завернуть — настоящий клас в код, а в тестах что бы фейки, и обязатьльно в тестах показать насколько ты разбираешься в смарт поинтерах, не дай бог в ручную прибить какой то объект. И побольше енумов, они типа не дадут тебя забыть какой то из них. А потом ты пишешь на джава и вспоминаешь с++ и людей которые на нем пишут как сон — как можна загнать себя в таки рамки и там жить ? Ну понятно ты 10 лет на плюсах седел, но если ты каждые пол года меняешь стек — как можна не видеть эти задротства ?

если ты каждые пол года меняешь стек

Тоді з тобою щось не так.

Ну або такий бізнес і такий ринок. От мене останнім часом носить проміж :Kotlin, Node.JS і от тепер ще і Python. А ще давай типу Kubrnetis, Teraform в черзі , та треба вивчити Angular та Apache Spark, в той самий час доводилось і писати авто тести засвоїти ра базовому ріні Cucumber тощо. Це объективна реальність на ринку — червоний океан конкуренції і щоби залишатись на плаву необхадно мати доволі штрокий асортимент навичок. Клієнт заоаз хоче таких собі мега стек інженерів. В цілому за допомогою ШІ це поступово стає можливим.

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

А такі речі як Kubernetes та Terraform від стека не залежать. Вони скрізь.

обожеж ти мій.

и в нем за последние 50 лет почти ничего не поменялось

Стандарт C++11 — 1250 сторінок. C++17 — 1605 pages. С++20 — 1930. С++23 — 2049.
Точно нічого не помінялося?

Ждем модульной компиляции

Модулі з’явилися в С++20.

Ну хотябы требование к форматированию что бы код влазил в 80 знаков

Вимоги до форматування в кожному проєкті свої. Ставте собі скільки хочете, мова того не забороняє.

И еще по дибильному юнит тесты пишутся, везде есть мок фреймворки

І в С++ є. GoogleMock — фактично стандарт.

обязатьльно в тестах показать насколько ты разбираешься в смарт поинтерах

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

не дай бог в ручную прибить какой то объект.

І правильно, чим менше ручного меморі менеджменту — тим краще.

Я чесно не пишу на c++, але доволі часто чую що з модулями не все так гладко. Через те що кожний виробник копіляторів робить це по своєму.

Робить, ну то й що. Беріть Clang і юзайте його реалізацію кругом. Якщо Гугл на ньому Хром написав під всі ОС, то і вам підійде.

І всю інфраструктуру збирання теж копіювати з Хрома?

Інфраструктура збирання Хрома вирішує купу різних задач. Дивіться самі, чи воно Вам треба. Швидше ні, ніж так.

"

C++11 — 1250 сторінок. C++17 — 1605 pages. С++20 — 1930. С++23 — 2049.

— как ты мог все это знать? может ты и есть один из тех людей кто делает с++ языком задротов?)) Прошли те временя когда ты мог взять и на проекте просто поменять ширину кода, счас все работает типа — мы пользуем рекомендации такой то компании к форматированию и просто акцептите это. Про поинтеры — хорошее изобретение, но мозки выносит сильно. Одно дело — ты пишишь код с нуля и лепишь смарт поитнеры там, другое дело ты добавляешь код в проект которому 10 лет, давай добавь свои смарт поинтеры к старым не смарт поинтерам и 3р библиотекам которые частично смарт а частично не смарт, потом твой код просмотрят задроты и начнут расказывать что смарт поинтеров можна было бы и больше написать...Тоесть всесто того что бы думать над бизнес логикой ты тратишь время на выбор дата стракчерсов, их создавание и их удаление из памяти, даже в юнит тестах ? И ты будешь думать что все ок пока не начнешь писать на джава и жс, и только потом оглядываясь назад ты поймешь что с++ маст дай !)

Відносно тільки одного пункту — робити якісь висновки по мовам програмування виходячи з рекомендацій по форматуванню — а в інших мовах не існують відповідних практик рекомендацій від слова зовсім?

счас все работает типа — мы пользуем рекомендации такой то компании к форматированию и просто акцептите это.

Як це мови стосується? Вас компанія може заставити стрибати через скакалку на будь-якій технології.

другое дело ты добавляешь код в проект которому 10 лет, давай добавь свои смарт поинтеры к старым не смарт поинтерам и 3р библиотекам которые частично смарт а частично не смарт

Ця проблема була актуальною десь в 2011 році. Після цього std::unique_ptr/std::shared_ptr/std::weak_ptr стали стандартом і за 2-3 роки всі живі проєкти на них перейшли. Якщо щось було мертвим вже в 2011 році і не мінялося з того часу — ну, співчуваю в такому проєкті копатися.

І правильно, чим менше ручного меморі менеджменту — тим краще.

Швидше видаліть це, так і до GC недалеко

Я би навіть сказав, що С++ 98 і С++ 11 вже різні мови програмування. Далі переломна віха С++ 20. Реальна архаїка тим не менше в Modern C++ є і позиція в комітеті зі стандартизації дуже потужної присутності Microsoft, блокує в сутності пропозиції Google прибрати цю архаїку та отримати 15% буст із продуктивнісю, разом із тим зламавши зворотну сумісність по ABI. А по суті у корпорацій діаметрально протилежні бізнес інтереси в цьому випадку, одним треба скоротити кости на сервери і 15% краща продуктивність коду це мільярди з економічних коштів на електрику і т.д. Для інших зберігти зворотню сумісність для софту який працює на мільярдах пристроїв по усьому світу.
Саме тому, наприклад, із пулом потоків не можуть розібратись 5 років.
Моя особиста позиція на стороні Google, ABI так чи інакше з часом доведеться зробити не сумісним.
Переписувати десятки мільйонів строк коду на С++ на Rust чи ще щось, без змістовно, навіть з допомогою ШІ.

Где вы насчитали 50 лет? Первые коммерческие реализации появились в 80-х. Модульная компиляция давно есть, библиотеки называется — пользуйтесь. Лимит 80 знаков это дичь, конечно. Я стараюсь влазить в 120. Юнит тесты пишутся так, как позволяет язык — это ж не C#, где есть интроспекция и можно генерить IL-код на лету. Остальное видимо, следствие вашей профдеформациb после долгих лет на Java ))

и в нем за последние 50 лет почти ничего не поменялось

Якщо візмеш код С++98, та щось написане вже на С++20. То це майже різні МП.

Те, що якість чуваки в 2025 пишуть спп код, де напряму юзають рау поінтери, інклуди замість модулів і іншу хрінь типу typedef не каже про те що мова не змінилась.

за всі роки користування компʼютером нічого страшного я не пригадую

Настільки товсто, що серйозно коментувати немає сенсу. Тому я просто залишу тут mohitmv.github.io/...​ined-Behaviour-In-Action

Растаманов набирают. Набегайте, кто в теме.
www.linkedin.com/...​wLr-Lh2Rt5GGvg934JGoZRRl4

Ну що взлетить п"ятнична тема?

Згадався анегдот про голодних звірів у ямі.
— Давайте з’їмо самого слабкого.
— Заєць: «Не чіпайте медведя»!

Заєць

заходить Раст у кімнату... слухав-слухав... — А зато я збираюсь найдовше!

Зайченок (JS/npm): А мне папа вчера машинку купил!
Лисенок (Rust/Cargo): А мне папа велосипедик купил на той неделе!
Мишка (C++/WTF): А я!! А мне!!! А я вам всем щас 3.14зды дам

велосипедик купил на той неделе

з трохи поржавівшими колесами, а зато не так падає, бо квадратні колеса ще необкатані)

на лого таки коліща, так що не потрібно ляля про квадратні колеса

на лого таки коліща

то вело-колеса такі для зручності придумали? хмм..

так що не потрібно ляля про
що взлетить п’ятнична тема?

може і взлетить якщо колеса підрівняти і наждачкою пройтися)

вело-колеса такі для зручності

в С++ на лого якась гайка на 6 граней

якась гайка

після велосипеда все може виглядати гайкою, навіть 3D hexagon)

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

С++ник... Rustаман..
це тільки вид зверху

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

С++ — язык графики. Появился во времена позднего DOS, расцвел на Wintel десктопе, сейчас нишевой язык игр/3D/обработки видео.
Отрицать его, как и пропагандировать за пределами этой ниши — глупо.

Я майже згоден. Хочеться вірити що це не зовсім так та в мене немає відповідних знань.і досвіду. Просто коробить від Rust і його фанатиків. C++ майже те саме, але не таке бридке.

А як же Хромог, Alcohol 120%, Adobe reader, PDF-Xchange editor, всякі там дефрагментатории і оптимізатори для Windows, EyeDefender і подібні програми, архіватори, фаєрволи, антивіруси, FlylinkDC++, Notepad2, Notepad++, Sublime text, KDE і вагон програм на Qt, Clipdiary, oMegaCommander, XnView, Cinta notes і т.п.?

сейчас нишевой язык игр/3D/обработки видео

настільки зараз вузька ніша — really?

пропагандировать за пределами этой ниши — глупо

:) нп браузери.. та навіть llvm

p.s. ніша ігри/3D виглядає в майбутньому досить зручною для Odin, хоча мова програмування доволі нещодавно тільки і створена (тому невідомо у що виллється якщо популярною стане)

С++ сейчас нишевой язык игр/3D/обработки видео.

писав на C++ і різних його варіаціях як C++/CX десь майже 5 років, що працював в Майкрософті, в тому числі компоненти ОС. Пишу на ньому ж останні 3 роки в Гуглі і твердження про нішевість С++ дуже далеке від реальності.

Отрицать его, как и пропагандировать за пределами этой ниши — глупо.

Ви не повірите скільки всього і в яких доменах написано на С++, спробуйте порахувати навіть тут chromium.googlesource.com/...​ads/main/chrome/renderer або тут github.com/...​tree/main/src/CalcManager або тут sources.debian.org/src/apt/3.1.5/methods

А кто сказал, что это -хороший- софт?

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

Їм користуються мільярди (не мільйони, а саме мільярди) користувачі в усьому світі

Миллионы мух никогда не ошибаются.
Чем шире аудитория продукта — тем больше он похож на дерьмо.

Чем шире аудитория продукта — тем больше он похож на дерьмо.

Зазвичай в точності до навпаки — чим більше аудиторія, тим вище конкуренція, тим вищі стандарти якості і вимоги до якості коду, безпеки і надійності. Бо інакше конкуренти тебе замінять чимось кращим, 0.01% проблеми надійності означає що вони впливають на сотні тисяч користувачів, а найменша проблема безпеки фактично гарантовано буде знайдена і використана.

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

И шо? Большая конкуренция у Windows?

Звичайно і дуже значна.

Не треба плутати домінантну позицію на ринку десктопних ОС і конкуренцію. Як тільки Windows стане гірше, то почне втрачати долі ринку і заміщуватися конкурентами (MacOS, ChromeOS, Linux ітд), не одномоментно, поступово, але це втрата мільйонів користувачів. Як тільки в коді буде суттєва помилка безпеки — хакери її знайдуть і використають, найменша вразливість може обернутися глобальною катастрофою. Як тільки тільки буде допущена помилка в коді яка впливає на 0.01% користувачів — це вплине на сотні тисяч і про це обовʼязково напишуть в інтернеті.

Тому вимоги до якості коду, і відповідно результат, значно перевищують вимоги до невеличкої програмки на 10-20 користувачів зробленою на замовлення компанією Ратиці і Копитця, чиїм основним підходом до безпеки є те, що її ніхто не намагатиметься зламати.

хакеры-шмакеры ...
1. Винда необычайно тяжеловесна — в несколько раз больше юниксов.
2. Тормозная
3. Кошмарный UX, как и у всего Майкрософта.
4. Необыкновенно трудно настроить что-то кастомное
Но мухи продолжают садится.

Тобто: початкове питання вузьконішевості звелося до невдоволення віндовсами

А якщо лінукс софт на плюсах — те саме?)

Тут все наплутано — нішевість мови програмування, якість програм, якість продукту, якість UX і ваші субʼєктивні враження від користування. Давайте розберемо по черзі.

Винда необычайно тяжеловесна — в несколько раз больше юниксов.

С++ має мало звʼязку з цим, Юнікси теж використовують С++. Великий розмір це ціна за підтримку заліза і сумісність з старими програмами (тими самими, чиє використання часто спонукає користувачів залишатися з Windows) і рішення, що саме буде поставлятися з ОС, а що ні вирішують не тільки інженери, а і ті, хто ці ОС будуть продавати. Але цю проблему потрохи вирішують. Наприклад моя команда займалась цим www.windowslatest.com/...​t-for-better-performance для зменшення розмірів, що займає ОС в середньому випадку.

Тормозная

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

Кошмарный UX, как и у всего Майкрософта.

UX != інженери і не має відношення до С++. Але в будь-якому випадку UX це часто питання смаку і звички. Комусь он подобається Vim а хтось програмує пересуваючи мишкою блоки в якихось low code системи типу Power Platform. За кожною зміною UX стоїть експеримент і UX дослідження. І якщо його впровадили — то більшості підходить.

Необыкновенно трудно настроить что-то кастомное

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

Якщо привести аналогію з машинами — то деякі машини це Феррарі, а деякі автоваз адаптований для єгипетського ринку. І якщо для більшості людей Феррарі по якості буде краще за єгипетський автоваз, це не означає що вона краще по всім характеристикам бо для неї треба спеціальне паливо і багато, а автоваз можна заправляти і паливом розбавленим віслючою сечею і він, може, ще й поїде, бо датчиків-запобіжників якості палива у нього нема. Я не стверджую, що Windows це Феррарі світу ОС, ні, скоріше, що критерії порівняння як «субʼєктивне враження 1 людини» недостатні для обʼєктивних доказів всіх перерахованих недоліків.

PowerShell може приблизно все, коли мова йде про налаштування.

Ага. А ще є реєстр, Windows script host, Windows API і ніхто не заважає поколупатися в DLL і написати програмку яка буде робити щось таке незвичне. А от перезібрати ядро вже не можна, ніяких тобі KDE, GNOME, MATE, XFCE, TDE і віконних менеджерів.Завантажувач тільки один і з ним особливо нічого не придумаєш. Немає мішка файлових систем. Життя з домашнім каталогом на окремому розділі — суцільний головний біль.

Винда необычайно тяжеловесна — в несколько раз больше юниксов.

Винда тяжеловесна, по той простой причине, что в ней обеспечение бинарной совместимости с написанным за 20 лет кодом это абсолютный приоритет. И это есть основной фактор ее успеха на рынке. Потому что бизнес такое ценит. Write once — run forever.

Тормозная

Ну да, конечно. Игры почему-то только и делают на винде.

Кошмарный UX, как и у всего Майкрософта.

Ну это он по-вашему кошмарный. По-моему, идеальный (если брать Windows 10). А кошмарный он как раз в OS X.

Необыкновенно трудно настроить что-то кастомное

Что например, вам нужно настроить «кастомное»? Вы вообще имеете представление о WinAPI, чтобы делать такие заявления? Винда это система в первую очередь для десктопа. Во-вторую, для встраиваемых приложений, где нужен развитый программный стек и технологии UI, с долговременной поддержкой (25 лет для версий Embedded). Например для банкоматов и киосков самообслуживания. Ну а для серверов и легкой одноразовой электроники, ничего лучше Линукса конечно не придумали.

Но мухи продолжают садится.

На гнилое Apple, ага.

Винда тяжеловесна, по той простой причине, что в ней обеспечение бинарной совместимости с написанным за 20 лет кодом это абсолютный приоритет.

О да, ради бинарной совместимости с тем, чего ещё не было, придумали WMI.

Ради бинарной совместимости с тем, чего ещё не было, придумали NTFS с раздутыми структурами на диске и чудовищно запутанным драйвером, в котором лет 20 лечили «мелкие» проблемы и который в полном объёме понимает человек пять на всю планету.

Ради бинарной совместимости (с чем?) придумали 13 аргументов у CreateFile().

Ради бинарной совместимости (с VMS для VAX, что ли?) до версии где-то 3.51 любой сисколл гонял в ядро и обратно 4KB данных.

Можно как-то убрать эту «совместимость» из базовой поставки и чтобы она возникала только для тех, кому реально нужна?

Потому что бизнес такое ценит. Write once — run forever.

Как запустить приложение для MS-DOS на Windows 11? Без виртуалок, пожалуйста.

Настоящее Write once — run forever — это у IBM. Написанное под S/360 в 1964 году будет без изменения работать и сейчас, причём, если не системное, то и виртуализация не требуется, а если системное, то достаточно лёгкой (Base Control). А у Microsoft это кривой хилый закос под.

Ну да, конечно. Игры почему-то только и делают на винде.

Снизим пафос на два порядка, но процесс идёт. Винда становится слишком дорогой.

Ну это он по-вашему кошмарный. По-моему, идеальный (если брать Windows 10).

Каждый раз, когда надо что-то подстроить, я знаю, что уйдёт на это вместо одной минуты — до десяти в простом случае, потому что 1) функции разделены между Control Panel и Settings самым неочевидным образом, 2) придётся продираться через «облегчённые» настройки, в которых фиг выйдешь за пределы типовых случаев, а всё чуть сложнее сидит на третьем уровне всяких advanced settings.

И при этом всё равно не починили, что если всплывает новое окно, то открытое меню может схлопнуться, и нажатие пойдёт не туда, куда ожидаешь.

Например для банкоматов и киосков самообслуживания.

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

О да, ради бинарной совместимости с тем, чего ещё не было, придумали WMI

WMI придумали, чтобы легко можно было пользоваться из скриптовых языков (VBScript), а также из командной строки. Это тулза для администрирования. В чем с ней проблема?

Ради бинарной совместимости с тем, чего ещё не было, придумали NTFS с раздутыми структурами на диске

Скажите сразу, что вам название не нравится — аргументация того же уровня.

Ради бинарной совместимости (с чем?) придумали 13 аргументов у CreateFile()

Вы что-то путаете, у CreateFile всего 7 аргументов.

Ради бинарной совместимости (с VMS для VAX, что ли?) до версии где-то 3.51 любой сисколл гонял в ядро и обратно 4KB данных.

Что еще вспомним, может быть CP/M?

Можно как-то убрать эту «совместимость» из базовой поставки и чтобы она возникала только для тех, кому реально нужна?

Можно, называется Windows Embedded. Я правда давно с ней не работал, но раньше был Platform Builder, можно было составить свой образ без лишних компонентов.

Как запустить приложение для MS-DOS на Windows 11? Без виртуалок, пожалуйста.

Ну так реальный режим уже и процессором не поддерживается, в x64 он не реализован. Так что MS-DOS только на виртуалках. Приложения DOS кстати всю жизнь работали в виртуализации, если вы не знали.

А у Microsoft это кривой хилый закос под.

Кривой или нет — это ваша субъективная оценка. Объективно — старые приложения поддерживаются даже на уровне багов, для которых были сделаны пути обхода. Причем как на уровне приложений (в Windows есть специальная база данных, которая для протестированных приложений включает режим совместимости). А для не протестированных, можно выбрать просто Run as Windows 7 (Vista, 8, etc).

Каждый раз, когда надо что-то подстроить

Вам что, заняться больше нечем, каждый день что-то подстраивать? Подавляющее большинство настроек делается ровно один раз, максимум два если результат сразу не понравился. У вас наверно просто психоз, это тогда к другому специалисту))

Скажите сразу, что вам название не нравится — аргументация того же уровня.

Видно, что вы никогда не сталкивались с её багами. Ну, бывает.

Вы что-то путаете, у CreateFile всего 7 аргументов.

Описка. Всё равно нелепо много. А ещё вспомним, что регулярно требуется извратиться с UNC.

Что еще вспомним, может быть CP/M?

Можно и CP/M. Это будет относиться уже не к вопросу раздутости, но к тому, почему вместо нормальных названий дисков всех обрекли на вековые страдания с буквами, да ещё и сломали логику имён устройств.

Ну так реальный режим уже и процессором не поддерживается

Когда Intel хотел в пику AMD сделать свою кодировку для 64-битного режима (это не про Титаник, это именно про расширение x86), MS сказала, что не будет для такого делать Windows — и Intel взял под козырёк и остался с той кодировкой, что AMD сделала наспех, когда была нищей на грани банкротства.
Когда стоял вопрос о логике расширения для AVX, и выбор между стилями «надо разрешить явно» и «само приползёт» — MS выдавила второе, и имеем теперь абсурд с командой vzeroupper.
А с реальным режимом почему-то MS этого не захотела, хотя если бы сказала «надо» — Intel бы взял под козырёк. Или даже без него: переключаться между legacy и long больно, но вполне подъёмно, любой x86 процессор позволяет, и не такие извращения делали. Вот про это я и говорю: разговоры про бинарную совместимость как «абсолютный приоритет» это миф. Нету у MS такого правила. Максимум есть «если очень хорошо заплатят, мы подумаем».

Приложения DOS кстати всю жизнь работали в виртуализации, если вы не знали.

Virtual 8086 != полной виртуализации.

Объективно — старые приложения поддерживаются даже на уровне багов, для которых были сделаны пути обхода.

Сколько из таких ещё осталось? Большинство этих хаков было вообще для 16-битных приложений.

Вам что, заняться больше нечем, каждый день что-то подстраивать?

Про «каждый день» верните на тот потолок, откуда взяли. А если вы не представляете себе ситуацию типа «теперь надо добавить ещё польскую раскладку», «дорогой муж, а подправь мне чувствительность мыши» и пр. (может быть несколько раз, пока не найдётся оптимальный результат, и то может «плыть») — это ваши п/с проблемы, а не мои.

Видно, что вы никогда не сталкивались с её багами. Ну, бывает.

Бывает, что и палка стреляет. За мои почти 25 лет пользования виндой с NTFS, начиная с Win2K, как-то не сталкивался, да. Не считая случаев нештатного завершения, когда портился реестр. Ну абсолютный fault tolerance никто и не обещал.

Описка. Всё равно нелепо много. А ещё вспомним, что регулярно требуется извратиться с UNC.

Извините, но ваши аргументы все больше напоминают нытье. В винде хотя бы есть универсальный доступ к сетевым и локальным ресурсам, на уровне API. В линуксе с макосом таким и не пахнет.

Можно и CP/M. Это будет относиться уже не к вопросу раздутости, но к тому, почему вместо нормальных названий дисков всех обрекли на вековые страдания с буквами, да ещё и сломали логику имён устройств.

Кто ее определяет, эту «правильную» логику? Система с буквами дисков была простой и понятной — есть устройство, есть его название. И понятная до сих пор. А не путь где-то там от рута, который еще и монтировать надо. При любом подходе, найдутся люди, которые будут «страдать». В данном случае это вы, а все остальные привыкли и пользуются. Как МКПП в машине или шнуровкой в ботинках.

Нету у MS такого правила. Максимум есть «если очень хорошо заплатят, мы подумаем».

Вот именно. Сохраняется то, что реально востребовано. То что не востребовано, удаляется из системы. Но в целом, подход именно такой. Были бы кому-то реально нужны были DOS приложения, до сих пор, они бы поддерживались из коробки.

Virtual 8086 != полной виртуализации

Приложения MS-DOS это не приложения Windows. Можно еще OS/2 вспомнить, тоже поддерживалось до WinXP вроде бы (и то, в рамках 16-бит кода, т.е. до конца совместного участия с IBM). Если хотите взять на понт, ничего не выйдет) Здравый смысл никто не отменял.

А если вы не представляете себе ситуацию типа

Прекрасно представляю. И прекрасно помню, что где крутить. Плюс тоже самое на Андроидах разных мастей (гепловских поделий в обозримом периметре нет, бог миловал). Плюс собственный сервер на Debian. Вот последний реально жестяк, не дай бог какое обновление что сломает, считай пару часов увлекательного траха обеспечено.

есть устройство

5"25 флопік

есть его название

A двікрапки

Система с буквами ... была простой и понятной. И понятная до сих пор

для тих хто флопіки досі юзає

Флешки зараз, яка різниця? І не лише флешки — Google Drive так само має букви. І до речі, це дійсно зручно — бо є 4 акаунти, є 4 диски. Ти звик що G: це один акаунт, H: інший. Заперечувати що це зручно — ну не знаю, якась тупа впертість вже.

Флешки зараз, яка різниця?

в сакральності «A:» для 5,25 флешки)

І до речі, це дійсно зручно

монтувати з назвою яка зручна і там де виникає потреба, а не там де є знайома буква G

якась тупа впертість

назвемо так — C: впертість типу дос)

в сакральності «A:» для 5,25 флешки)

Нема ніякої сакральності. Ось я зараз призначив A: для флешки, можу показати:
res.cloudinary.com/...​/bdfjeovrhfaq4qkk4yu1.png

монтувати з назвою яка зручна і там де виникає потреба, а не там де є знайома буква G

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

інтуїтивно. І букви пристроїв

суб’єктивне використання практично взаємовиключних частин можна називати впертістю?

суб’єктивне використання практично взаємовиключних частин

Що саме є взаємовиключним та неінтуїтивним? Букви пристроїв існують з початку ери PC та є звичною практикою, а PC та Windows є досі домінуючою архітектурою на ринку. Нагадати скільки років? Вже 3 покоління на цьому вчиться. Це значно простіша абстракція, ніж оте «монтування» що для користувача виглядає як якась папка, яка з’являється десь сама по собі, і треба ще знати де і як вона з’явиться. На OS X цю папку дійсно відображено як окремий пристрій, але це омана. В Windows омани немає.

неінтуїтивним?

неінтуїтивні букволегасі типу G:

оте «монтування» що для користувача виглядає як

для користувача — у віконці чи якомусь докбар побачив у списку назву чогось (з більш-менш зрозумілою назвою)

для адміністрування etc. — ієрархічна система необмежена однією буквою (навіть G:інтуїтивною чи C:cакральною) — зручно

неінтуїтивні букволегасі типу G:

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

Ви мабуть окрім смартфона нічого не бачили. Для всіх хто користувався комп’ютером, а я впевнений що всі починали з Windows

яка показова я-самовпевненість у «всі»

Цьому ще в школі вчать. Ви прогулювали інформатику?

тобто цікавить не тематика підтеми, а хто що прогулював?)

В часи коли дос ще не було — чи була інформатика у школах...
а якщо була — як же тоді вивчали букви А-Б-Ц — містична загадка яка ще досі інтригує деяких осіб)))

В часи коли дос ще не було — чи була інформатика у школах...

Була, класи були на Yamaha MSX наприклад. Я сам в такому вчився, десь пару років застали ще. Що потім з’явилось не пам’ятаю, але вже вивчали Паскаль, то мабуть були PC AT. Але навіть на Ямахах, на вчительскому компі була CP/M (якщо вірити Wiki), а в CP/M диски теж позначались літерами. На учнівських компах ніяких пристроїв не було взагалі. На Спектрумах OS як такої не було, був системний монітор що мав 1 команду на завантаження даних що йшли з магнітофону через лінійний вхід. То ж це не пристрій в системі. А на дискових OS на кшталт TR-DOS вже були саме диски з літерами.

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

але вже вивчали Паскаль, то мабуть були PC AT

Трохи раніше починали з фортрану і макроасемблера, паскаль і сі були — але на тому «фортран»-залізі були настільки повільні що їх практично ніхто не використовував у розрахунках (хоча на ознайомитись було нормально). Ще трохи з того що було наводив у коментарях VN.

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

треба в меморіз внести, щоб будь-хто з майбутніх нащадків часів диску Це букви не забували)

В підсумку

після «Додати коментар ...» можна не додавати)

Трохи раніше починали з фортрану і макроасемблера

Макроасемблеру, серйозно? )) Це де ви таке бачили, на кафедрі якоїсь кібернетики в КПІ? Дуже масове явище, ага. Якби вся країна так.

хоч взнали трохи що існувало поза диском Це, а то школа школа ...)

«пристрій позначається буквою»

з двокрапкою

Есть куча людей, которые начинают свое ознакомление с компьютерами именно со смартфонов/планшетов и потом с макбуков, и таки да, не знают ничего про какие-то там буковки.

и таки да, не знают ничего про какие-то там буковки

Что-то мне подсказывает, что такие люди не только про буковки не знают, а вообще практически ничего. Кругозор размером с яблоко.

назвіть то яблукозір versus дискцезор :)

для адміністрування etc. — ієрархічна система файлової системи необмежена однією буквою (навіть G:інтуїтивною чи C:cакральною) — зручно

Якщо дуже треба щоб все було в одній ієрархії, то змонтуйте пристрій як папку, NTFS таке підтримує. Або як symbolic link. Ну щоб зовсім як в лінуксі.

забувши нещодавнє зневажливе «оте монтування» пропонуєте «змонтуйте»)

забувши нещодавнє зневажливе «оте монтування» пропонуєте «змонтуйте»)

Це ж ви того хочете, не я.

В винде хотя бы есть универсальный доступ к сетевым и локальным ресурсам, на уровне API.

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

Система с буквами дисков была простой и понятной — есть устройство, есть его название. И понятная до сих пор. А не путь где-то там от рута, который еще и монтировать надо.

У вас проблемы с чтением сообщений собеседника. Не пути от рута, а имена дисков. Если вы не в курсе: в RSX-11 с аналогами было, например, что где бы системный диск ни находился, для него есть алиас «SYS», в путях — используется типа «SYS:COMMON.LIB». Алиасы можно назначать от админа достаточно произвольно. А ещё когда отправляешь, например, FOO.TXT на принтер, создаётся «PRN:FOO.TXT». Вот это у MS сломали и не восстанавливали, а в результате имеем проблемы типа такого, где я без UNC не могу гарантировать, что мне не подсунут AUX.CPP (реально был когда-то в MySQL) или COM³.TXT, который завесит программу от попытки доступа.
И нормализовать тут оба аспекта было бы банально, но MS продолжает хотеть, чтобы было через зад.

Приложения MS-DOS это не приложения Windows.

Эта формальность за отмазку не канает. Под DOS написано огромный объём софта, а автор оси та же MS.

Прекрасно представляю. И прекрасно помню, что где крутить.

Специально запоминали 100500 частных случаев «вот это в Control Panel, а это в Settings, а это вообще в отдельной тулзе». Мне моя голова пока что дорога в разумном состоянии.

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

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

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

Вопрос субъективный. Для меня это абсолютно естественно, что любая прога из коробки поддерживает сетевые пути.

Если вы не в курсе: в RSX-11 с аналогами было, например, что где бы системный диск ни находился, для него есть алиас «SYS»

Ну так в винде системный диск всегда будет C: — так было еще со времен DOS. Трудно запомнить? Можете назначить Volume Label если трудно. Обозвать флешки как PHOTO или BACKUP, в Проводнике будет сразу понятно что есть что. Google Drive их сразу создает, с именем аккаунта — тут вообще без вопросов.

который завесит программу от попытки доступа

Ну вот я создал в Far три файла — AUX.CPP, CON.CPP и PRN.CPP. Да из стандартного UI они недоступны, но ничего нигде не зависает. Согласен что сообщение могло бы быть и более понятным, чем «Elevation required» или «File not found», и удалить их стандартными средствами нельзя. Но и создать не получится. Far может создать файл с именем хоть из одного пробела.

Эта формальность за отмазку не канает. Под DOS написано огромный объём софта, а автор оси та же MS.

Написано, но софт под DOS уже история. Оно сейчас если где и работает еще, то на всяких контроллерах, с дисплейчиком 16×2. Сам писал под такое 20 лет назад.

Специально запоминали 100500 частных случаев «вот это в Control Panel, а это в Settings, а это вообще в отдельной тулзе»

Такое ощущение, что вы застряли на системе 10 летней давности. В Win10 22H2 путь ко всем настройкам идет через Start — Settings. В Contrl Panel уже практически ничего важного нет. А то что есть, имеет ссылки из нового UI. И все устроено более-менее логично. Поиск по настройкам помогает, если что. В крайнем случае открываете gpedit.msc и видите все что поддается настройке в виде дерева — логичней не бывает. Cтавьте лайк если не знали ;)

Вопрос субъективный. Для меня это абсолютно естественно, что любая прога из коробки поддерживает сетевые пути.

Ну если продолжаете пользоваться файловым шарингом в 2020х как основным методом... извинити (tm)

Ну так в винде системный диск всегда будет C: — так было еще со времен DOS. Трудно запомнить?

А кроме системного диска вы про какой-нибудь ещё слышали?

Ну вот я создал в Far три файла — AUX.CPP, CON.CPP и PRN.CPP. Да из стандартного UI они недоступны, но ничего нигде не зависает.

Недоступности достаточно, чтобы с этим были массовые проблемы у приложений.

Самое главное, непонятно, накойхер оно осталось в не-DOS, а тем более в Win64 приложениях.

Такое ощущение, что вы застряли на системе 10 летней давности. В Win10 22H2 путь ко всем настройкам идет через Start — Settings.

Именно что на 10ке стало резко хуже, чем на 7ке. Нет, не все. Многие оттуда недоступны, приходится идти через Control Panel. Это раздвоение известно всем, кто работает с виндой, но почему-то не вам.

В крайнем случае открываете gpedit.msc и видите все что поддается настройке в виде дерева — логичней не бывает. Cтавьте лайк если не знали ;)

11ка 24H2. gpedit.msc отсутствует. Вам дизлайк 👎

Ну если продолжаете пользоваться файловым шарингом в 2020х как основным методом... извинити (tm)

Да, продолжаю пользоваться. У меня есть NAS, который доступен через шаринг. Простые вещи должны оставаться простыми.

А кроме системного диска вы про какой-нибудь ещё слышали?

По-моему этот тред начинает превращаться в демагогию. Доказывать очевидное, знаете ли, утомляет.

Многие оттуда недоступны, приходится идти через Control Panel

Например?

11ка 24H2. gpedit.msc отсутствует. Вам дизлайк

Вы аж заставили меня поднять виртуалку и проверить:
res.cloudinary.com/...​/y3q94ey5g0quxl70gh3n.png

Как бы, сказанное вами не соответствует действительности.

Вы аж заставили меня поднять виртуалку и проверить:

На моей винде со свежекупленного лаптопа Asus его нет. Я ничего не делал, чтобы его не было.

По причине перехода Thomas Anderson на личные оскорбления в соседнем комментарии закрываю дискуссию с ним.

На моей винде со свежекупленного лаптопа Asus его нет. Я ничего не делал, чтобы его не было.

Ну как не делали. Вы купили устройство с урезанной версией винды (Home Edition). И теперь оказывается, что там чего-то нет, внезапно. Причем и не было никогда — начиная с WinXP как минимум. Просто детский сад (салфетка была намеком именно на это).

Ну так реальный режим уже и процессором не поддерживается, в x64 он не реализован. Так что MS-DOS только на виртуалках. Приложения DOS кстати всю жизнь работали в виртуализации, если вы не знали.

Тут интересный вопрос, MS ничего не стоило реально встроить в ОС программный эмулятор старой архитектуры для поддержки старого ПО про которое они так беспокоятся, причем оно б работало следующие 50 лет с нулевой поддержкой, но почему-то решили, что лучши поддержку дропнуть, что ставит под большой вопрос аргумент про любовь MS к совместимости со старым софтом.

Что ставит под большой вопрос аргумент про любовь MS к совместимости со старым софтом

Это ж не Windows-софт, почему он должен нативно поддерживаться? При том что и железо тех лет уже давно умерло и не имеет прямых наследников (звук, графика, периферия — все это не будет сегодня работать). А какая-нибудь БД на FoxPro или Clarion в текстовом режиме 80×25 с успехом взлетит в виртуалке, обеспечивая дополнительные плюшки вроде простых бекапов (VM snapshots), что для таких файловых систем как FAT было актуально. С другой стороны, Windows-софт уже не работает напрямую с железом, поэтому и поддерживается гораздо проще. Нет смысла в нативном DOS короче.

Это ж не Windows-софт, почему он должен нативно поддерживаться?

Что обозначают первые две буквы в слове MS-DOS?

При том что и железо тех лет уже давно умерло и не имеет прямых наследников

Да, но эмуляторы существуют и на них все прекрасно работает.

Что обозначают первые две буквы в слове MS-DOS?

Поставщика системы. У Майкрософт еще Unix был собственный, Xenix назывался. OS/2, которая должна была стать будущей NT, но не стала. Тоже нужны эмуляторы? А для OS/2 он был, между тем (поддержка 16-бит NE бинарников и вызовы API).

Да, но эмуляторы существуют и на них все прекрасно работает.

Возможно. Но это по больше части для старых игр. Серьезный софт для работы давно уже переписан под Win32, а если надо чтобы работал старый софт — я думаю, у Microsoft есть что предложить.

Вообще, смысл моего посыла «Write once — run forever» был в том, что так это делает Майкрософт, больше не делает никто. На линуксе — пересобирай пакеты под каждый новый релиз, а пока сидишь на старом, никакой новый софт тебе не светит. Даром что никакое новое ядро ему не нужно, а нужны просто библиотеки, которых в системе нет. А нет потому, что все сцементировано на системном уровне — невозможно обновить что-то одно и локально, надо обновлять все и глобально. Т.е. ты либо сидишь на старой системе со старым софтом, либо обновляешь систему и весь софт вместе с ней. Варианта обновить только систему нет.

В OS X Apple вообще срать хотела на старый софт — конечно, зачем его поддерживать, если можно нагнуть разработчиков чтобы они все переписали. А если разработчиков уже нет, то и хрен с ними — выкинем из аппстора, а взамен кто-нибудь что-то новое напишет. Ну или не напишет — скажем юзерам, что это для их же блага, не понимают своего счастья. А Apple потом поимеет процент с продаж. Профит!

«Write once — run forever» был в том, что так это делает Майкрософт, больше не делает никто.

Це робить також ядро Linux в парі з контейнеризацією, випадки ламаючих змін в сисколах там надзвичайно рідно стаються.

Т.е. ты либо сидишь на старой системе со старым софтом, либо обновляешь систему и весь софт вместе с ней. Варианта обновить только систему нет.

шукаєте схоже immutable os з розділенням на core/user та з їх атомік апдейтом системної частини, при бажанні знайдете (опцій з дистрибутивами достатньо, але то не системи диска Це)

Каждый раз, когда надо что-то подстроить, я знаю, что уйдёт на это вместо одной минуты — до десяти в простом случае, потому что 1) функции разделены между Control Panel и Settings самым неочевидным образом, 2) придётся продираться через «облегчённые» настройки, в которых фиг выйдешь за пределы типовых случаев, а всё чуть сложнее сидит на третьем уровне всяких advanced settings.

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

Нет, он постоянно в первую очередь вываливает в веб со страницами самых общих рассуждений на тему названных слов.
Настроить клавиатуру или то, что называется accessibility, как «пузырьки» локации мыши — через него идти тупо бесполезно, предложит всё что угодно, но не нужные пункты программ настройки.
Так что и это они сделали отвратительно.

Настроить клавиатуру или то, что называется accessibility, как «пузырьки» локации мыши — через него идти тупо бесполезно

res.cloudinary.com/...​/xxosukaldlyztyow9jx8.png

1. Каким образом «Ease of access» означает раскладку? У MS своя версия английского?
2. 11ка 24H2. Этих пунктов в списке нет.
3. Ну вот открыл accessibility mouse settings. Чтобы дойти до нужного, я должен докрутить вниз, дойти до additional mouse settings, которые откроются отдельно (а как же accessibility и какая связь с additional?), там среди интерфейса древнего стиля (95) найти это в pointer options (логика уровня «безумный бог») и только там включить.

Прежде чем давать советы, вы хоть пробовали сами проверить, о чём говорит другой?

1. Каким образом «Ease of access» означает раскладку? У MS своя версия английского?

Accessibility вы упомянули, не я. Хорошо, замените на «keyboard». Вам случайно салфетка для носа не нужна? А то сопли текут, некрасиво.

11ка 24H2. Этих пунктов в списке нет.

«А если найду»? Нет, реально вы думаете, что у меня нет на чем проверить?

Прежде чем давать советы, вы хоть пробовали сами проверить, о чём говорит другой?

Конечно. Поздравляю, вы справились. Может еще чем-то помочь?

Вам случайно салфетка для носа не нужна? А то сопли текут, некрасиво.

О, вы начали оскорблять оппонента! На этом считаю дискуссию законченной.

> Вообще, смысл моего посыла «Write once — run forever» был в том, что так это делает Майкрософт, больше не делает никто.

Повторюсь: единственный, кто так реально делает, это IBM. Как минимум в линиях Z (потомки IBM/360), I (AS/400), частично и P (POWER, RS/6000). А Microsoft делает в лучшем случае наполовину, очень ограниченно, после того, как ей пригрозят уходом с её решений (были примеры) и при всём при этом качество в последние годы упало в разы за счёт избавления от собственного штата тестеров.

> Т.е. ты либо сидишь на старой системе со старым софтом, либо обновляешь систему и весь софт вместе с ней. Варианта обновить только систему нет.

То есть про докер с кучей аналогов вы не слышали, как и то, что подобные решения на базе даже простейшего chroot() существуют ещё с середины 1990-х. Это если решать максимально прямолинейно, а есть и более хитрые методы.
Вам ещё многое предстоит узнать...

То есть про докер с кучей аналогов вы не слышали, как и то, что подобные решения на базе даже простейшего chroot() существуют ещё с середины 1990-х. Это если решать максимально прямолинейно, а есть и более хитрые методы.

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

По поводу chroot, это средство для повышения безопасности, а не совместимости. Чтобы софт работал с ограниченной видимостью файловой системы, в частности чтобы не было доступа ко всему /etc а только к собственным конфигам. Штука хорошая, сам недавно делал песочницу для одного сервиса на Golang, но вопросы совместимости не решает.

По поводу докера, это решение не для конечного пользователя. Это форма, в которой продукт должен поставляться изначально. Если у тебя обычный .deb пакет, то докер никак не поможет. Точнее, конечный пользователь тогда должен решать свои проблемы самостоятельно, создавая окружение которое требуется. Что он вряд ли осилит.

Если у тебя обычный .deb пакет, то докер никак не поможет. Точне, конечный пользователь тогда должен решать свои проблемы самостоятельно, создавая окружение которое требуется.

один з можливих варіантів гарантування runtime — snap/flatpak як засіб пакування, а з орієнтацію систем на «конечный пользователь» познайомтесь з immutable дистрибутивами як опцією

По поводу chroot, это средство для повышения безопасности, а не совместимости. Чтобы софт работал с ограниченной видимостью файловой системы,

С другой FS. В которой уже может быть что угодно, но другое.

chroot был для примера, что средства есть давно. Естественно, сейчас лучше использовать что-то вроде snap. Автоматизация этого для старого софта есть, я видел коммерческие решения, но названий сейчас не найду.

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

Или осилит, или заплатит. Главное, что система этому не мешает.

Чего-то я не понял, почему я другому человеку тут отвечаю. Артём, извините, промахнулся где-то.

я тут на днях на T480 намагався убунту поставити, мінт та кубунту.
Від чорного екрану до зависання інсталлятора на етапі вибора часової зони.
Стає тільки калі. Але калі у мене стає і на 12700h і на 12900К, і на старенький A200 тошибу.

Може це, варто перестати гратись у дитячий садочок з кастомізаціями і трохи зайнятись тим, аби догнати вінду у плані сумісності з залізом 6-8 річної давнини? Ну шо б ставало без «ой, може вам треба спробувати поставити без графічного інтерфейсу, напевно це сумісність з графікою
»

Образы Убунту 9-20 продолжают лежать в репозитории.

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

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

Бо для того аби вліпити мас-маркет лінух дистр на ще свіжий ноут з проциком 8го покоління — потрібно качати out of support версію дистра.

Я просто не можу зрозуміти, знаючи про таку дегенеративну особливість мас-маркет дистрів лінуха, навіщо пропагандувати це?

А ще, пропоную вам уявити що б ви писали про вінду (це теж відноситься до п1 — бо у нас ура-патріоти кудись зникли на переломі 19-20го року, а деякі з них, навіть по 300к почали отримувати) як би для того аби встати на процик 8го покоління потрібно було б качати тільки він7.

Час іде, зомбі-пропагандісти не міняються.

PS чесно кажу, я намагався поставити убунту як основну систему для розробки, чат гпт не рекомендує калі для цього. А все інше на тестове залізо не встає. Чи встане на 12700h — якщо воно не працює на старому, стабільному залізі? — хз, у мене просто нема бажання (я не настільки у дитячому віці, що б оце гратись у кастомізації вже, бажаю вам подорослішати, дореч) витрачати на сміття час.

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

чат гпт не рекомендує калі для цього

Біда, ну раз chatgpt не рекомендує, то все.
Цікаво, чому chatgpt забув про Debian, на якому що те калі, що убунту й базується.

свіжий ноут з проциком 8го покоління

btw, зараз десь з приблизно такого нетбука (з intel 8145U та uhd620 графіка) і пишу цей комент, був там спершу win11 — який зніс та поставив debian13+gnomeDE, нормально робить включно з тачскрін. Хоча була думка поставити cachyos чи свіжу ubuntu (не пробував на такому залізі) тільки заради того щоб потім отримати софт зібраний під x84-64-v[23] — але то не особливо і потрібно за овероптимізацією під проц гнатися, та мені дебіан зручний, реліз якого покищо достатньо свіжий, — тому на ньому і зупинився.

аби догнати вінду у плані сумісності з залізом 6-8 річної давнини?

Тобто почати відмовлятися встановлювати без TPM 2.0? :)

1) штучне обмеження, яке обходиться вентоєм або консольною командою.
2) корпоративні ноути вже давно з тпм2, ще коли мамкіни іксперди про нього і не чули.
УПС

корпоративні ноути вже давно з тпм2

Звісно. Але до чого тут корпоративні ноути? Специфікація TPM 2.0 війшла лище у квітні 2014, тому я більш ніж певний, що є моделі восьмирічної давнини без його підтримки.

штучне обмеження, яке обходиться вентоєм або консольною командою.

Ну так обійдіть штучне обмеження на встановлення linux на старе залізо встановленням іншого дистрибутиву.

ну то може у вас не стоїть, а у мене все стоїть.

В кого що болить... :)

Як тільки Windows стане гірше, то почне втрачати долі ринку

Якось занадто наївно. Коли вийшла Vista кидалися переходити на дистрибутиви Linux, коли вийшла Windows 8 було те ж саме, коли вийшла 11... Коли Яблуко перейшло на інтеловські ЦП окремі ентузіасти ставили Хакінтош. Гірше повинно стати просто капітально.

Коли мова йде про мільйоні і мільярди користувачів, будь-яка зміна впливає, бо завжди є користувачі, які перебувають у хиткому стані вибору. Кожний провал вартував долі ринку Windows. Інертність змін розтягує цей процес на роки чи десятиліття, але подивіться на долю FireFox або Internet Explorer. Навіть домінантна позиція на ринку не допоможе, якщо помилки призвели до втрати репутації.

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

Vista не була гіршою. Це була просто бета-версія Windows 7, яка стала абсолютним хітом, і яку можна використовувати навіть зараз (бо є підтримка в деяких каналах, що закінчується лише у 2026 році). Windows 8 була невдала версія, скоріше експериментом. Але Win 10 повернула позиції, і досі їх тримає. А щодо Хакінтош, то було і зворотнє — встановлювали вінду на геплівське залізо. Бо воно само по собі непогане.

Vista була гіршою в порівнянні з Windows XP. Все виглядало так ніби вони налажали і випустили щось з новою назвою аби не було асоціацій з недоробленою Vista. Краще б вони не випускали Windows 7 а таки доробили Vista хай би навіть для цього довелося випустити 10 сервіспаків бо в Windows 7 GUI став повільнішим (мабуть через переписування на .NET), нормальну панель задач замінили на вкрадений в Apple dock, хоч і не сильно та все ж перероибили оформлення в дещо гірший бік і в цілому Windows 7 якась ніби трохи повільніша.

Vista була гіршою в порівнянні з Windows XP.

Vista сприймалась гіршою, а не була гіршою. Бо якби вона справді була гіршою, Windows 7 не мала б ніяких шансів. Бо майже 90% (моя суб’єктивна оцінка, слід сприймати в сенсі «майже все») нового в ядрі та API було зроблено саме в Vista. Ну а оцінювати візуальну частину категоріями гірше/ліпше то взагалі не має сенсу. Особливо якщо врахувати засоби персоналізації, які можуть як повернути інтерфейс в стилі XP, так і увімкнути новий з ефектами Aero, якщо це подобається.

Коли вийшла Vista кидалися переходити на дистрибутиви Linux,

Так віста не була поганою системою, вона просто вийшла досить рано, віста мала запит на кор 2 дуо, а вийшла в світ віндовс хп сп2 на пентіумах. А коли світ вже массово перейшов на багатоядерні проци, вийшла уже віндовс 7 і віста просто стала непотрібна. І ніхто не кидався переходити на лінукс, залишались на XP до кінця, ну і багато не втратили, адже підтримку дропнули аж в 2014 перед виходом десятки.

Windows 8 було те ж саме, коли вийшла 11

Шо було з 11? Віндовс 11 найкраща вінда евер, вони перелопатили систему, дещо попереписували, вона стала надзвичайно швидкою у порівнянні з десяткою після третього редстоуна, і тим паче більш старих версій. Всі нахрюки на 11 вінду були від гордих власників помийних відер з 1155 сокетом. 1 в 1 як ситуація з десяткою, і тими самими власниками 775 сокета.

Всі нахрюки на 11 вінду були від гордих власників помийних відер з 1155 сокетом.

1155 сокет був ще до 1150 сокет я щойно перевірив на 1150 в мене ще досі ганяють 2 блоки 4160 та 4170 ще на вінді 8 треба до речі вінді 10 туди переставить просто щоб було

вінда 11 туди на сокет 1150 просто не ставиться

... щоправда я не перевіряв то вона пише що звиняйне ніт то я і повірив а чого ж не повірить то ж було трохи давно

і та сама історія з 775 сокет

1 в 1 як ситуація з десяткою, і тими самими власниками 775 сокета.

в мене так само ще досі є система на 775 просто вже ні куди там стоїть хп яка пережила декілька переходів через залізо і ще варкрафт 3 чи якось так я іноді дістаю хоча може вже складно бо я не точно пам’ятаю чи є там ще hdmi бо там мабуть лише dvi

а це було так давно що вже геть давно мабуть ще до революції при царі ))

... тож кажучи це маю що то є якісь дуже дивні користувачі які досі мають 775 сокет і які якімось чудом намагаються його всунути на вінду 10

... а чого тоді власне 10 а не той самий 8?

від гордих власників помийних відер з 1155 сокетом.

особисто не знаю таких і не зустрічав ніде зі свого інфо простору також що вказує слід що я все правильно роблю живу простим щире життя ))

Мухи не способны делать рациональный выбор. Человек — способен. И то что C++ сейчас это фундаментальная основа всего ПО, как раз и есть проявление этой рациональности.

І JS теж? Ви переоцінюєте людей. Тут як еволюція, хто перший захопив нішу. C++ був перший.

А что JS? Для своего основного назначения (веб-фронтенд) это вполне адекватный выбор. При всех своих недостатках, достоинства перевешивают — абсолютно аналогично C++. Но поскольку каждый уже промышленный стандарт в своей нише, это уже само по себе достоинство — т.к. технологии проверены временем, есть масса наработок, литературы и прочего. И кстати, быть первым не значит быть успешным. Xerox придумал UI, Apple его вывела в массы, но первой она не стала. Потому что продукт не соответствовал ожиданиям. А вот IBM PC соответствовал, потому и стал доминирующей архитектурой на десятилетия.

А що тут обговорювати, якщо вибору немає? Це як хвалити єдиний ресторан у селі за смачну їжу. Звісно, для веб-фронтенду JS адекватний, бо альтернатив просто не існує. Elm спробував щось змінити, але екосистема JS уже була настільки величезною, що новачки просто не мали шансів.
Далі, якщо є недоліки, то вже можна їх виправити і буде краще.
А от це «перевірені часом» мене завжди забавляє. Часто це просто означає «застрягли в минулому і тепер нічого не можемо змінити». PHP теж 25+ років «перевірений». Це просто не дає можливості іншим захопити нішу, то вимагає значних вкладень.

А що тут обговорювати, якщо вибору немає? Це як хвалити єдиний ресторан у селі за смачну їжу. Звісно, для веб-фронтенду JS адекватний, бо альтернатив просто не існує

Альтернативи і раніше існували, і зараз є. Наприклад був Silverlight, чудова технологія, в якої все було прекрасно. Окрім хіба що SEO, але мабуть з часом вирішилось би. Зараз є Flutter, у якого щоправда, так само складнощі з SEO. Але там де воно не потрібно, наприклад в якоїсь корпоративної CRM, то можна чудово все робити на Flutter, і забути про жахливий JS (хоча воно і транслюється в той JS і відповідно працює на JS движку). А все тому, що хтось вирішив що плагіни до браузера це погано...

А от це «перевірені часом» мене завжди забавляє. Часто це просто означає «застрягли в минулому і тепер нічого не можемо змінити». PHP теж 25+ років «перевірений».

Саме так — перевірений, зі зрозумілою поведінкою та великим досвідом застосування. Промисловий стандарт. Я ніколи не розумів, навіщо щось змінювати, заради того щоб змінювати. Хіба що знов взяти гроші за те саме. Але це огидно, і егоїстично. Ось як є одна компанія, яка весь час щось змінює, під соусом «прогресу» та «інновацій», але щороку дорожче і дорожче. Підказати назву?

Silverlight, чудова технологія, в якої все було прекрасно

А памʼятаю... Казала мені іди нахрен зі своєю FreeBSD. Технологія померла, бо вже був JS який працює крізь, а портувати .NET на кожну мобілку не вистачило ресурсу. Що ще раз доводить тезу про зайнятість ніші, та як важко витісняти.

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

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

А памʼятаю... Казала мені іди нахрен зі своєю FreeBSD

Був ще Adobe Flash, також технологія web-frontend. Набагато більш успішна, і якщо вірити чуткам, досі популярна в Китаї. Але її не вивчав, то ж як там з погляду розробника, х.з. Але Silverlight мені подобався (а Windows Phone 7 на ньому взагалі був цукеркою).

Я це саме кажу, ніша зайнята

Ну як зайнята, давно є і Python/Django, є Ruby on Rails — теж привабливі альтернативи, мають свої переваги. Але мають і недоліки, бо складно знайти хостінг — шареного майже не існує, треба брати VPS. А це значно дорожче. І ще Golang, так само.

А памʼятаю... Казала мені іди нахрен зі своєю FreeBSD.

Така доля у маргіналів. А ще Opera зазвичай помітно краще працювала в Windows а ще Flash, не знаю що там в FreeBSD та в Linux воно робили через пень—колоду. Особисто я відмовився від Linux бо зроблено воно не зовсім для домашніх комплюктерів та й монополія Windows не сприяє.

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

Вже був Flash. Silverlight — це як Flash від Microsoft. Якщо постаратися, то й зараз можна знайти сайти з Flash а от щодо Silverlight, то якщо такі ще є, їх прям дуже мало.

І що, в гулі реально ще цпп десь використовуть ?

Зверніться до публічно доступної інформації — medium.com/...​oogle-and-why-b798c509652. Так, це одна з основних мов програмування.

Старенька стаття, але ок.

The most important and used languages are the so-called Big Four: Python, C++, Java and Golang.

Ооо, 3 з 4 МП які я найбільш знаю та використовую.

Перефразовуючи

реально ще цпп десь використовуть?
Ооо, 3 з 4 МП які я ...

а шо реально сьогодні ще джава десь (крім legacy) використовують?))

Цікаво, я з цих 4 МП саме джаву не знаю і ніколи не писав на ній.
Але нічого особистого, просто так «карти склались».

я бы не был так категоричен, есть компании где с++ это язык первого выбора для всего — что вебстраницы что компиляторы сначала пишут не нем.

Есть компании, где все пишут на JS, даже embedded.
Но мы ж понимаем, что вкусовщина, а не объективная реальность.

С++ — язык графики

Вакансії С++, які мені пропонували рекрутери за останній місяць (при тому, що я роботу зараз не шукаю):
— Писати Автокад
— Писати Блумберг термінал
— Автомотів
— Писати Вайбер
— Писати якусь кастомну RTOS для якогось дивного заліза
— Писати плагіни до відеоредактора
— Писати торгівлю опціонами
— Писати гру

Лише дві вакансії з восьми стосувалися графіки та відео.
Ну і вцілому про популярність мови та затребуваність людей — вісім запрошень на співбесіду за місяць для людини, яка не шукає роботу.

— Автокад
— Автомотив — скорее всего очередные мультимедиа в тачку
— Вайбер = видео и звуковой поток.
— Видеоредактор.
— Игра.
С финансовым софтом я работал, они любят С++, но пишут в С-стиле. Был бы какой-нибудь GLib более хайповым- писали бы на нем.
Остаётся RTOS, кто же лекарь извращенцам.

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

Или желанием писать RTOS на С++.
Я например дропаю все С++ предложения, несмотря на ситуацию на рынке. Графики не знаю, а писать на С++, то что можно сделать на Go — не хочу.

Все, що можна зробити на Go, треба, звичайно, робити на Go. Але часто у людей вже є мільйон рядків коду на С++ і наступний мільйон рядків буде написаний теж на ньому.

Зная С++ переключиться на Go — как стакан воды выпить. Но люди продолжают писать CRUDы на С++, компилировать по часу, а потом искать текущую память.
Комбайном не косят газоны.

Зная С++ переключиться на Go — как стакан воды выпить.

даже не рядом сори

Конечно, лучше вообще забить на память и потом винить GC в том, что он ее плохо освобождает))

Ну вообще-то совсем не так просто переключиться — знаю по опыту. Местами не просто функции другие, а идоматика совсем другого типа.
И без реального наследования местами ой тоска.
Утечка памяти — полбеды. Битая, когда побитие взрывается через час — вот это реально горе.
Тут действительно писать на языках с MMM это надо отдельно учиться.

І все одно краще переписати, якщо в задачі нема такого, що суворо б вимагало саме C++.

Два останніх моїх проекти з категорії «embedded на потужній залізяці з Linux» були як раз такими, що якщо замінити там C і C++ на Go, то з ходу кількість багів скоротилася б на порядок.

Ось приклад багу: він просто чудовий:
Компонент A отримує запит по внутрішній мережі (загорнутий в Thrift) видати, не видаю з-під NDA, кількість... ну, наприклад, встановлених посудомийок і їх номери в локальному індексі.
Функція, що виконує це в A, отримує масив розміром 8 (їх більше не може бути) і повертає int8_t, який ⩾0 якщо успіх, і −1 якщо помилка.
Функція, що її викликає з колбеку мережі, читає результат в uint8_t, отримує 255 замість −1. Компілятор навіть ворнінга про проблемність конверсії не дає. Вона заповнює свій масив із 8 значень прийнятими 255 значеннями, дивом при цьому не крешачись, і передає відповід в мережу.
Компонент B приймає відповідь, заганяє 255 байт даних з мережі в масив на 8 елементів і крешиться.

Я не згадував ще, що використовувати звужені типи на зразок int8_t за межами пакованих структур це безглуздий злочин сам по собі — цьому тих індусів (справжніх!), що писали цей код, не навчити. Але на Go хоча б відловити помилку можна було швидко і без того, щоб крешнулось не там, де помилка, а в сусідньому процесі.

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

«І так у них все» ©.

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

отримує 255 замість —1. Компілятор навіть ворнінга про проблемність конверсії не дає.

а сам мікро процесор видає? бо прийде Христос і судити буде і мікро процесор теж буде на Суд Божий!

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

загалом то є на всіх працює без винятку зазирни у розподіл популяції за дефініцією там лише до 15% усієї популяції людей реально можуть вміти і доводити це писати не прутнем а базова популяція 70% то є самий максимум не пошкодити прутень собі та не пошкодити прутень машині

... для прикладу виявляється що у той макдональз влаштуватися маючи айкю 83 уже складно а маючи 70 уже рахуй не можливо тож селяві просто бізнес і робітників з окремої ліцензії прінцев мало і на всєх іх нє хватаєт

Функція, що її викликає з колбеку мережі, читає результат в uint8_t, отримує 255 замість —1. Компілятор навіть ворнінга про проблемність конверсії не дає.

І тому добрі люди створили www.boost.org/...​ion/doc/numeric_cast.html

«Добрі люди» зробили десятки таких ліб. У мене є власна така з одного з проєктів.

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

І ще:
1. Показаний numeric_cast уміє тільки перевіряти границі, але йому не можна явно і надійно сказати «а тут, навпаки, перетвори з усіченням (насиченням)».
2. На останок: в прикладі, що я навів, був C, а не C++. Тому ваша пропозиція про Boost.NumericCast в принципі недоречна.

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

В цьому, я думаю, і проблема. Поки пишеш власні велосипеди і не використовуєш С++, то воно так і буде — в кожному рядку треба бороти всі відомі і невідомі людству проблеми власними руками. То весело, поки молодий, але потрім набридає. Рано чи пізно розробка приходить до вибору якогось гарного фреймворку і довірі йому. Буст, Qt, можливо щось корпоративне, в геймдеві он купа гарних фреймворків, в мультимедіа, в фінансах, тощо. Береш і пишеш. Всі кути вже обклеєні м’яким поролоном, зручно.

В цьому, я думаю, і проблема. Поки пишеш власні велосипеди і не використовуєш С++

Ще раз мій головний тезіс: стандартна мова _не дає_ потрібного, і саме тому робляться власні доповнення.

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

Сподіваюсь на відповідь за суттю, а не міркування навкруги.

стандартна мова _не дає_ потрібного

Так, не дає.

і саме тому робляться власні доповнення

найчастіше — не доводиться, бо воно вже існує у вигляді гарної протестованої бібліотеки чи фреймворку. Он в мові С++ досі немає network чи графіки, але це ж не значить, що робота над проєктом, що їх потребує, почнеться з того, що Ви почнете це писати з нуля від рівня взаємодї з залізом. Ні, Ви візьмете потрібну лібу — та й буде.

Пропонувати і отримати офер дві різні різниці.
Спробуйте дійти до кінця процес найму.

Доходження (чи не доходження) до кінця дасть оцінку мені. А я ж кажу про оцінку ринку, потребу в людях і типах проєктів.

приблизно вимоги такі:
— програмувати RTOS, bare metal, Linux (ядро і юзерспейс)
— знати С і С++ останніх стандартів
— вміти CI/CD та AWS/Azure/GCP
— вміти low latency video
— паяти BGA і тп.
— їздити в поле та на полігон
— знати Compass/AutoCAD/Altium, вмітималювати схеми та розводити PCB 8 слоїв з глихими отворами та з шинами 1GHz+
— підбирати BOM
— користвуватися осцилографами та різними іншими спектографами з логаналізаторами
— знати аналовову техніку, ЦОС, RF, MatCad/Matlab/Simulink, знати АІ та Python/Torch
— ходити в офіс з 9-5 але понаднормово (відпочинок після перемоги, мабуть звільнять)
— проходити поліграфа (секюрність понад усе ж)
— мати оновлені документи для оформлення згідно КЗпП
— бути згодним на оплата вище ринку (40К ..50К грн. до податків, залежно від досвіду)

Compass

Це шо таке? Я б канєшн прикинув, що це расєянский Аскон Компас-3Д, якщо дивитись по подальшому списку, але не схоже.

Думаю, він. До інших вимог, я так розумію, питань нема.

P.S.
Забув ще FPGA/Verilog

бувають, але мова про середньо-геометрично-квадратично-медіанно з.п. з локальними мінімумами в якому ДП 15..20 Кгрн при «кадровому голоді» тому «змушені брати початківців», але стьоб щодо вимог у темі «на захист С++»

сейчас нишевой язык игр/3D/обработки видео

А также десктопа, большинства тяжелых приложений и практически полностью embedded (если считать C туда же).

Як на мене, Сі та C++ дуже різні мови. Навіть Zig, Rust ближче до C++ ніж Сі. Причина контейнери.

З першою частиною згоден.
Но до чого тут контейнери і які контейнери ?

мабуть ті що в STL (строка, масив, вектор, сет, черга, мапа ...) не докер контейнери ж?

Точно.
В мене 15 років були stl, а тепер рік кубернетеси.
Назва таж а сенс різний.

Во всіх цих мовах є контейнери з коробки, з якими люди звикають працювати. Виникає контейнерно орієнтоване мислення: має бути власник елементів. І коли запитуєш як це зробити, то відповідь буде з серії треба тут масив/вектор, тут мапу, тут ще, .. Це складові блоки мислення.

Якщо брати Сі, то там контейнерів немає, там списки (двозвʼязні, циклічні). І це трохи інші складові блоки. На Rust реалізувати двозвʼязні циклічні списки це горе. На Zig це можливо, але багато писанини з @alignCast. Тому вони відсутні навіть в стандарній лібі, я ось пробував вийшло так: dlist.zig Тому C++, Zig це можливо, але видно що так не роблять.

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

емм... це пан сам придумав, про «контейнери», чи звідки це???

Це моє пояснення того факту, що двозвʼязні циклічні списки дуже широко використовуються у коді на Сі, і не використовуються ніяк в C++, Zig. Ну а в Rust, C#, Java їх без unsafe не реалізувати.

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

ну ви вводите якийсь термін «контейнери», в який засовуєте одні структури даних, а інші — ні. крім вас його ніхто не використовує.
p.s.
в Java LinkedList якраз двохзв’язний. Що саме там не реалізували що вам було б потрібно?

ну ви вводите якийсь термін «контейнери»

Це термінологія STL: Containers library

Що саме там не реалізували що вам було б потрібно?

Нариклад, як елемент може видалити себе зі списку? А потім відмінити видалення?

void dlist_delete(struct dlist *item) {
    item->prev->next = item->next;
    item->next->prev = item->prev;
}

void dlist_undo_delete(struct dlist *item) {
    item->prev->next = item;
    item->next->prev = item;
}

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

видалити сама себе вона не може. що логічно

Не розумію логіки, на Сі це звичайнісінька практика, подивіться Linux Kernel. Те, що неможливо в Java, я постійно роблю на Сі.

з боку списку

Ще раз, список це просто необовʼязковий елемент списку, бо кожен елемент і є список. Якщо нам треба список, ми виділяємо елемент та робимо його списком, але це необовʼязково, якщо не треба, то ми можемо обʼєднати будь які два елементи у список без списку, а при ініціалізації кожен елемент буде списком з одного елементу самого себе. Що тут незрозумілого?

а звідки у вас взялась інфа про ноду

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

робите обгортку над стандартним списком

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

Не розумію логіки, на Сі це звичайнісінька практика, подивіться Linux Kernel. Те, що неможливо в Java, я постійно роблю на Сі.

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

Ще раз, список це просто необовʼязковий елемент списку, бо кожен елемент і є список. Якщо нам треба список, ми виділяємо елемент та робимо його списком, але це необовʼязково, якщо не треба, то ми можемо обʼєднати будь які два елементи у список без списку, а при ініціалізації кожен елемент буде списком з одного елементу самого себе. Що тут незрозумілого?

Оце все і незрозуміло, що ви намагаєтесь сказати.
Ок, крок за кроком, маючи на у вазі саме елемент, а не ноду;

Ще раз, список це просто необовʼязковий елемент списку, бо кожен елемент і є список.

До чого це твердження? У нас є список. Це структура, яка може тримати в собі елементи. Кожен з цих елементів може бути списком, а може і не бути. Умовно, не говорячи про примітивні типи, у нас там як елементи пойнтери лежать, які вказують на структури в памяті.

Якщо нам треба список, ми виділяємо елемент та робимо його списком

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

ми виділяємо елемент та робимо його списком

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

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

це взагалі «за гранню добра і зла» — мені абсолютно незрозуміло що ви намагаєтесь описати.

ок, знову про ноди (НЕ елементи)

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

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

Це структура, яка може тримати в собі елементи.

В Java так, але це дуже велике обмеження. Список це структура, яка містить в собі посилання, а не елементи.

де не наступити на граблі буде за щастя

От ілюстрація для вирішення exact cover (Судоку, ...)

res.cloudinary.com/...​/fxbpc3uk4znifjjovzwg.jpg

Знаходимо рядок з мінімальною кількістю варіантів, список додаємо до розвʼязку та видаляємо конфлікти (стовбчик). Після цього рекурсивно знаходимо інший рядок, ... після того як повернулися з рекурсії, відтворюємо те що видалили, та переходимо до наступного.

от була у нас друга нода в списку, у неї був пойнтер на першу, перша «самовидалилась» — куди вказує пойнтер другої,

На ту, що була перед першою. Класика же

first->prev->next = first->next;
first->next->prev = first->prev;
якщо first->next це друга, ти ми оновлюємо її посилання prev. У мене враження, що ви зовсім не розумієте про що йде мова. Щоб зробуміти двозвʼязні циклічні списки треба повністю відкинути Java досвід, бо він не відповідає дійсності.
це порушення принципу інкасуляції, але що таке «інкапсуляція» для сішника — дивний незрозумілий концепт.

Є static є handle. В принципі в Python її теж особливо немає, тому принцип не має бути догмою.

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

dlist_delete
dlist_undo_delete

Нічого не зробив з контейнером, наприклад не видалив
item->next ?

Логіка бектрейсінгу дає гарантію. От у нас є перебір: взяли елемент, зробили пошук, повернули його на місце, взяли наступний. Що буде, якщо ми його не повернули на місце? Ну баг буде.

Нічого не зробив з контейнером, наприклад не видалив
item->next ?

Так він буде видалений неодноразово зазвичай. Просто він має відтворитися. Це питання із серії, що буде, якщо користувач зробив lock на забув про unlock.

Якщо брати Сі, то там контейнерів немає, там списки (двозвʼязні, циклічні). І це трохи інші складові блоки.

на сі так само є масиви як шматки шматків пам’яті які ідуть підряд як то аж геть класіка кільцевий буфер з цього і починається

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

Тому першим ділом вони починають писати власні контейнери на зразок цих мов.

так недо люди вони такі )) втім звісно може вони навчаться але з досвіду вже навчався я так не думаю

на сі так само є масиви як шматки шматків пам’яті які ідуть підряд як то аж геть класіка кільцевий буфер з цього і починається

Є масиви, є кільцевий буфер. Але от вже realloc вважається поганою практикою, бо вказівники на елементи інвалідуються. Багато ліб живуть без нього. На відміну віж std::vector, де push_back одна з самих частих операцій, інвалідація ітераторів при модифікації контейнера...

Там вже років 10 як emplacemet_back використрвують.

какие такие контейнеры? )

обичні морські у нас такі по 2 в ряд один на оден возять по залізній дорозі

якісь одні якихось обічних дідотуристів возять, треба транслятор з туристичного додавати

Звісно що різні, бо перший процедурний, а другий ООП. Просто засоби C++ можна використовувати в будь-якому обсязі, не змінюючі підходу до проєктування. Наприклад можна мати API в стилі libcurl, але застосовувати об’єкти RAII для зручності. Або віртуальні функції, як це робиться в COM (Component Object Model). Можна відключити Exceptions, але залишити RTTI. Можна не використовувати STL та замінити її власним аналогом. Тобто C++ не примушує вас до якоїсь конкретної моделі. І це також фактор успіху.

Це теоретично, а на практиці C++ нагадує героїн: спочатку прикольно, бо дійсно уникаєш боілерплейту. Потім не знаєш як злізти.

Якщо брати ООП, то і на Сі можна бачити інтерфейси, наслідування, ... (GTK, WinAPI, msquic, ...) Фактично об’єктну модель через структури та функці, як я писав, про бойлерплейт. RAII до ООП відношення не має, зручно, але легко захопитися та розролювати виключення в деструкторі. Винятки так, але теж переускладнено та створює багато простору заплутатися. RTTI в принципі якщо треба, то часто своє пишуть.
Головний фактор успіху? Думаю що сумісніть з Сі (купа готових ліб), ООП хайп та можливість написати wnd.move(10, 20) замість windows_move(wnd, 10, 20). Для мене золотий стандарт ООП це Delphi, там дійсно все продумано. А С++? Ідеальна комбінація: готові C бібліотеки + модний ООП + синтаксичний цукор. Технічно нічого революційного, але маркетингово в яблучко.

Це теоретично, а на практиці C++ нагадує героїн: спочатку прикольно, бо дійсно уникаєш боілерплейту. Потім не знаєш як злізти.

Не розумію про що ви. Я перший код на C++ написав ще в 1999-му, і це був open source, коли ще навіть SVN не існувало. Патчі відправляли по Fido. І якось за цей час не виникло бажання «злазити». Навпаки, завдяки Qt, я вважаю нічого кращого за С++ зараз не існує.

Якщо брати ООП, то і на Сі можна бачити інтерфейси, наслідування

Так, але це не є безпечним з погляду перевірки типів. Статичний аналіз не допоможе, лише дисципліна застосування. То й же Objective C був набагато краще з цього погляду. Шкода до речі, що він не отримав популярності окрім як на Apple.

RAII до ООП відношення не має, зручно

Ну як не має, якщо це є базові механізми інкапсуляції. Об’єкт володіє ресурсами, об’єкт їх звільняє. В С таке не зробиш.

але легко захопитися та розролювати виключення в деструкторі

Щоб не захоплюватись, треба книжки читати. Кожен інструмент потребує навчання, бо можна й молотком по пальцях влупити.

RTTI в принципі якщо треба, то часто своє пишуть.

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

Технічно нічого революційного, але маркетингово в яблучко.

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

завдяки Qt, я вважаю нічого кращого за С++ зараз не існує

таксамо як стверджувати що

завдяки GTK, я вважаю нічого кращого за С зараз не існує

Можливо. Але для C це здебільшого милиці, застосування мови в спосіб, до якого вона не призначена. Бо це натягування ООП на процедурну парадигму. В той час як саме для цього призначений C++. Навпаки, Qt це саме доповнення С++ засобами, яких в ньому бракує (signal/slots що є втіленням Observer-паттерна майже на рівні мови, а також метадані/інтроспекція про що я вже згадував). Загалом Qt це повноцінний фреймворк на кшталт .NET, а не лише якійсь графічний тулкіт.

Якщо дивитися по результатам: обидва мейнстрім DE — Gnome та KDE приблизно однакові з рівня популярності у користувачів. Так і GTK чи Qt поміж девелоперів.

p.s. дотнет поза межами зацікавленості бо відсутній

Qt це ж не тільки KDE, це дуже популярний фреймворк для будь-якої платформи. На Windows багато чого зроблено на Qt — від Telegram з Viber-ом до як не дивно, офіційного клієнту OneDrive від Microsoft. Переносність коду майже абсолютна, особливо якщо UI робити на QML — десь на 95% все буде працювати просто як є (звісно, якщо немає коду, що явного залежить від платформи).

А ще можна згадати Automotive- та IoT-галузь, де там буде той GTK?

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

«Короля делает свита». Qt додає C++ саме тієї привабливості, якої йому не вистачає, порівняно з C# / .NET. При цьому зберігаючи всі його сильні сторони, які нікуди не зникають.

завтра придумають який модний рустреакт

Оцінювати вірогідності у найближчому майбутньому завжди можна:
— завтра полетять на Марс
— завтра напишуть Раст DE
— завтра перепишуть растом браузер

Що саме раніше відбудеться?

RS (Rust Script), а вже є

растом браузер

servo.org —> in progress github.com/versotile-org/verso

Раст DE

www.rust.de

RS (Rust Script)

це дві різні зовсім неоднакові вірогідності:
одна що з’явиться rustscript, інша що він стане достатньо популярним і на ньому напишуть крупні проекти

По прикладам браузери і DE:

Можна додати що не кажучи навіть про in-progress, багато release версій часто так і залишаються на рівні вузького кола ентузіастів. Тобто вірогідність широкого розповсюдження у майбутньому — відповідна може бути.

p.s. якщо відносно DE мало що чути покищо, то для мейнстрім браузерів оминути приклад Firefox буде важко

Так, але це не є безпечним з погляду перевірки типів.

Чому?

struct Cat* cat = (struct Cat*)dog; // Працює в обох мовах
struct Cat* cat = dog; // Не працює в обох
Я перший код на C++ написав ще в 1999-му,

Я писав раніше, але Borland C++ 3.1 навряд чи можна вважати повноцінним C++.

Навпаки, завдяки Qt,

Для мене золотий стандарт ООП це Delphi, там зроблено було набагато краще з точки зору дизайну мови.

Ну як не має, якщо це є базові механізми інкапсуляції. Об’єкт володіє ресурсами, об’єкт їх звільняє. В С таке не зробиш.

__attribute__ cleanup робить С ООП? Взагалі не бачу звʼязку.

Страуструп писав про це ще в перших своїх статтях про C++.

Ой, вірити маркетологу... Так, харизматичний дядько, але що по факту?

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

Ada була з усих боків краще, ІМХО

Цікаво, що якщо взяти унікальні фішки С++, то їх щось не дуже запозичували інші мови. Економія на ініціалізації полів класу (zero overhead). Жах. RAII, інші мови переробили більш людяно. Множинне наслідування... Ніт. Неявні перетворення типів... Ніт. Екземпляри класів на стеку. Теж. Автоматичне інстаціювання шаблонів? Привіт повідомлення про помилки. Одночасно вказівники та посилання?

Усі інше, синтаксіс obj.method() та VMT це Simula, виключення це Ada. Так, можливість передавати свої поля ніби-то унікально для С++ та перейшло в інші мови. В Ada там можна тільки назва класу та повідомлення, свої поля ніяк. Шаблони теж Ada.
Тому скоріше C++ став посібником як не треба робити мову програмування: люди подивилися на досвід використання... Та зробили по іншому.

struct Cat* cat = (struct Cat*)dog; // Працює в обох мовах

Тому що в C++ це зветься reinterpret_cast і не вважається безпечним. Це по суті, пряма вказівка компілятору «мені пофіг що ти там думаєш щодо цього типу, роби як я сказав». Навіть попереджень не буде.

Я писав раніше, але Borland C++ 3.1 навряд чи можна вважати повноцінним C++.

В мене був gcc 2.8 здається, і це було під OS/2. Трохи допілював редактор GoldED, коли автор припинив розробку/продаж та подарував його в Open Source. Але основні риси C++ на той час вже були (OOP, та здається exceptions). Перший стандарт тільки що вийшов. Те саме перше видання Страуструпа досі займає почесне місце в мене на полиці. Жовте вже від часу)

Для мене золотий стандарт ООП це Delphi, там зроблено було набагато краще з точки зору дизайну мови.

Можливо, з Delphi не мав справи.

__attribute__ cleanup робить С ООП? Взагалі не бачу звʼязку.

Це нестандартне розширення конкретної реалізації. І ні, не робить, бо це треба вказувати явно при кожному оголошенні об’єкта. Тобто треба про це пам’ятати — те саме, що вручну робити виклик free() по завершенню. Те що C++ робить автоматично, бо має концепцію об’єкта, а C не має. Але згоден, трохи нагадує RAII.

Ой, вірити маркетологу... Так, харизматичний дядько, але що по факту?

Він вчений, який маркетолог? Він розробив C++ для власних потреб, в той час коли працював в AT&T. Інші досліджувачи це оцінили та підтримали. З таким саме успіхом і Торвальдса можна назвати маркетологом. Вивчайте історію.

Ada була з усих боків краще, ІМХО

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

zero overhead

Це є принциповою рисою C++. Дорікати на це, все одне що дорікати тигру що він хижак.

Цікаво, що якщо взяти унікальні фішки С++, то їх щось не дуже запозичували інші мови.

Запозичували, але не всі і не одразу. Множинне наслідування інтерфейсів багато де є. Неявне перетворення типів теж, наприклад в C# (implicit cast operator). Так само екземпляри класів на стеку (C#). І вказівники в C# є. Ще скажи, що асемблерні вставки ніде не можна робити, і я скажу, що тому C++ і існує, що лише в ньому і можна))

Тому скоріше C++ став посібником як не треба робити мову програмування: люди подивилися на досвід використання... Та зробили по іншому.

І де вони всі? ))))

Тому що в C++ це зветься reinterpret_cast

Це називається С-style cast. В Сі це теж не дозволено робити без каста. Каст це небезпека. Яка відміна?

Те саме перше видання Страуструпа

Ну... а памʼятаю зелене видення 1991 року. Так, спочатку це було надихаючи, критика прийшла пізніше.

Те що C++ робить автоматично, бо має концепцію об’єкта, а C не має.

Це деталі реалізації, ну викликай автоматично деструктор... Суть одна й та сама. Знову це особливість С++, а не ООП.

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

Ну... останній стандарт Ada це 2022, вона досі жива. Але вона програла не С++, вона програла Сі (Turbo C 1.5 мій перший досвід). А С++ обирався через сумісність з Сі.

Це є принциповою рисою C++. Дорікати на це, все одне що дорікати тигру що він хижак.

Коли є ООП, то ми не рахуємо такти.

Неявне перетворення типів теж, наприклад в C# (implicit cast operator). Так само екземпляри класів на стеку (C#). І вказівники в C# є.

Не зустрічав, ОК. Хоча я більше за строгу типізацію.

Так само екземпляри класів на стеку (C#)

Ой, там по іншому зроблено. В Сі ти можеш обирати для будь якого класу. В С# виключно boxed типи, читай структури та скалярні типи. Звичайний клас з віртуальними функціями на стек не покладеш.

І вказівники в C# є.

Це unsafe, і ніби-то обмежене використання.

Ще скажи, що асемблерні вставки ніде не можна робити, і я скажу, що тому C++ і існує, що лише в ньому і можна))

Ой, в C++ там жахливий синтаксис. От Delphi, ностальгія, скільки таких вставок я робив:

function FastMultiply(a, b: Integer): Integer;
asm
  mov eax, a
  imul eax, b
end;
І де вони всі?

Поступово витісняють С++, доля нових проєктів на ньому падає. Особливо я для своїх пет-проєктів даунгрейдився на Сі.

Це називається С-style cast. В Сі це теж не дозволено робити без каста. Каст це небезпека. Яка відміна?

Бо в C++ є також static_cast, const_cast та dynamic_cast, що роблять більш безпечні перетворення, а reinterpret_cast без зайвої потреби це є поганий стиль. До того ж для похідних типів cast взагалі не потрібен, а в C навпаки, потрібен в будь-якому разі.

Знову це особливість С++, а не ООП

Це саме ООП, бо є частиною концепта інкапсуляції. Бо якщо у об’єкта є стан, мають бути засоби його ініціалізації та очищення. Інакше це не об’єкт, а проста структура (композиція). То ж деструктор і є таким засобом. Він навіть в C# є, finalizer зветься.

Коли є ООП, то ми не рахуємо такти.

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

Це unsafe, і ніби-то обмежене використання.

Це для того, щоб C# був практичний, щоб API-функції (__stdcall) можна було використовувати напряму, без бріджів/враперів.

Ой, в C++ там жахливий синтаксис

Від компілятора залежить, ось в MSVC наприклад:

int my_var = 5;
__asm {
    mov eax, my_var
    add eax, 10
    mov my_var, eax
}
Це називається С-style cast. В Сі це теж не дозволено робити без каста. Каст це небезпека. Яка відміна?

C-style cast поєднує декілька видів кастів в один, не уточнюючи, що саме змінюється. Це погіршує контроль компілятором і аналізаторами. Крім того, він не грепається. Тому в більшости регуляцій гарного стилю C-style cast заборонений, замість нього треба писати конкретний варіант *_cast, або навіть декілька ланцюгом, якщо потрібно. Краще більше слів, але надійно.

В С# виключно boxed типи, читай структури та скалярні типи. Звичайний клас з віртуальними функціями на стек не покладеш.

Воно само це робить, якщо escape analysis підказує, що можна.

Ой, в C++ там жахливий синтаксис. От Delphi, ностальгія, скільки таких вставок я робив:

Якщо мова про синтаксис GCC, то він, може, естетично і «не того», але він чітко описує входи, виходи, побочні ефекти, при бажанні параметризується («%4 — довільний регистр»), і тому ефективний, на відміну від того, що у Borland і MS, які для захисту від непередбачуваних проблем зберігають навколо такої вставки все, що можуть. Тому в GCC як раз все правильно. А MS в 64 бітах взагалі скасували такі вставки, бо не впорались з проблемою визначення точного контексту.
А що позначення там це окрема надто лаконічна мова — ну, на жаль.

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

Де підміна понять? Немає ніякої підміни.

C++ справді дуже переускладнений

Настільки що однокашники в технікумі писали простенькі двохвимірні ігри і клієнти до баз данних. Як погано що тоді не було нікого хто б пояснив їм що їхній куций розум не в змозі осягнути такий складний C++.

Є проста як двері мова програмування Сі. На С++ можна писати як на Сі. А можна з boost, asyncio, з використанням усього що там є.

Коли ти пишеш сам, ти не використовуєш того, чого не розумієш. В продакшені всі інакше.

Є проста (насправді не така й проста) як двері мова програмування JavaScript і CSS... далі мені було лінь передруковувати. Висновок: JavaScript справді дуже переускладнений сам по собі а якщо додати ще й ту ж верстку бо JavaScript існує не в вакуумі, і далі по тексту.

PS
Писати замість C Сі це якась інтелектуальна особливість чи що?

Є проста (насправді не така й проста) як двері мова програмування

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

JavaScript справді дуже переускладнений сам по собі

Згоден, але для Frontend реальної альтернативи йому немає. Тут як і в житті, хто перший встав, того й тапки.

Писати замість C Сі це якась інтелектуальна особливість чи що?

Ні, це скоріше звичка, на початку 90х часто можна було зустріти «Мова програмування Сі», от тільки коли мова заходила про конкретне середовищу розробки писали «Опис стандартних функцій Turbo C 2.0». Плюс інколи хочеться підкреслити відміну Сі від C++ хоча б написанням.

У москальщині москаль,
Полюбляє свій паскаль.
В Україні ми усі
Програмуємо на Сі.

у продовження аналогій з «лопатами»)

Сі проста як лопата

C++ лопата де з протилежної сторони держака встановлені вилки і граблі (періодично перевертаючи держак догори ногами можна використовувати у доволі широкому діапазоні робіт по господарству)

Rust лопата пофарбована нестандартна, але з safe рукавичками (по інструкції використовувати тільки з ними, але навіть виробники то часто і самі ігнорують), користувачі пробують приладнати її для любого типу сільгосп.робіт

На С++ можна писати як на Сі

дивлячись що розуміти під тим

ніши між ними в багатьох випадках пересікаються, але в багатьох і ні (reliable аргументація була нп.. від Лінуса)

дивлячись що розуміти під тим

Ну... хоча би просто не використовувати класи, віртуальні функції, ... Знаю проєкти, де заборонена STL, smart pointers, ... Просто С++ він як героїн, спочатку прикольно, давай це спробую, потім це... А потім не знаєш як злізти.

хоча би просто не використовувати ...

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

проблема меморі ліків в с++ фактично неактуальна років 15. зараз це вкрай рідкісні проблеми спричинені як правило кривою архітектурою або дуже старим слабо протестованим кодом. в той час як надмірне споживання пам’яті всякими java/javascript є дуже розповсюдженою проблемою яка зустрічається практично в 100% випадках.

проблема меморі ліків в с++ фактично неактуальна років 15. зараз це вкрай рідкісні проблеми спричинені як правило кривою архітектурою або дуже старим слабо протестованим кодом.

Блажен є хто вірує, тепло йому на світі ©

Один такий «дуже старий» код в проекті, де я робив, почався з нуля приблизно в 2012, інший в 2018. І ніхто тих супернових захищених полісі, які ви маєте на увазі, не застосовував. Це реальність комерційного галерного світу. Вважаємо, з 4 великих C/C++ проектів, де я робив «на галерах», така херня була в 3. Ітого 75%.

в той час як надмірне споживання пам’яті всякими java/javascript є дуже розповсюдженою проблемою яка зустрічається практично в 100% випадках.

Там хоча б ліки і шкоду даних легко відловити. Для цього і завищення витрат в 2-3 рази, як на зараз, можна вважати нормальним.

Головна проблема C++, щоправда не зараз — а колись була, бо зараз ренесанс разом із AI — був низкий маркет фіт.
В 90-ті та нульві ціла купа різноманітних навчальних программ різної якості, від С++ за 21 день до топових курсів провідних університетів типу Берклі, на плодили на ринку червоний океан конкуренції. На сьогоднішній момент те саме — це Frontend, з абсолютно аналогічних причин.
Так усе влаштовано, що взагалі усе в індустрії, оскільки ми живемо в капіталістичній системі, регулюється ринком і через зміну попиту на ньому, маркетинговими інструментами та інноваціями будь які навички можуть як повністю перестати мати попит на ринку, так і тимчасово, так і відновитись. Ілан Маск написав Zip2, тобто електронний довідник телефонів жовті сторінки для інтернету в 1996 році саме на С++. Тобто справа зовсім не в мові програмування, вона в бізнесі. Інтернет був новітньою інноваційною технологією в якій ряд бізнесменів, що зараз є найбагатшими людьми планети зробили бізнес, при цьому не маючи жодних гарантій успіху.
Таким чином той же Rust мало чого гарантує і якості тахнологічної конкурентної переваги, якщо немає проекту і роботодавця чи інвестора який обрав цю технологію. Щоправда як ми знаємо, станом на зараз це Пентагон, а там річний бюджет 810 мільярдів долларів цього року і 900 наступного.
Ну а скажвмо в GameDev — С++ як був так і є провідною мовою.

Підписатись на коментарі