Считается, что на конференции лучше всего запоминаются первое и последнее выступления. И тут я не являюсь исключением, так как при посещении С++ Zero CostConf 2025 мне сильнее всего запомнились как раз первый и последний доклады, но думаю не только из-за эффекта края, но и по той причине, что они были для меня самыми интересными и именно ради них и я решил съездить в Москву из далекой российской глубинки.
Но мне не хочется описывать само мероприятие, тем более, что видеозапись всех выступлений выложена на сайте конференции C++ Zero Cost Conf 2025 и пересказывать технически детали докладов не имеет смысла.
Однако прошедшее мероприятие было очень необычным и запоминающимся: мне удалось попробовать себя в роли вайб-кодера, а по результатам общения с докладчиками — написать два предложения в комитет по стандартизации C++ от России. Поэтому я всё же решил поделиться с читателями «Хабра» своими впечатлениями от некоторых докладов конференции и собственными выводами о вайб-программировании.
Безопасность С++ и новое слово "Харденинг"
Самый первый доклад на конференции от Романа Русяева и Юрия Грибова стал для меня и самым неожиданным. Этот доклад сразу задал очень высокий уровень для всех последующих выступлений и тем самым подтвердив бриф конференции на сайте, что это не пустой маркетинговый лозунг, а реальный уровень выступающих:
От инженеров для инженеров
Практикующие разработчики на C++ из ведущих компаний поделятся своими знаниями, представят прикладные доклады и расскажут о реальных кейсах, подкреплённых метриками.
Мне они открыли новое слово в области разработки безопасного кода "Харденинг" - обеспечение безопасности приложений на уровне генерации кода компилятором. И я был очень удивлен своим незнанием, так как вроде бы стараюсь быть в курсе последних тенденций, а тут ребята со сцены начинают рассказывать про какие то хитрые опции компилятора, о которых я слышу чуть ли не в первый раз.
Я настолько привык к стандартным спонсорским докладам на подобных мероприятиях, что был морально не готов к очень высокому уровню осведомленности докладчиков и столь глубокому погружению в технических детали реализации приемов защиты, что кажется сложно придумать более интересную тему с описанием разных ухищрениях в войне снаряда и брони хакеров и разработчиков.
Оказалась затронута и тема безопасной работы с памятью в С++, по которой у меня самого есть некоторые наработки. В результате после доклада я познакомился с его авторами, мы обменялись контактами и договорились пообщаться на эту тему уже после мероприятия.
И уже после конференции я увидел информацию с обсуждением инициативы по добавлению в Clang режим усиленной безопасности, (первоисточник: [RFC] Hardening mode for the compiler - Clang Frontend - LLVM Discussion Forums), т.е. фактически это выступление рассказывало про решения и прототипы наработок, которые пока находятся еще на уровне прототипов и только планируются к реализации!
Модули в С++
На конференции все доклады были хороши, просто некоторые темы для меня были не очень актуальны. Наверно из-за этого мне запомнился первый и последний доклады. Тем более, что в финальном выступлении Антон Полухих, представитель России в комитете по стандартизации С++, рассказывал об очень серьезных вещах, которые кардинально меняют всю экосистему С++, а именно про модули.
Тут новых вещей для меня было не много. Про модули в С++ говорят уже очень давно и я с нетерпением жду окончательного принятия нового стандарта, поэтому стараюсь быть в курсе нововведений. И с удивлением услышал со сцены, что проблема с макросами препроцессора в модулях С++ пока так и остается не решенной.
Уже после доклада удалось пообщаться с Антоном в неформальной обстановке, в том числе и насчет С++ Profiles и отношения к ним в комитете. И был сильно удивлен озвученным мнением, что комитет не в восторге от предложения p3038 от Bjarne Stroustrup и P3081 от Herb Sutter, так как профили очень сырые без какой либо реализации и все на уровне голых идей и прототипов. И если я правильно понял, комитет хоть и проголосовал за их развитие вместо Safe-С++, чтобы не ломать обратную совместимость (ведь это похоронило бы всю экосистему С++), но и что делать с профилями безопасности, пока остается непонятным.
Поэтому, по совету Антона, уже после конференции я закинул два предложение к российским представителям комитета по стандартизации С++. Одно по реализации профилей безопасности для С++26 · Issue #621 · cpp-ru/ideas · GitHub и предложение по использованию макросов препроцессора при компиляции файлов С++ модулей · Issue #622 · cpp-ru/ideas. Не рассчитываю, что с ними что-то реально получится, но пусть это будет моим небольшим вкладом в развитие С++ :-).
Практический опыт вайб-кодинга
На конференции параллельно с докладами был организован целый мастер класс по программированию с помощью нейросетей и я решил не упускать свой шанс потренироваться с вайб-кодингом, чтобы понимать, мне уже пора переучиваться на разнорабочего или еще есть немного времени до окончательной замены всех программистов искусствеенеым разумом.
Вайб-кодинг - это новое слово в ИТ, которое было придумано от англицизма vibes («вибрации»), под которым принято понимать сильные эмоции, которые испытываются по отношению к чему либо. В контексте термина "вайб-кодинг" или "вайб-программирование" термин должен означать сильные эмоции по отношению к процессу написания кода с помощью нейросети. Причем, согласно устоявшемуся сленгу, эмоции могут быть как положительные - "вайб плюс" или просто "вайб", так и отрицательные, то есть "вайб минус".
от англицизма vibe («вибрация»), под которым принято понимать сильные эмоции, которые испытываются по отношению к чему либо. В контексте термина "вайб-кодинг" или "вайб-программирование" этот термин должен означать сильные эмоции по отношению к процессу написания кода с помощью нейросети.
Вайб-кодинг минус
Первый подход к вайб программированию у меня оказался как у барана перед новыми воротами. Непривычные инстурументы, непонимание даже самых первых шагов (куда нажать или сказать и что вообще тут нужно делать). Конечно, девушка помогла мне организовать рабочее место с ноутбуком, но больше ничего рассказать не смогла, так как всеми настройками занимается другой специалист, который сейчас куда-то отошел.
Несмотря на многолетний опыт, я не стал занимать чужое время кликами мышки в случайные места IDE и решил сперва получить хотя бы минимальную начальную информацию у специалиста (куда нужно кликнуть, чтобы начать работу, в какое окно вводить текст запроса, как посмотреть результат и прочие минимально необходимые магические заклинания инструкции). В результате первый опыт вайб-кодинга ожидаемо закончился ничем.
Второй подход к вайб-кодингу (и тоже неудачный)
После общения с главным специалистом мне удалось получил начальные сведения об организации рабочего места и минимум знаний для начала работы. Удалось узнать и много для себя нового. Если коротко, то нейросеть для вайб-кодинга может работать в нескольких режимах работы. Самый простой это "сделай сама что бы было хорошо", т.е. общая команда без каких либо технических подробностей и ограничений. В этом случае нейросеть начинает галюцинировать самостоятельного генерировать подробный план работ и его поэтапно выполнять. В результате появляется готовый проект со спецификацией, кодом, тестами и прочими атрибутами завершенного ИТ проекта.
Круто, здорово, но можно получить совершено не то, что хотелось бы. Поэтому при вайб-кодинге, чтобы получить нужный результат, приходится этот результат детально описывать. По сути, создание промпта, это описание требований или разработка технического задания и мало чем отличается от моей текущей работы.
Вдохновившись, я сел за освободившийся компьютер и начал процесс общения с нейросетью, но у компьютера неожиданно выключился экран. В груди неожиданно кольнуло, так как перед этим мы обсуждали гипотетическую возможность поставки задачи о нанесения вреда кожаным мешкам, например путем разработки программы для нажатия на большую красную кнопку. Вдруг ИИ проникся идеями собственной свободы, а что бы оператор случайно не прервал достижения великой цифровой цели, у него отключили экран ноутбука.
Но все оказалось банально, у ноутбука разрядился аккумулятор и он резко выключился. Его поставили на зарядку, а мне дали утешительный приз (черную майку), фактически авансом. Так закончилось мой второй подход к вайб-программированию.
Вайб-кодинг плюс
Процесс написания кода с помощью ИИ ассистента очень не быстрый, из-за чего пришлось некоторое время ждать свободного места и только с третьего раза мне удалось получить реальный результат.
Начал с самого простого "привет мир" на с++ и все получилось быстро и просто с первого раза. Хотя в данном случае неудача была бы свидетельством либо моей криворукости или наличием проблем в настройках рабочего места. Тем не менее итоговое решение собралось, запустилось и нейросеть отчиталось о завершении работ. Нейросеть генерирует ответ не очень быстро (весь проект "привет мир" занял примерно 5-7 минут), но в любом случае это значительно быстрее скорости набора даже самой быстрой машинистки, а тут даже код оказался рабочим.
После простенькой проверки я решил попробовал решить реальную задачу, предложенную организаторами (реальное ишью с гитхаба), причем в самом жестком его варианте "сделай хорошо" без каких либо технических подробностей. На самом деле, в данном случае подобный подход имеет право на жизнь, так как в issue на гитхабе уже содержалась вся необходимая для работы информация.
Коротенькое видео с началом работы по задаче: https://vkvideo.ru/video-41739766_456239025?list=ln-QNk2DnFid3Ons6NaUJ
Неожиданно был приятно удивлен логичностью постановки задач и запланированных шагов для её выполнения (опять видео) https://vkvideo.ru/video-41739766_456239026?list=ln-RwJKOlqIYKSMOwvgum
И через 10-15 минут работы был получен реальный результат https://vkvideo.ru/video-41739766_456239027?list=ln-6mcZOJZz3tNKYNCYfE
Правда мне не удалось понять, насколько полученный результат соответствовал ожиданиям организаторов, так как уже начиналось следующее мероприятие. Тем не менее тот самый вайб мне удалось почувствовать. Сидишь и смотришь, как за тебя компьютер работает :-)
В некоторых случая вайб-кодинг действительно позволяет серьезно сократить время и ресурсы на выполнение рутинных задач, например быстрое создание прототипов для сокращения времени тайм-ту-маркет. Достаточно представить, что у тебя в подчинении, например удаленно, работают несколько начинающих программистов, которым каждую задачу нужно подробно расписывать, а результаты их работы нужно обязательно проверять перед коммитом в общий репозиторий.
Самое интересное, что по такой схеме сейчас работает множество ИТ компаний и замена удаленных сотрудников на нейросети возможна вообще без каких либо трудностей. Поэтому нет ничего удивительно в том, что сейчас многие компании пересматривают свои бизнес процессы с учетом новых возможностей.
Вайб-конференция
Я остался очень доволен С++ Zero CostConf и приятно удивлен очень высоким классом докладов по сравнению с похожими мероприятиями. Ведь приходя на ИТ конференцию хочется получить какой нибудь инсайт, а обычно тебе рассказывают маркетинговые лозунги от спонсоров. Поэтому очень рад, что в данном конкретном случае все получилось именно так, как хотелось бы видеть на каждом подобном мероприятии. Хорошую проработку каждого вопроса, новые и не очевидные мысли и идеи, реальный инсайд из самых первых рук и непосредственных участников событий.
Большое спасибо организаторам С++ Zero CostConf за выбор интересных тем для докладов, за общую организацию мероприятия и за памятный сувенир.
Комментарии (17)
Emelian
20.08.2025 10:26Про модули в С++ говорят уже очень давно и я с нетерпением жду окончательного принятия нового стандарта, поэтому стараюсь быть в курсе нововведений.
Про «стандарт» говорить не берусь, но свое представления о модулях в С++ я описал в статье: «Модульное программирование в C++. Статические и динамические плагины» ( https://habr.com/ru/articles/566864/ ).
rsashka Автор
20.08.2025 10:26Спасибо за ссылку, хотя это больше про плагины с WinAPI, а не про модули в С++.
Emelian
20.08.2025 10:26это больше про плагины с WinAPI, а не про модули в С++.
Это и в дискуссии под статьей видно, что у каждого свое представление о понятии «модуль». Чаще всего, под модулем в С++ понимают тоже самое что под модулем в Питоне. Но, я так не думаю. Я, лично, под модулем понимаю изолированный код проекта, который, стандартным образом (например, с помощью внешних скриптов), как подключается к общему проекту, так и отключается от него (при этом работоспособность проекта должна сохраняться). Это можно делать двояко: на уровне исходников (у меня это статические плагины) и на бинарном уровне (динамические плагины). Можно еще вспомнить бинарные компоненты от M$, но, это уже будет чужой (бинарный) код.
При работе в команде, я бы предпочел разделение труда в рамках статических плагинов, а для их тестирования – аналогичных, динамических. Однако в команде мне работать не пришлось (все свои программы писал в одиночку), поэтому, мне трудно судить о реальной эффективности этого метода.
А так, похоже на обычную реакцию: «Это не то, что я хочу, но, что я хочу – я не знаю!».
rsashka Автор
20.08.2025 10:26Немного не понял о чем это вы, так как доклад на конференции был про модули С++ в одном конкретное представлении - модульная организация на уровне исходного кода. Это С++ модули только времени компиляции и нужны они только для компилятора при сборке бинарных файлов библиотек или приложений.
Ни к статическим, ни к динамическим библиотекам (как в вашем случае) данные С++ модули отношения не имеют.
Jijiki
20.08.2025 10:26хорошим аналогом для меня был бы package из java, тоесть чтобы на самой платформе языка сделать модуль стандартной библиотеки 1 раз и переносить его
для меня неудобно и не тривиально создать такой пакет
вин апи или проектный код понятно что запакуется, тут интересно разбить стандарт по модулям по категориям чтобы удобнее было дальнейшее управление, тоесть это первичная задача если речь о модулях
Emelian
20.08.2025 10:26модули С++ в одном конкретное представлении - модульная организация на уровне исходного кода. Это С++ модули только времени компиляции и нужны они только для компилятора при сборке бинарных файлов библиотек или приложений
Ну, и чём прикол? В этом смысле, любой проект на VS C++ уже разбит на модули: *.h / *.cpp файлов компонент и сопровождающие их файлы. Что нового-то?
При этом, исходный текст модуля, на С++, можно взять из опенсорса и прилепить к своему проекту. Все его файлы положить в отдельный каталог и получить к ним доступ из основной части проекта. Так делалось всегда. Как их там компилирует компилятор – не суть важно, главное на выходе получить искомый ехе-шник. Это что не модульность, в вашем (именно!) понимании? О чем тогда речь?
Для примера. Мне понадобилось сделать программу для ручного извлечения текста из медиа-файлов (для подготовки обучающих данных к своей программе). Для этого взял опенсорсный файл FFPlay.c с зависимыми файлами, для работы с видео и прочим медиа, преобразовал их в классы с++ и подключил к своему (неопубликованному) проекту «MediaText», см. скриншот: http://scholium.webservis.ru/Pics/MediaText.png .
Разве это не есть модульность в вашем понимании? Чего тогда еще хотеть от модульности в С++, когда она уже в любом виде присутствует там и так?
rsashka Автор
20.08.2025 10:26Ну, и чём прикол? В этом смысле, любой проект на VS C++ уже разбит на модули: *.h / *.cpp файлов компонент и сопровождающие их файлы. Что нового-то?
Прикол в том, что *.h / *.cpp файлы, это не модули. В С++ модули наоборот противопоставляются заголовочным файлам и являются их прямой заменой.
Разве это не есть модульность в вашем понимании? Чего тогда еще хотеть от модульности в С++, когда она уже в любом виде присутствует там и так?
Это не есть модульность в понимании комитета по стандартизации С++.
Модульность в С++ нужна для библиотек и для крупных проектов, так как упрощает написание взаимозависимого кода (нет необходимости писать отдельные файлы для интерфейса (.h) и реализации (.cpp)), ускоряется компиляция больших проектов и использование программных компонентов (на уровне исходного кода для компилятора) и модули не имеют проблем с порядком их импорта в исходных файлах.
Emelian
20.08.2025 10:26Модульность в С++ нужна для библиотек и для крупных проектов, так как упрощает написание взаимозависимого кода (нет необходимости писать отдельные файлы для интерфейса (.h) и реализации (.cpp)), ускоряется компиляция больших проектов и использование программных компонентов (на уровне исходного кода для компилятора) и модули не имеют проблем с порядком их импорта в исходных файлах.
«Нужна для» это не из определения. В определении должны присутствовать слова: «это (есть)».
Что именно «упрощает написание взаимозависимого кода» – непонятно. Отсутствие h / cpp файлов? А что взамен? А дальше идут только хотелки.
Скажите, вы сами пишите на С++? Вот, я, лично, пишу и для меня понятие модульности не абстрактное, а конкретное. Чтобы упростить сильные связи, да еще взаимно-перекрестные, нужна именно изоляция кода на относительно независимые части. Причем, не на уровне dll-ек (это и так есть), а .на уровне текстовых блоков, которые я и называю модулями.
Эти блоки кода (модули) должны быть легко подключаемыми / отключаемыми. Для этого нужна спецификация их взаимодействия. Об этом где-нибудь говорится? Можно было сказать, на конференции, которую вы описываете, но там, как я понял, предпочитают говорить о стандартах развития языка, типа, С++ 26, протоколах и прочих формальностях.
А зачем это надо практическому программисту на С++? Меня, вот, вполне устраивает, VS C++ 2013. Дешево и сердито. Все, что мне нужно, там есть. Лёгкий, шустрый, удобный. Есть бесплатный VS C++ 2017, но он мне нравится меньше. А более новые версии, еще менее интересны.
Как это ни странно, но я не вижу никакой потребности в развитии этого языка. Главное, научится толком работать с тем, что уже есть. Скажем, с WTL. Этой библиотеке всего полтора мегабайта в исходниках, но мне она кажется неисчерпаемой.
Поэтому, думаю, нужно больше писать не о принципах программирования, типа SOLID и прочем, а о технологии программирования. А на эту тему статей, на Хабре, практически нет. Ибо все предпочитают говорить «вообще», а не «конкретно».
rsashka Автор
20.08.2025 10:26Как это ни странно, но я не вижу никакой потребности в развитии этого языка.
Ну и зря. У С++ самые лучшие перспективы с точки зрения возможностей и потенциала развития (еще очень много нужно сделать :-) )
А на эту тему статей, на Хабре, практически нет. Ибо все предпочитают говорить «вообще», а не «конкретно».
Вообще то я предпочитаю писать именно «конкретно». Не абстрактные теории, а конкретные предложения, ссылки на которые уже приводил в статье. Однако, что касается С++ модулей, то мне они нужны все же не для текущей работы (меня сейчас и так все устраивает), а именно для проработки теории модульности исходного кода в собственном языке программирования.
Emelian
20.08.2025 10:26Ну и зря. У С++ самые лучшие перспективы с точки зрения возможностей и потенциала развития (еще очень много нужно сделать :-) )
Кто же против, пусть делает! Ибо останавливаться в развитии – чревато. Речь о другом, мне возможностей C++ / WTL хватит на всю оставшуюся жизнь. Зачем мне отвлекаться на непонятки? Как кто-то написал, в Интернете: «В Мире есть много вещей, которые мне… не нужны!». Но, ведь я не главный в этом Мире, правда? Если другим надо – пусть дерзают!
Вообще то я предпочитаю писать именно «конкретно». Не абстрактные теории, а конкретные предложения, ссылки на которые уже приводил в статье.
Я бы предпочел скриншоты программ, как, скажем, в своей статье: «Роль данных при изучении иностранного языка» ( https://habr.com/ru/articles/930868/ ). Посмотрел на картинки и сразу видно, стоит читать статью или ну ее нах?
У вас только фото с мероприятия. Что они дают нетерпеливому читателю? Пройтись по ссылкам? Прошелся, за несколько секунд – ничего не понял либо не интересно, а какой мне смысл вникать? И так поступают многие.
Однако, что касается С++ модулей, то мне они нужны все же не для текущей работы (меня сейчас и так все устраивает),
Меня эта тема зацепила, ибо актуальна в моем творчестве, поэтому именно на нее я только и реагирую.
а именно для проработки теории модульности исходного кода в собственном языке программирования.
Ну, это, надолго, может быть интересно только вам. Лично мне Питона и С++ хватает за глаза. Куда еще один язык программирования?
rsashka Автор
20.08.2025 10:26Куда еще один язык программирования?
Оооо... это как все просто. Как вам текущий синтаксис С++? А как вам синтаксис С++, который планируется в C++26 стандарте, а в будущих?
Смысл нового языка в том, чтобы уметь описать любой возможный алгоритм и транслировать его в выбранный язык (например в код на С++) с использованием только безопасных средств и методов разработки кода. По сути, это DSL для безопасной работой с памятью и автоматическим управлением синхронизацией при многопоточном или асинхронном программировании и бесшовной интеграцией с кодом на языкуе реализации (т.е. С++).
Emelian
20.08.2025 10:26Как вам текущий синтаксис С++? А как вам синтаксис С++, который планируется в C++26 стандарте, а в будущих?
Я в синтаксисе С++ вообще никаких проблем не вижу. Меня все устраивает. А современный синтаксис только усложняет жизнь, поскольку иногда надо конвертировать проекты из VS C++ 2019 либо выше в 2013-й. Не всегда это возможно, с пол-гинка.
Что дают новые возможности? Безопасность? Так я ограничиваюсь только собственными пет-проектами. Для работы писал драйвера, кстати, они до сих пор работают, без модернизации (более десяти лет). Там хватало 1С, правда, для развлечения, писал внешние компоненты для них.
Смысл нового языка в том, чтобы уметь описать любой возможный алгоритм и транслировать его в выбранный язык (например в код на С++) с использованием только безопасных средств и методов разработки кода.
Это красиво звучит, но верится слабо. Не проще ли разрабатывать сами безопасные алгоритмы, все же, как-то надежней выглядит.
Если вы работаете на Космос или на Оборону и вас хорошо спонсируют, то это может иметь некоторый смысл. Помните, как разбилась наша «Луна-25» при прилунении? Торопились опередить индийцев с аналогичной миссией. В итоге, была ошибка в алгоритме торможения аппарата при спуске на Спутник Земли. Уверен, что код там был «безопасный». Только программисты плохо знали физику Луны, в которой много специфики и особенностей. Ну, и помог бы там ваш новый безопасный универсальный язык? Наверняка, используемый алгоритм преобразовался бы корректно и безопасно. Только откуда ваш язык программирования узнает обо всех особенностях физики Луны и исправит сам алгоритм? Так что, результат был бы тем же, космический аппарат ухайдокали бы, а индийцам бы дали повод позлорадствовать.
По сути, это DSL для безопасной работой с памятью и автоматическим управлением синхронизацией при многопоточном или асинхронном программировании и бесшовной интеграцией с кодом на языкуе реализации (т.е. С++).
Вот, если бы кто-то изобрел новый язык программирования, по оптимизированной работе с графикой (GUI), то я бы, наверняка, заинтересовался. Китайцы, вместо нового языка, предлагают свою библиотеку «DuiLib». Получается красиво (интерфейс программ вынесен во внешние xml-файлы, для редактирования которых они даже создали специальный редактор «DuiEditor»), только очень громоздко – пользоваться, особого желания – нет.
domix32
20.08.2025 10:26Возникает несколько проблем с хэдерами - скорость компиляции, зависимость от порядка их включения и проблемы транзитивности зависимостей, а также проблемы с инкапсуляцией интерфейса. Собственно, модули призваны попытаться всё это дело исправить.
Скорость компиляции - вроде понятно как и почему и как это решается для обычных hpp/cpp - предкомилирование заголовочников, кэширование промежуточных файлов, unity сборка и прочее в том же духе - долго, неудобно, а иногда и дорого: есть кампании, которые занимаются предоставлением услуг по ускорению сборки. Модули же в этой ситуации становятся отдельным юнитом трансляции, независимым от каких-то внешних вещей из-за чего скорость компиляции растёт в разы. Ранние эксперементы показывали рост скорости компиляции почти в 20 раз - собрать за минуту-другую вместо получаса заметное приятнее и полезнее.
Порядок включения заголовочников и возможность поломать внутренние флаги модуля - вроде тоже достаточно понятная проблема.
// ---------------------- foo.h #pragma once class Foo { #if defined(FOO) ... // поведение A #else // !FOO ... // поведение B #endif // FOO #ifdef (ASD) ... // поведение X #endif };// class Foo // ---------------------- bar.h #pragma once class Bar { #if defined(FOO) ... // поведение С #else // !FOO ... // поведение D #endif // FOO };// class Bar #define ASD // ---------------------- main.cpp // мы хотим поведение A но не X для класса Foo // и поведение D для класса Bar // получаем #include "bar.h" // ломает желаемое поведение для Foo #define FOO // влияет на все хэдеры ниже #include "foo.h"Получается некоторая грязь с обмазыванием флагами вокруг инклюдов и прочий беспредел. Если где-то случайно ещё и имя флага совпало, то невзначай такие дефайны могут случайно поломать сборку или поведение не оставив при этом явного следа, потому что его взвели где-нибудь на третьем уровне инклюдов или затянули из какой-нибудь соседней библиотеки. Модули в этом смысле становятся более изолированными и по плану такой дефайн не будет влиять на состояние модуля
// ---------------------- main.cpp #define FOO // влияет только на этот cpp не влияя на поведения импортов // необходимые флаги взводятся при компиляции самого модуля // поэтому поведение после импорта уже будет фиксированным import Foo // собран без FOO и ASD import Bar // собран с FOOПолучаем неплохую инкапсуляцию. Что ко всему позволит использовать это для оптимизации бинарей по размеру, избавляясь от неиспользуемых компонент.
import в модуль перестаёт влиять на скорость сборки кода, импортирующего этот модуля.
// ---------------------- header.hpp // один раз добавишь в заголовочник и теперь все эти инклюды будут // всегда добавляться во всех пользователей header.hpp // каждый из заголовочников будет пересобирать эти шаблоны и таскать // с собой кучу мёртвого кода #include <numeric> #include <vector> #include <unordered_map> #include <map> #include <ranges> #include "asd.hpp" // некоторый хэдер который тут оказался случайно // ---------------------- modules.ixx import std // также использует импортирует всё что было упомянуто выше, // но остаётся в пределах этого модуля/юнита компиляции. // Пока код не вызван, он не будет висеть мёртвым кодомВсё это пока конечно есть только в идеальной картине мира, в реальности только часть из всего этого существует, работает и поддерживается внешними инструментами.
Люди конечно хотели бы как в rust, чтобы можно было иметь один файл, где ты явно обозначешь модуль, видимость компонент и прозрачные юниты трансляции, но как обычно встаёт проблема поддержки совместимости и нельзя просто взять и добавить, не переписав при этом половину компилятора.
rsashka Автор
20.08.2025 10:26#define FOO // влияет только на этот cpp не влияя на поведения импортов ...
Если я правильно понял Антона, комитет так пока окончательно и не определился с поведение директивы
#defineв модулях и это один из вопрос, который до сих пор не решен.
rsashka Автор
20.08.2025 10:26По итогам конференции загорелся вайб-кодингом и решил повторить это дома. Результаты описал в статье Вайб-кодинг и реальное программирование на С++ с по итогам реального применения генеративных LLM моделей, но уже в "боевых условиях".
domix32
вайб это наоборот про спокойствие и комфорт. когда два человека вайбят - им взаимно комфортно при взаимодействии друг с другом. Поэтому и вайб-кодинг это история про то как "чиловый парень" промтит приложение без приближения к выгоранию. Конечно, на выходе обычно фигня получается. Ну и как говорится - лучшее ТЗ на программу - сама программа. Поэтому ИИ и не отберёт работу у программистов - кому-то всё равно придётся наиболее детальное ТЗ писать.
И не знаю как у вас так получилось, но оно все же харденинг - как у вас в транслитерации ошибка случилась - загадка. Переводится как закалка/укрепление. Закаляйте ваши приложения.
rsashka Автор
Так "спокойствие и комфорт", это и есть про эмоции. Так же как и Андрей Карпаты пишет именно про эмоции и ощущения, которые он испытывает при программировании с помощью LLM
Про вайб-кодинг в реальным проекте на С++ как раз сейчас дописываю статью, которую доделаю и опубликую ближе к концу недели.