#define FOO // влияет только на этот cpp не влияя на поведения импортов ...
Если я правильно понял Антона, комитет так пока окончательно и не определился с поведение директивы #define в модулях и это один из вопрос, который до сих пор не решен.
Оооо... это как все просто. Как вам текущий синтаксис С++? А как вам синтаксис С++, который планируется в C++26 стандарте, а в будущих?
Смысл нового языка в том, чтобы уметь описать любой возможный алгоритм и транслировать его в выбранный язык (например в код на С++) с использованием только безопасных средств и методов разработки кода. По сути, это DSL для безопасной работой с памятью и автоматическим управлением синхронизацией при многопоточном или асинхронном программировании и бесшовной интеграцией с кодом на языкуе реализации (т.е. С++).
Как это ни странно, но я не вижу никакой потребности в развитии этого языка.
Ну и зря. У С++ самые лучшие перспективы с точки зрения возможностей и потенциала развития (еще очень много нужно сделать :-) )
А на эту тему статей, на Хабре, практически нет. Ибо все предпочитают говорить «вообще», а не «конкретно».
Вообще то я предпочитаю писать именно «конкретно». Не абстрактные теории, а конкретные предложения, ссылки на которые уже приводил в статье. Однако, что касается С++ модулей, то мне они нужны все же не для текущей работы (меня сейчас и так все устраивает), а именно для проработки теории модульности исходного кода в собственном языке программирования.
Ну, и чём прикол? В этом смысле, любой проект на VS C++ уже разбит на модули: *.h / *.cpp файлов компонент и сопровождающие их файлы. Что нового-то?
Прикол в том, что *.h / *.cpp файлы, это не модули. В С++ модули наоборот противопоставляются заголовочным файлам и являются их прямой заменой.
Разве это не есть модульность в вашем понимании? Чего тогда еще хотеть от модульности в С++, когда она уже в любом виде присутствует там и так?
Это не есть модульность в понимании комитета по стандартизации С++.
Модульность в С++ нужна для библиотек и для крупных проектов, так как упрощает написание взаимозависимого кода (нет необходимости писать отдельные файлы для интерфейса (.h) и реализации (.cpp)), ускоряется компиляция больших проектов и использование программных компонентов (на уровне исходного кода для компилятора) и модули не имеют проблем с порядком их импорта в исходных файлах.
Архитектурный комитет, в виде отдельного органа (как в вашем случае в статье), в маленькой компании невозможен да и ненужен. Обсуждения архитектуры можно делать в компании (или проекте) любого размера. Но архитектурный комитет и обсуждение архитектуры это не одно и тоже.
Роли, это классно, матрицы и оформление документов по PMBOK, это вообще высший пилотаж. В вашем случае как у интегратора (AGIMA - Крупнейший интегратор digital решений, 501–1 000 сотрудников), наверно это имеет смысл. Но много ли компаний могут похвастаться подобной численностью, и простите, а какая проблема решается?
Немного не понял о чем это вы, так как доклад на конференции был про модули С++ в одном конкретное представлении - модульная организация на уровне исходного кода. Это С++ модули только времени компиляции и нужны они только для компилятора при сборке бинарных файлов библиотек или приложений.
Ни к статическим, ни к динамическим библиотекам (как в вашем случае) данные С++ модули отношения не имеют.
Архитектурный комитет, это кончено здорово, но возможно только в крупной компании. И он не всегда может решить проблемы проектов из-за размытия ответственности при принятии решения "Комитет — совет, а не диктатор. Решение — всегда коллективное" и перекладывания ответственности за реализацию только на команду "Ответственность за реализацию несет проектная команда.".
Однако есть отличная альтернатива архитектурному комитету, которую можно использовать даже в маленьких компаний, это Хабр
Системные библиотеки для поддержки периферии могут иметь небольшие отличия от аналога, поэтому тут возникают вопросы насчет возможности поддержки новой аппаратной платформы в рамках одной прошивки (если платформа декларируется совместимой). Как делается, например, для поддержки GD, но приходится учитывать некоторые тонкости в различиях железа.
Тут проблема в другом. Если вы берете "аналог STM32", то рассчитываете на использование уже разработанного кода, но у вас нет возможности отладки с помощью штатных средств (например, STM32CubeIDE), а стандартные библиотеки и уже отлаженные решения могут глючить в самых неожиданных местах.
Возможно с точки зрения трудоемкости имеет смысл менять железо не на "аналог" с непонятным статусом поддержки системного ПО, а перенести бизнес логику на другое железо с нормальной поддержкой системного ПО и средств разработки и отладки.
Портирование AM32 на К1946ВК035 оказалось задачей не из простых — не столько из-за недостатка вычислительной мощности, сколько из-за особенностей периферии. Микроконтроллер уверенно тянет любые алгоритмы управления BLDC-моторами, но разработчику придётся вложиться в адаптацию к архитектуре:
Сделал для себя вывод, что лучше брать микроконтроллер на другой, но нормальной архитектуре (например, RISC-V), чем ловить косяки в "совместимых аналогах".
Заказывал у вас патентный поиск, регистрировал патент и несколько торговых знаков. Жаль, что у вас в последнее время очень сильно подскочили расценки, но все равно рад вашему возвращению на Хабр и реальным кейсам!
Или китайская комната
Если я правильно понял Антона, комитет так пока окончательно и не определился с поведение директивы
#defineв модулях и это один из вопрос, который до сих пор не решен.Так с 1 сентября MAX обязали устанавливать на всех телефонах
Оооо... это как все просто. Как вам текущий синтаксис С++? А как вам синтаксис С++, который планируется в C++26 стандарте, а в будущих?
Смысл нового языка в том, чтобы уметь описать любой возможный алгоритм и транслировать его в выбранный язык (например в код на С++) с использованием только безопасных средств и методов разработки кода. По сути, это DSL для безопасной работой с памятью и автоматическим управлением синхронизацией при многопоточном или асинхронном программировании и бесшовной интеграцией с кодом на языкуе реализации (т.е. С++).
Ну и зря. У С++ самые лучшие перспективы с точки зрения возможностей и потенциала развития (еще очень много нужно сделать :-) )
Вообще то я предпочитаю писать именно «конкретно». Не абстрактные теории, а конкретные предложения, ссылки на которые уже приводил в статье. Однако, что касается С++ модулей, то мне они нужны все же не для текущей работы (меня сейчас и так все устраивает), а именно для проработки теории модульности исходного кода в собственном языке программирования.
Прикол в том, что *.h / *.cpp файлы, это не модули. В С++ модули наоборот противопоставляются заголовочным файлам и являются их прямой заменой.
Это не есть модульность в понимании комитета по стандартизации С++.
Модульность в С++ нужна для библиотек и для крупных проектов, так как упрощает написание взаимозависимого кода (нет необходимости писать отдельные файлы для интерфейса (.h) и реализации (.cpp)), ускоряется компиляция больших проектов и использование программных компонентов (на уровне исходного кода для компилятора) и модули не имеют проблем с порядком их импорта в исходных файлах.
Архитектурный комитет, в виде отдельного органа (как в вашем случае в статье), в маленькой компании невозможен да и ненужен. Обсуждения архитектуры можно делать в компании (или проекте) любого размера. Но архитектурный комитет и обсуждение архитектуры это не одно и тоже.
Роли, это классно, матрицы и оформление документов по PMBOK, это вообще высший пилотаж. В вашем случае как у интегратора (AGIMA - Крупнейший интегратор digital решений, 501–1 000 сотрудников), наверно это имеет смысл. Но много ли компаний могут похвастаться подобной численностью, и простите, а какая проблема решается?
Немного не понял о чем это вы, так как доклад на конференции был про модули С++ в одном конкретное представлении - модульная организация на уровне исходного кода. Это С++ модули только времени компиляции и нужны они только для компилятора при сборке бинарных файлов библиотек или приложений.
Ни к статическим, ни к динамическим библиотекам (как в вашем случае) данные С++ модули отношения не имеют.
Архитектурный комитет, это кончено здорово, но возможно только в крупной компании.
И он не всегда может решить проблемы проектов из-за размытия ответственности при принятии решения "Комитет — совет, а не диктатор. Решение — всегда коллективное" и перекладывания ответственности за реализацию только на команду "Ответственность за реализацию несет проектная команда.".
Однако есть отличная альтернатива архитектурному комитету, которую можно использовать даже в маленьких компаний, это Хабр
Спасибо за ссылку, хотя это больше про плагины с WinAPI, а не про модули в С++.
Так "спокойствие и комфорт", это и есть про эмоции. Так же как и Андрей Карпаты пишет именно про эмоции и ощущения, которые он испытывает при программировании с помощью LLM
Про вайб-кодинг в реальным проекте на С++ как раз сейчас дописываю статью, которую доделаю и опубликую ближе к концу недели.
Системные библиотеки для поддержки периферии могут иметь небольшие отличия от аналога, поэтому тут возникают вопросы насчет возможности поддержки новой аппаратной платформы в рамках одной прошивки (если платформа декларируется совместимой). Как делается, например, для поддержки GD, но приходится учитывать некоторые тонкости в различиях железа.
а так же к системным библиотекам, средствам разработки и отладки :-)
СЕО уже давно при смерти из-за рекламы, а сейчас нейросети его добили окончательно.
Тут проблема в другом. Если вы берете "аналог STM32", то рассчитываете на использование уже разработанного кода, но у вас нет возможности отладки с помощью штатных средств (например, STM32CubeIDE), а стандартные библиотеки и уже отлаженные решения могут глючить в самых неожиданных местах.
Возможно с точки зрения трудоемкости имеет смысл менять железо не на "аналог" с непонятным статусом поддержки системного ПО, а перенести бизнес логику на другое железо с нормальной поддержкой системного ПО и средств разработки и отладки.
Критично всегда использовать голову, а применяемый ею инструмент (карандаш с блокнотом, пишущая машинка или LLM), значения не имеют.
Сделал для себя вывод, что лучше брать микроконтроллер на другой, но нормальной архитектуре (например, RISC-V), чем ловить косяки в "совместимых аналогах".
Самое главное, что это не агрегатор (посредник) для патентных поверенных, а реально работающая компания, которая сама несет ответственно за результат.
Солидарное взыскание при банкротстве?
Заказывал у вас патентный поиск, регистрировал патент и несколько торговых знаков.
Жаль, что у вас в последнее время очень сильно подскочили расценки, но все равно рад вашему возвращению на Хабр и реальным кейсам!