Фільм і пару моїх думок про C++
Нещодавно вийшов документальний фільм про C++ за спонсорством Hudson River Trading: The Story of C++: The World’s Most Consequential Programming Language, який я дуже раджу подивитись. Причому не тільки C++ програмістам, а загалом людям, зацікавленим в індустрії. По-перше, через фундаментальний вплив C++ на галузь у цілому. По-друге, відео саме по собі цікаве. Наприклад, історія про дві різні версії CFront: 2.0 і 2.0.0.
Спершу я хотів просто кинути посилання, але поки дивився у мене назбиралося кілька думок, якими я вирішив поділитись. Тим паче, що не так давно C++ був гарячим холіварним топіком на форумі. Не те щоб ці думки були зв’язними і корисними, але вони мої і написані мною (не LLM).
C++ ховають уже не вперше. У
Зараз настала друга зима, але причини інші. Я можу виділити три:
- Rust. У питанні memory safety він справді безпечніший за дизайном. Уряди і регулятори прямим текстом радять переходити на memory-safe мови і відмовлятися від C++. Дуже велика спокуса писати safe-by-design код.
- Backward compatibility. Сила і наріжний камінь C++. Комітету стандартизації бракує рішучості зламати backward compatibility (що загалом зрозуміло), тому багато неоптимальних речей тягнуться ще з часів C++98. Причому деякі речі все-таки потрохи випилюють, але не такими темпами як хотілося б.
- C++ роздутий. Комітет генерує занадто багато пропозицій, які дуже довго обговорюються. Б’ярне жорстко підняв цю проблему у панельній дискусії 2025 року. Він скаржиться, що кількість голів підкомітетів стандарту досягла початкової кількості учасників усього комітету стандартизації.
Від себе можу потеоретизувати, що з AI стало ще гірше. Згенерувати пропозицію тепер набагато легше, тому комітет більшість часу займається тим, що каже «ні». Люди не готові до нового способу ініціалізувати змінну кожні три роки. Це дуже іронічно для мови, яка стандартизувала багатопотоковість і модель пам’яті тільки в 2011 році.
При цьому C++ не стоїть на місці. Static reflection уже проголосували в C++26. Саттер називає її чи не найвпливовішою фічею за всю історію мови, і я тут з ним погоджусь. Туди ж приїхали contracts і std::execution. Взагалі за останній час додали мільйон нових речей (згадуємо роздутість), про які можна штампувати матеріал тоннами — і однаково все не покриєш. Ідіоматичний C++26 код суттєво відрізняється від коду, написаного на C++14. Відчуття, ніби комітет лобіюють видавництва технічної літератури. Кожні 3 роки можна випускати нову партію книг.
Кожен ветеран індустрії, що себе поважає, або студент, озброєний модними технологіями, вважає за обов’язок прийти в коментарі і написати, що C++ вже мертвий і нікому не треба. Краще взяти *вставте тут улюблену мову* і насолоджуватись життям.
Почнемо з того, що C++ досі використовується всюди: gamedev (Unreal Engine), automotive, під капотом AI-буму через CUDA та HIP, компілятори (наприклад LLVM), HFT (згадаємо, що спонсор фільму HRT), браузери, супутники і багато чого іншого. І це незважаючи на те, що офіційний реліз Rust був 15 травня 2015 року (більше 11 років тому).
Із того моменту у людей був не один шанс щось написати/переписати на Rust, але далі окремих вузьких сфер типу крипти справа не пішла. І це незважаючи на те, що зараз можна купити компанію і переписати її код на Rust за допомогою Claude Code.
Тут трішки відійдемо від теми. Нещодавня показова історія: Anthropic у грудні минулого купила Oven і за пів року AI агенти портували Bun з Zig на Rust. У травні перепис змержили в main: вийшло більше мільйона рядків Rust коду, при тому що весь оригінальний код був близько 300к рядків. Аудит порту нарахував у ньому 13365 unsafe-блоків. Так, Bun був написаний не на C++, але масштаб витрат і результат «let’s rewrite it in Rust» показовий, навіть з використанням безліміту токенів. Якщо що, я не вважаю Rust поганою мовою. Мова — це інструмент, зі своїми плюсами, мінусами і сферами застосування. Тому ідеальної мови не існує.
Суб’єктивно, на додачу до того, що LLM досі пишуть не найкращий код, вони часто спотикаються на нюансах C++. Починаючи з мінорного: без додаткових інструкцій, чомусь, LLM завжди до constexpr-символів дописує inline, незважаючи на те, що фактична різниця між constexpr і inline constexpr є тільки для змінних в namespace scope хедерів (передаю вітання тому, хто зробив таку інтуїтивну поведінку). Закінчуючи відвертими багами.
Кілька разів Opus 4.8 пропонував мені повертати вказівник на елемент std::vector з методу, незважаючи на те, що цей вектор змінювався в інших методах. Для тих, хто не в курсі, вектор може реалокуватись, і відданий назовні вказівник може почати вказувати на невалідну пам’ять.
Щодо зворотної сумісності, Саттер ініціював cpp2, про який він на конференціях розказував вже не один раз. Ідейно, cpp2 для C++ є тим же, чим ранній C++ з CFront був для C. Тобто cpp2 компілюється в C++ код з повною сумісністю. Цілком можливо, що це стане майбутнім вектором розвитку C++, тому раджу з ним ознайомитись. У будь-кого є навіть можливість долучитись до розвитку цього проєкту.
Тепер про нас, бо в фільмі багато про комітет стандартизації. У списку регулярних учасників є Польща, Казахстан, навіть росія. України в WG21 відсутня. У нас немає national body, яке б цим займалося. І це незважаючи на те, що ми представлені у батьківському комітеті SC22 з мов програмування загалом. Є шляхи потрапити в стандарт не через national body, але я однаково не зміг знайти жодного українця у комітеті стандартизації. Це є великим нашим недопрацюванням. Чому так могло статись тягне на окремий пост. А ще в нас досі немає навіть C++ user group. Людей багато, але організованої спільноти немає. Можливо, хтось дуже скоро це виправить)
Резюмуючи, я думаю, що C++ переживе і цю зиму. Комітету вдасться налагодити роботу і зробити ще один якісний стрибок, як це було з C++11. І я дуже сподіваюся, що ми будемо до цього хоча б дотично причетні.
110 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівМопед не мій, тільки розмістив
агіткуоб’яву:А зачем С++ вообще нужен? Синтаксис таке, прямой доступ к памяти, наследование черт ногу сломит есть же friend. Разработка медленная, кломпиляция медленная. Скорость работы быстрее чем что? Другое дело язык С, без вот этих плюсов. Там по крайней мере понятно зачем он нужен.
Чтобы писать большой сложный софт, работающий с ограниченными ресурсами (надо выжать по максимуму из проца или памяти). Браузеры, базы данных, телефония и проигрывание медиа.
хіба браузери,
Redis — C
Asterisk — C
ffmpeg — C
а який саме варіант з плюсів, той що «С з класами»,
чи С++26?
Ну то ж умовно база — без аналітики.
Як пощастить — залежно року початку проекту. Хоча інколи затягають новіші стандарти — оно Хроміум оновлювали.
оно Servo обращували
Redis — це звісно C, а ось ClickHouse, MongoDB, MySQL, та і загалом більшість нових DB — це C++
В базах даних швидкість С++ не має особливого значення, так як запис на диск саме повільне місце
Так віддажють перевагу С++ над С, не тому що там байтики швидше записуються, а тому що він зручніше
dou.ua/...rums/topic/60022/#3089521
Ні, часто робота з диском взагалі на іншому сервері, чи через якусь асинхронщину. А найповільніше місце — це робота з індексами в пам’яті (в OLAP) або блокування рекордів (OLTP). А індекси намагаються тримати в пам’яті.
Ну не на 100% так. Когда оперативка это что-то вроде быстрого диска, а бывшее место оперативки по скорости занял кэш, возможность сложить байтики в памяти именно так, как хочешь, становится принципиальной.
Но C и C++ тут примерно одинаковы.
насправді, можливість складувати байтікі як хочеш залишиласть тільки в асемблера.
саме тому десь тут згаданий ffmpeg вроді як на С, але ледь не половина таки асемблер.
такаж ситуація і в кріптолібах, наприклад
Яку конфігурацію байтиків не вийде скласти у С++, або С, але вийде у асемблера?
до чого тут вийде або не вийде.
питання в тому як ти хочеш або не хочеш.
і це питання до того шо в с/с++ врубаеться оптимізатор і він може міняти послідовність операцій типу множення і ділення, наприклад.
чисто математично нічо не міняється, але представлення чисел в компі обмежене, тому деколи множення полюбе треба зробити першим.
якшо до кріпти, там намагаються зробити шоб обчислення йшли одаковий час не зважаючі на вхідні дані, зробити таке гарантовано для всіх компіляторов важко, або тупо неможливо.
По-перше, я не бачу сенсу збирати асемблерний код без оптимізатора. А якщо збирати з оптимізатором, то неважливо яка мова, оптимізатор у будь-якому випадку може туди-сюди операції переставляти. По-друге, навіть якщо скомпілювати асемблерний код 1 в 1, то всеодно воно не буде виконуватись в тому порядку, в якому написано, бо всі сучасні CPU мають out-of-order execution, який до того ж часто superscalar. Одному CPU відомо який там насправді порядок інстукцій. І це якщо не згадувати той факт, що інсткрукції не виконуються одна за одною, тому поняття порядку до них слабко застосоване
в яких асемблерах при оптимізаціях може мінятись порядок виконання інструкцій?
Ви праві, асемблери не переставляють інструкції
з оптимізатором :)
І ffmpeg і криптоліби — це не про розміщення в памʼяті, а про використання відповідних команд процесора, в яких вже зроблена адаптація під кодеки, і в які компілятор не згорне сам.
І то, замість прямого асемблера можна було використати відповідні інтринсики компіляторів, де вони є — і це активно теж використовується.
А памʼять там зазвичай такої ж орґанізації, як у випадку C/C++.
Asterisk начался во времена, когда качественного переносимого C++ не было на Unix, так что выбора не было. Но вообще вспоминать этот шизанутый кошмар как показательный пример разработки — разве что как такой тяп-ляп, который вышел в мир только потому, что он был первый.
Ffmpeg — похожая история, хотя чуть позже.
Redis — уже запросто могли, но просто не захотели.
Вообще весь софт Unix мира, стартованный примерно до 2015, страдает этим. Полноценной традиции использования C++ не сложилось до сих пор, и наполовину этому причиной ещё старая память, как всё было плохо20-30 лет назад.
Майже все, що можна написати на С, можна написати на С++, але швидше і зручніше. Що не так з наслідуванням? Якщо це про diamond problem — то є інструмент вирішення у вигляді віртуального наслідування. Використовувати friend — це моветон. С++ теоретично може бути швидше ніж С, бо на етапі компіляції можна передати компілятору більше інформації
Отут непомітні граблі.
Коли ти пишеш зручніше — то починається надлишкове використання фіч мови — віртуальність, generic контейнери, фрагментація в пам’яті.
В С поки напишеш — то руками оптимізується під кожен конкретний випадок, котрий в С++ йде з коробки.
По результату на С довше писати, але код часто працюватиме швидше, бо написаний оптимальніше.
от мені здається в 99% проектів виберуть зручніше і швидке (але з пенальті по оптимізаціям), бо інакше ми б і досі весь софт писали на asm/c а не на js/php та інших мовах високого рівня
А отой 1% залишився нішею С де є сильні обмеження або треба максимум вижати з архітектури...
мова йшла про зручність видачі bloatcode
Але ж по результату Пітон ще зручніший, тому напишуть на Пітоні, а не на плюсах.
от особисто мені, якшо вибирати між пітоном і С++ то пітон зручний поки все шо треба вміщаеться 200 — 300 рядків коду.
якшо ясно шо проект буде більший,я виберу плюси
А Джава чи Шарп з батарейками?
F#
Останнім часом я використовую Go
теж варіант, але мені особисто go не зайшов.
Ну, синтаксис у нього дійсно дещо наркоманський і мені його важко парсити очима. Напевно дається взнаки швидкий компілятор та молодість, що припала на 60-70-ті.
він не не те шо наркоманський. мені то і раст норм.
проблема шо коли я на нього дивився в ньому навіть генереків не було.
можна було легко отримати нулл з функції,і потім получити сегфолт.
і компілятор навіть варнінг не виводив 🤷♀️
а так да, компілюється моментально.
Go і зараз не вміє у flow analysis і не може гарантувати відсутність nil panic. Так, потрібно писати boilerplate перевірки, але автори вирішили, шо таков путь. Але, як на мій смак, збережено баланс між простотою і фічастістю.
Так во сколько раз.
Считаем переход, например, от питона к C++ и далее к C.
Первый переход — ускорили код в 30 раз, на написание потребовалось в 4 раза больше времени.
Второй — ускорили ещё на 25%, на написание потребовалось ещё в 4 раза больше времени (по сравнению с C++).
Сидим и смотрим — оно того вообще стоило?
Кстати, с Питоном не все так грустно. Например, нахождение максимума и минимума по колонке в текстовом дампе базы ускорилось всего в 3 раза.
И скорость разработки между С и С++ тоже может не сильно отличаться — смотря по проекту.
Звісно можна, бо Сі по суті це підмножина С++. Так, є мінорні відміни, які запросто пофіксить автоматичний транслятор. Проблема в іншому, С++ чимось нагадує героїн: на початку прикольно, а потім не знаєш як з цього злізти. Велика кількість багів в С++ це «не подумав що там під капотом».
Так, C++ може бути швидше Сі в шаблонах, проте це не дуже частий сценарій, головна ніша це фінтех.
А от чого бракує С++ так це формальної верифікації, більше того її й при моєму житті не буде :-)
Бліать,,, а я то думаю, чого в мене вже 2й рік ломка....
т.е. в Расте с синтаксисом типа всё ок?))
С++ слишком разный. Это и MPL, и Qt, и boost.preprocessor, и много чего другого, и каждый из них порой выглядит и ощущается как отдельный язык. Хоть и с возможностью их смешивания. Но в плане syntax-hell’а до Раста ему ещё далековато (по моему субъективному личному опыту, на Расте тоже пишу)
це про «макроси зло»?
а з компіляційон еггог в С++ «тіпа ОК»?
Вже років 10 як пофіксили
я имел ввиду, что несмотря на «разнообразие синтаксисов» в с++, rust у меня пока в топе худшего синтаксиса. Сама вот эта его мультипагадигма — смесь декларативщины с функциональщиной — сложно даётся мне
При чём тут friend, я в упор не понял (а вы сами хоть поняли?), а наследование простое и понятное, пока не включается множественное наследование, а оно крайне редко где и зачем.
Компиляция медленная только если вы начнёте подключать мегатонны всяких Spirit и Fusion.
Разработка в разы быстрее при наличии минимального понимания языка за счёт того, что
1) Не надо писать всякие страшно-многотонные `crr_trx_pkt_prc(pkt, moo)` вместо простого `pkt->process(moo)`, читать легче.
2) Сильно легче сократить в разы количество ошибок управления памятью, неправильной конверсии указателя, и т.п. и за счёт этого упростить, уже в десятки раз, отладку. Даже требование делать всякие reinterpret_cast вместо сишной конверсии уже помогает, по таким словам легче искать.
Да. Авторы Unix задумывали C как средство для написания шелла, awk и простейших системных утилит. Всё более сложное предполагалось писать уже на высокоуровневых средствах (шелл, awk, sed, позднее Perl, по той же линии пошёл Python...) Но дальше их линия была сломана желанием выжать максимум соков из железа.
А закон Мура?
Если ты имеешь в виду, что он начал останавливаться около2005-го, а сейчас вообще не работает по ряду показателей — то это было сильно позже периода, когда C вырвался из своей начальной ниши.
А в период, считаем, с 1975 по 1990 он был в полный рост.
Я про те
не було раціонально, так як
Было. При переходе на PC выжимали максимум что могли, просто из-за конкуренции.
Закон Мура в час великих машин? Та й зараз ціна заліза може диктувати вимоги програмісту: всунь щось велике в 64 байти оперативки.
Я ведь практик. Работал на проекте в 2013 году где множественное наследование было основой, а friend был нормой, ни когда не забаду тот дебаг.
А когда подключаешь MFC,ATL компиляция тоже медленная )))) Она вообще всегда медленая потому что без библиотек как бы не попрограммируешь особо.
Синтаксис stl просто убивает все желание. Хочется думать над задачей, а не бороться с языком, бывает надо бороться с библиотекой, с Win32 API например, но с языком это уже слишком.
А вот Си я практически использую, редко, но метко. Зачем. Например что бы написать библиотеку для использования в Python проекте.
Практика — она разная бывает.
Я подряд на двух галерах работал на сходных проектах, телеком, установки системы «крутой embedded на линуксе на дальних площадках, есть доступ по ethernet, но хрен тебе клава или дисплей». На обеих C++. Но на первой наследование (не множественное, к счастью) во много уровней, на другом вообще не было, сразу классы конкретного вида. На одном компиляция с
-O3, на другом с-O0.Так что искренне сочувствую, но если там не просто множественное наследование, а ромбы, то это настолько редкий и извращённый случай, что в систему никак не ложится.
Дебаг с friend — аналогично, мои соболезнования. Народ экономил на спичках при написании, а дальше имел проблемы.
Ну мне не такой он и кошмарный. Хотя таки бывают интересные случаи... но это уже когда они абьюзят перегрузку.
Для FFI он, я согласен, обычно лучше. Особенно если иначе надо думать об извращениях вроде транзитных пробросов исключений...
А цей задум і зараз актуальний. Завжди є ніша, де потрібне маленьке швидке і просте ядро, а вже навколо цього можна городить шелл, різні перло-пітони або виклики.
І саме тут я надаю перевагу С через його простоту. Тупо простіше розібратись, ніж у великих і жахливих плюсах. Та й швидкість компіляції теж має значення.
Ну да, половина використання Пітона це як раз такі випадки.
Нема там реально жахливого. У сенсі, що ти сам вибираєш, чим користуватись зі всього цього.
До речі, ви аналізували cpp2? Чим воно реально простіше, скажімо, за C++03?
Я дивився пару виступів від Саттера, і трохи лазив по репозиторію. Я б не сказав що він простіше за С++03, тому що в ньому залишились майже всі фічі С++ (ще й зверху трохи накинули). Якщо порівнювати з С++26 — то напевно так. Є тепер тільки 1 спосіб визначити змінну) Змінили навіть дефолтну поведінку, наприклад, все окрім локальних змінних за замовчуванням const, обов’язкова ініціалізація(неможливо мати неініціалізовану змінну). Вийшло модно, молодіжно, і дуже схоже на молоді мови типу Rust і Zig
Колись бачив виступ (чи навіть тренінг — воно день чи два йшло) Маєрса, десь в часи С++14. От він розповідав, що С++ має два типа фіч:
— для звичайних програмістів, котрі пишуть бізнес-логіку. По суті, тут мова схожа на Джаву — класи, наслідування, RAII чи смарт пойнтери.
— для писачів бібліотек. Отут темплейти та увесь жах, щоб робити ефективний движок будь-чого.
Проблема, що С++ так і не зміг відділити одне від іншого — і затягнув усе в ядро мови. Гірше, нема розділення між ядром та стандартною бібліотекою — наприклад, std::move чомусь в бібліотеці, а використовується як звичайна команда в коді. Ще гірше, що ентузіасти мови питають на співбесідах усе підряд, що робить С++ елітарним клюбом ентузіастів — бо інакше не пройдеш співбесіду.
От в результаті хтось пише ембедед на С++03 чи 11 (як високорівневу альтернативу С) щоб не вчити оте усе нове — бо стара мова реально проста й зручна, і може усе, крім корутин. Хтось юзає Джаву чи Го — бо вони простіші за останні стандарти. А справжнє активне С++ комьюніті закрите від пролетаріату страшенним бар’єром входження.
Та який там с++
Я якось поставив той Клауд код, подивитись що воно таке.
Двадцять євро, чи скільки там, за підписку заплатив.
Ну щоб протестовали як воно працює сказав йому створити веб морду на регулярні для апі на chess.com. Ну щоб в шахи в браузері грати і той апі використовувався.
Воно щось там згенерувало, воно навіть працювало.
Поліз дивитися в код, відкриваю перший компонент і бачу що фігури в шахах зроблені як свг іконки і захардкожені прям в компоненті тупо стрінгом, в одну строку. Ото прямо отой весь xml в одну строки вліпдений, навіть без форматування.
Не пережив, закрив Клауд код, відписався і більше не відкривав.
А що хіба «вєб формошлепери» до появи АІ, по іншому писали ?
без goto як заповідав великий Дейкстра
Ну іконки хоча б в свг файлах зберігали, а не хардкодили.
Тут треба просто перетерпіти) Тому AI і не є чарівною пігулкою яка фіксить всі проблеми 1 промптом. Якщо вказати на всі місця де треба покращення, а ще краще написати як покращити, то він все зробить. З С++ проблема, що коли пишеш на ньому, треба зберігати концентрацію, щоб не лишитись кінцівки. А в LLM код часто не дуже вчитуються, чого С++ може не пробачити
Ой, та можно все, тільки нахіба
Минулого тижня бавився
Була бага яка при одних кейсах репродюситься, а при інших ні.
Як роблять нормальні люди?
Відкривають дві вкладки браузера і крок за кроком дебажать той шматок коду шукаючи різницю. Роботи десь на годину там
Що зробив я?
Ну в мене ж копайлот, моделі там усяки, чатгепете, кладсонет та ще якась барахло. Ну отже нафіг дебаг, зараз напишу гарненький промпт, детально опишу проблему і через пару хвилин отримаю фікс і юні тести бонусом.
Ну того.. години чотири я спілкувався з різними агентами, вони там щось фіксили, тестили, я уточнював, врешті решт якось то все пофіксили, я викинув купу непотрібного коду з фіксу і якось наче нічого вийшло.
Ну хз, з одного боку ви вірно кажете, з іншого С++ вірно але поступово видавлюють.
Мої спостереженея за останні роки.
Гєймдєв — так, але ААА рівня та енжайни типу UE.
Увесь міддл левел — там давно юніті і ні якого С++.
Блокчейн/кріпта — Тут раст давно С++ випер.
HFT — С++ досі намбер ван, але дивлюся статиі на лінкедін — Раст потроху і туди залазить.
Linux kernel — C, а тепер ще і Раст, ніякого С++.
Це мої спрстереження.
І незрозуміле ситуація щодо AI.
От моє питанея автору — наскільки AI промптінг зараз замінює кодінг в HFT ?
З Linux ситуація цікава. Якби не персональна нелюбов Лінуса до С++, і якби був лобіст з грошима, то я думаю C++ потрапив би в ядро в обрізаному вигляді. Особливо, якби це пушили вже після виходу С++11. Чого тільки вартий RAII, який би дозволив викинути мільярд goto done;. Але тепер маємо Rust, до якого Лінус, на відміну від С++, поставився куди прихильніше. Можливо з віком він став відкритішим до нового)
Щодо AI: На мою думку, AI prompting в найближчому майбутньому (а можливо і ніколи) не замінить software engineering. Кодінг — можливо. HFT — це висококонкурентна сфера, де кодингу майже немає, а є software engineering. В той самий час, AI дозволяє збільшити продуктивність інженера. Причому, на мою думку, підвищення продуктивності залежить більше від самого програміста, ніж від сфери. Тому компанії, які його не використовують, стають менш конкурентоздатними
Windows?
Не дозволив би, бо все ще треба якось розділяти kmalloc, vmalloc, GFP_KERNEL, GFP_NOWAIT,... і слідкувати за контекстом виділення тих об’єктів.
З іншого боку, для більшості задач зараз і так використовують devm_kzalloc(), який видаляє за собою об’єкти при вивантаженні модуля ядра.
Чому не вийде? Наприклад, в std::unique_ptr можна передати будь-який deleter
Писати окремий унікальний deleter щоразу коли раптом потрібно алокувати об’єкт в інтерапті чи тасклеті буде явно менш зручно, ніж вручну викликати kfree(). Для некритичного і живучого в тредах є devm_kzalloc().
а нашо писати унікальний делетер?
с++ достатньо гнучкий шоб написати доволі універсальний делетер.
Я б тут посперечався, бо, як вже було сказано, легко зробити універсальний deleter просто створивши alias на тип. По-друге, все, що треба робити вручну легко провтикати. По-третє, в ядро по-факту вже додали такий механізм в 6.5: docs.kernel.org/core-api/cleanup.html
Весь Лінукс збирається за 5 хвилин — завдяки тому, що це С, з простим синтаксисом, і без темплейтів.
А ще там кілька варіантів виділення пам’яті — залежно її призначення. В С++ воно самі знаєте як виглядало б. Себто, коли робота з залізом — то не має бути жодної магії, бо в залізі своєї магії повно. І ці магії пересваряться.
З часом збірки я абсолютно згоден. Якщо переборщити, то навіть проект на якихось пару тисяч рядків може збиратись хвилину або декілька, бо metaprogramming constexpr частина в C++ вже тягне на окрему мову. Єдине що, хоч я з ядром майже не працював, я не уявляю навіщо треба ребілдити все ядро часто. Зазвичай активна робота іде над парою(максимум десятків) файлів, які відносно швидко перезбираються
Наприклад, мені доводилося збирати прошивку Wi-Fi роутера, коли з ними працював — воно підтягало поточну вебку, і мою телефонію з локального проекту. Тоді віддаєш тестувальнику й бачиш, чи пофіксилися баги. Весь роутер ноутом збирався за пів-години, здається. А реюзати вчорашній кеш з сьогоднішньою вебкою — стріляти в ноги, бо хто зна що там де в системі змінилося.
functional safety standard, чи як його там, вимагає робити зборку всіх артефактів «з нуля»
В нас не було.
Щі існує ccache / distcc, але колись народ намагався їх завести, не зафіксував якогось профіту, а потім ще пару тижнів вичищав з ноута, доки він знову почав нормально збирати).
Ну це коли ти вже на СІ ганяєш. А локально ти можеш ітеративно збирати
А що це і в чому різниця?
Це я зайшов трохи в філософію. Під кодингом, я мав на увазі ситуацію, коли була задача, але її хтось уточнив, декомпозував, придумав що конкретно і як робити, і тобі лишається тільки це запрограмувати. Такий клас задач LLM вирішує дуже добре. Під software engineering я мав на увазі ситуацію, коли у тебе є тільки високорівнева задача, і тобі весь шлях виконання треба проробити самому
В kernel завезли Rust здебільшого заради нової крові в коммьюніті. Універи сьогодні забили на курси С/С++ і системному програмування вчать за Rust або Go, бо C не секьюрно! Корпораціям стало важче шукати джунів та мідлів, що б колупали їх кернел модулі, бо сьогоднішні студенти бояться вкладати свій час в мови, які госдеп визнав легасі і не радив на них писати. Ветерани Linux теж старіють або вигорають, тому додавання в кернел хайпової мови не така вже й погана ідея. Я не вірю, що Rust в kernel це якась silver bullet, там всеодно без unsafe мало що напишеш.
а «іноземні спеціалісти» © (тм)
«дєнєг нєт, но вы дєржітєсь» ©(тм)
Виглядає так, що після включення Profiles до стандарту, C++ отримає змогу надавати найсильніші Safety гарантії часу компіляції ніж будь-яка інша мова програмування.
Крім того, проблеми Зворотної сумісності та Технічного боргу властиві не лише C++, а будь-якій мові програмування масового використання.
яка самовпевненість 😂
і ви кажіть ©
То хіба є щось погане у звертанні на ви?
не обнадіюйся, це сталий вираз, але в тебе досі пригорає, точно на якій держслужбі все життя бомків лапав
В чому радість московито-подібного свино-собачого поводження — не зрозуміло.
То анекдот.
Приходить дід до лікаря й жаліється:
— В мене сусід 90 років, і він каже, що щоночі вони з дружиною годину сексом займаються. А мені 85, і вже лише раз на тиждень можу.
— То й ви кажіть!
По-перше, Profiles вже не потрапили в С++26 (вже був feature freeze). Звісно, частину гарантій безпеки вже можна використовувати зараз, типу bounds-check (libcxx.llvm.org/Hardening.html). Але це вже давно є в інших популярних мовах, які не пріоритизували zero-cost abstractions. Також, я б не сказав, що Profiles роблять С++ безпечнішим за той же Rust. Також, планується, що profiles треба буде вручну вмикати, а це набагато небезпечніше ніж ручне вимикання (unsafe) в Rust. І це я ще не згадував «екзотичні» мови які зроблені навколо ідеї безпечності.
Щодо оберненої сумісності, тут теж не погоджусь. Чого вартий тільки Python 2 -> 3. Тут ще можна згадати Swift. Велика корпорація може вирішити зламати обернену сумісність, і у людей немає іншого вибору, як переписувати/перезбирати код.
загалом так, але по версіям ще ні, бо існує вже декіілька С++: 98, 03, 11, 14, 17 так сказати «легаці», а от починаючи з С++20 хз який компілєр що пітримує під яке HW
С++20 — це новий С++17, зараз багато хто його використовує як стабільну версію. Підтримку стандартів компіляторами можна подивитись тут: en.cppreference.com/cpp/compiler_support. Загалом С++20 підтримується майже повністю, окрім, можливо, стабільної роботи модулів. С++23 вже фактично теж повнстію підтримується. Навіть деякі фічі С++26 вже підтримуються в gcc/clang. Проблем з підтримкою HW теж немає
Мене «поперли» з С++ як раз коли миирочали на С++20 переходити.
В цьому році, в вільний час, дочитав книгу на С++ щоб рівень коптетентості підтримувати.
а це, модулі з версіюванням (як в го, ноді, расті і т.д.) в 26 вже примотали, чи все автомейком з автотулом без них?
який може с++rgo де?
Не знаю хто зараз використовує автомейк. Щодо пакетного менеджера — його немає в стандарті, і це, напевно добре. З популярних зараз — це conan і vcpkg. Депенденсі можна менеджити і мануально в Cmake відносно легко (наскільки слово лекго застосовано до cmake). А от з модулями наче дійсно ще проблема, але я давно не перевіряв. У будь-якому випадку всі основні бібліотеки досі на хедерах
Він переживе, але навряд чи вилізе з занепаду. Мови не вмирають — нещодавно бачив вакансію на Дельфі.
Мова вмирає разом із останнім її носієм. (в граніт би це)
P.S.
За даними ЮНЕСКО, кожні два тижні разом з останнім носієм помирає одна мова
З делфі ситуація інша. Як я розумію він був більше до застосунків, які можна легко переписати, бо вони стоять в кінці ланцюга залежносей. А ось С++ знаходиться десь на початку і всередині ланцюга. Щоб викинути С++ треба переписати не тільки сам цей софт на С++, а ще й весь софт який використовує його, а це вже далеко не просто
Наразі пішла хвиля автопереписування усього на Раст. Навряд чи має сенс міняти С++ на Раст, але в принципі, якщо воно всередині ланцюжка — то там, імовірно, інтерфейс через extern C, або навіть stdio чи сокети. В останньому разі взагалі не проблема змінити мову.
А так, щоб ліба експозила лише С++ інтерфейс — то хто ж її юзатиме окрім С++? І тоді усе це кубло замінять заразом.
Але на практиці не замінять, а просто хтось напише альтернативу, і з часом на неї переїдуть користувачі — бо альтернатива розвиватиметься швидше за оригінал. Приклади — ОпенОфіс та ЛібреОфіс, чи Екліпс та ВсКод.
а можно узнать, на основании каких объективных данных вы текущее состояние языка описываете как «занепад»?
а вообще нужно знать историю. то, в какой дупе были плюсы в первой половине нулевых, сегодня трудно себе представить. Microsoft сказала, что API новой версии Windows уже будет только на .NET и в тот момент это казалось последним гвоздем в крышку гроба.
но внезапно оказалось, что частоты CPU уперлись в потолок, закон Мура оказался про рост в ширину, а не высоту и покойника пришлось откапывать...
вспомнил я все это не случайно, а потому, что мы сейчас в разгаре неслыханного кризиса микроэлектроники. беспрецедентно жесткого, в сравнении с которым кризис майнинга вызывает только улыбку. и совсем не похоже, что кризис этот завтра сойдет на нет (даже если пузырь AI лопнет). а в эпоху, когда каждый мегабайт снова на счету, уверен, плюсы себя будут чувствовать более чем комфортно.
Чому це будуть плюси, а не Rust? Схоже для вайб-переписувань існуючих проектів з інших мов він вже більш популярний.
у Rust есть своя ниша, растет он быстрее плюсов и в эпоху борьбы за выжимание всех соков из железа у него такие же хорошие шансы, как и у плюсов.
но это не значит, что он выйдет победителем завтра. у Саттера по этому поводу было очень хорошее выступление. там, помимо всего прочего, оценивался общий рост программистов в мире. так вот, за последний год значение прироста C++ программистов больше, чем всего Rust программистов сегодня в мире: C++ added as many devs in 1 year than total Rust devs.
becpp.org/...ition, safety, and AI.pdf
ШІ ж «сокращає», який ще прирост жиров в маслах?
исключительно для инвесторов )
Ну ось графік — плюси на7-8 місці.
github.blog/...programming-languages.png
А в 90х вони були єдиним варіантом для написання великих систем. Це вже потім прийшла Джава, і плюси з цієї ніші викинули. Потім прийшли Го, і частково видавили з хайлоаду. Зараз ще Раст видавлює фінтеху. І Пітон — з наукових обчислень.
— график показывает не упадок, график показывает стабильность90-ми нужен график гитхаба за 90-е )
— github имеет свою специфику, эти данные нельзя экстраполировать на всю индустрию
— чтобы сравнивать с
отріцатєльний рост
Стабільно пасе задніх десь між Шеллом та HCL
а только я вижу, что одну позицию язык проигрывал, а потом отыгрывал?
т.е. одна позиция на таком графике мало чего показывает, это уровень погрешности.
Гаразд. «Стабільно після PHP».
TS растет, JS падает. с этим по этому графику я могу согласится.
«PHP дуже популярний та сучасний, С++ трохи менш популярний»
Був чат в Телеграмі «C, C++, Rust» але мене в ньому забанили коли почав приколюватися з адміна.