Простите за грубость, но статья откровенное Г. Возможно вы, как погруженный в тему, имеете представление о проблеме, а вот я, как читатель, так и не понял что именно вам нужно и почему вы этого не можете получить. Полагаю, очень не хватает иллюстрирующих суть происходящего примеров кода. Типа вот это есть, вот этого хотелось бы, вот из-за этого не получается.
Отдельно доставляют запрятанные под кат простыни диалога с ИИ. Они кому-то кроме вас интересны?
ИМХО, просто образец того, как писать статьи не нужно. Еще раз проссыте за грубость.
А я потом опубликую продолжение этого разговора в котором ИИ оправдывается-анализирует почему он не смог предложить мне, если не правильное решение
Может лучше не надо?
Уверен, что не понял суть ваших затруднений. Но сложилось впечатление, что вам нужно от класса Sensor сделать шаблонный класс-наследник. Который должен параметризоваться специальным классом с нужными вам свойствами. И в коде далее должен использоваться не Sensor, а этот шаблонный наследник. Что-то типа:
template< typename Props >
class BasicSensor : public Sensor {
...
// Этот метод должен использоваться для получения пути
// к тестовым файлам.
[[nodiscard]] std::filesystem::path getTestDataPath() {
// А вот главный трюк: это значение должен предоставлять класс Props.
return Props::testDataPath;
}
...
}
После чего для того, чтобы использовать BasicSensor пользователь должен определить соответствующий класс свойств со статическим членом внутри.
struct MySensorProps {
static std::filesystem::path testDataPath;
};
...
class MySensor : public BasicSensor< MySensorProps > {
...
};
В копилку хороших парсеров аргументов командной строки надо бы добавить еще и args с Lyra
А статье, имхо, не хватает перечня недостатков в существующих библиотеках и компенсирующих их достоинств в FancyArgumentParser. Типа “вот в XX и в YY вот это не делается никак, а в ZZ – только через тридцать три лишних приседания, тогда как в FancyArgumentParser – двумя с половиной строчками”.
Без такого перечня складывается ощущение, что у всех отвергнутых автором библиотек был всего лишь один фатальный недостаток…
Если нет никакой физкультуры, то имеет смысл добавить какой-либо вид ОФП. Это поможет и повысить работоспособность сейчас, и сохранит эту самую работоспособность на долгие годы вперед. Лет через 30 организм только спасибо скажет за привитые в молодости привычки к физическим упражнениям. А эти самые 30 лет, увы, пролетят очень и очень быстро.
Исключения дороги по производительности на throw‑path, требуют exception‑safe‑кода во всей цепочке вызовов, плохо взаимодействуют с многопоточностью
Не устану повторять, что в С++ принципы обеспечения exception safety прекрасно работают и для обычных return-ов. Поэтому если разработчик озадачился вопросами exception safety, то нет разницы, сообщается ли об ошибке через exception или через early return.
Особенностью моей работы является то, что пока в одном проекте можно использовать фичи свежего стандарта, рядом обязательно будет проект, отстающий на один два стандарта. Например, сегодня работаешь на C++20, завтра вынужден откатываться до C++17 или C++14 (вот C++11 давненько не было, к счастью). И каждый раз сразу видно скольких хороших вещей тебя лишили. Это ощущалось всегда: и при переходе с C++20 на C++17, и с C++17 на C++14… Особенно при переходе с C++14 на C++98/03. Тут вообще как будто на другой язык переучиваться приходилось.
Тем удивительнее в 2026-ом слышать панегирики C++98/03. Даже не смотря на то, что дичи в современные стандарты добавляют изрядно.
У меня есть версия, что статья написана специально для того, чтобы устроить перепись ниасиляторов фанатов старого доброго “Си с классами” и Qt головного мозга. По типу вот этого или вот этого комментариев.
Вас опять несет не в ту сторону. Мне, например, не нравятся такие языки, как Си, Java и Go. Но я не бегаю по Хабру и не доказываю, что есть языки лучше. И не страдаю от необходимости начинать новые проекты на них.
А вот вы страдаете. Ну так не страдайте.
Значит, читателю стоит в следующий раз читать внимательнее и разбираться, какой пример к какому языку относится.
Раз вы разобрались с нюансами C++ и освоили Haskell-и с Agda-ми, значит должны быть интеллектуально развиты. Но эта развитость удивительным образом не позволяет видеть простых вещей: вот есть ваш комментарий про более безопасные языки. Допустим, что читатель, который устал от проблем C++, смотрит на ваши примеры и хочет взять какой-либо из “более других” языков вместо C++. Ну, например, чтобы сделать свой Excel. Или сильно специализированную альтернативу nginx. И…
И в реальности он быстро обнаружит, что даже у Rust-а не будет безоговорочного преимущества. Не говоря уже про Haskell-и.
Получается, что если язык программирования для читателя – это не вещь в себе и не самоцель, а всего лишь инструмент, то ваш комментарий тупо лишен практического смысла. Поэтому и не нужно разбираться с тем, какие еще смыслы вы туда вкладывали и какая запятая к чему относилась.
Если у вас с аналогиями хуже, чем у идиота, то что это о вас говорит?
Обо мне это может говорить все что угодно. Например, что я в 10 раз тупее вас (что вполне соответствует действительности). Только вот каким бы ни был я сам, вы умным идиотом быть не перестанете.
Мне думается, что водораздел достаточно простой: у вас есть код проекта, в этом коде вы используете какие-то библиотеки напрямую. Вот это и имеет смысл рассматривать. А то, что библиотека где-то внутри как-то обращается к функциональности ОС – это уже за рамками разговора. Т.е. глубину рекурсии можно жестко ограничить.
Одна из сложностей разговора о новых проектах на C++ в том, что практически не бывает новых проектов, которые начинаются с абсолютного нуля и пишутся полностью самостоятельно, без переиспользования уже готовых библиотек.
Для C++ таких библиотек множество. Это только про чисто C++ны. Плюс огромное количество С-шных, которые из C++ используются как родные.
И если проект стартует на базе Boost+Folly+Abceil+ffmpeg+DearImGui и т.д., и т.п., то где грань между “новым” и “легаси”?
Поэтому и не хочется разводить рассуждения на эту тему.
Моя основная критика C++ — что это неюзабельный язык с фрактальной сложностью, единственная причина выбирать который для программирования в 2026-м — легаси.
Ну так не выбирайте. Вас кто-то силой заставляет?
А это — другой поинт, и не надо его смешивать с предыдущим.
Или это вам так кажется. Может вам хотелось бы, чтобы ваш комментарий, в котором вы приводите примеры на Haskell-е и Agda, воспринимался как многослойный с кучей поинтов и смыслов. Может вы даже пытались его таким сделать.
Но для одного конкретного читателя он выглядит гораздо проще: есть C/C++, которые сплошной unsafe, и есть более безопасные языки с парой конкретных примеров оных. И все.
Ну вы же знаете, что будет дальше?
Нет, я не умею предсказывать будущее.
Ровно это может быть использовано как «причина» для
Для каких-то выводов, которые странным образом рождаются в вашей голове и которые я не понимаю. Вы строите какие-то свои взаимосвязи и выдаете это за якобы следствия из моих слов.
Вы мне пытаетесь донести, что причины — [в том числе] экономические, и я по-вашему этого не понимаю, несмотря на то, что мой первый же ответ вам на эту тему начинался с «В экономике»?
Нет, я не это вам пытаюсь донести. Но, как уже было сказано выше, простые вещи вы не понимаете. Это доказано уже не первым разговором.
А могли бы позвать многочисленных комментаторов с хабра (и заодно с опеннета) — они знают, как надо, и пишут безбажный код по их словам!
Мне кажется, что гораздо проще и гораздо точнее будет просто вас охарактеризовать как умного идиота.
А как называется переход от «язык позволяет выражать такие-то вещи [невозможность делить на ноль]» к «а чего тогда на нём не пишут $X, где эти вещи не являются определяющим фактором»?
Это не переход. Это ключевой момент касающийся вашей критики C++. Когда вы сравниваете C++ с Haskell-ем или Adga2, вы сравниваете огурцы с ананасами. И те, и другие можно есть, но они не являются друг другу заменой.
И может быть многие бы хотели бы есть больше ананасов, но даже экономические возможности этого не позволяют. Не говоря уже про другие факторы.
Это я вам на языке “аналогий” пытаюсь донести то, что вы никак не поймете.
сравнение C++ с другими языками там есть
О том и речь.
Правда, на том же расте пишут и ОС, и браузеры.
Только вот ваши примеры относились не к Rust-у.
Сколько там нового кода в андроиде на плюсах, а сколько — на расте?
ХЗ, я не пишу код Андроида. В том, чем занимаюсь я в последнее время, Rust лично мне не кажется 100% оправданной заменой. Т.е. где-то за счет Rust-а было бы проще. Где-то – сильно нет.
То, что замены C++у появляются меня лично радует, т.к. не смотря на всю мою любовь к C++, тратить время на разбирательства с падениями из-за порчи памяти жалко. Пока, к сожалению, из адекватных замен только Rust.
Я вам показываю аналогией, как ваш «аргумент» выглядит в другом контексте.
Вы изливаете на меня какую-то дурно пахнущую субстанцию из своей головы. Например, я вообще не могу понять как у вас возникла вот эта “аналогия”:
Это вообще ничем не отличается по сути от гипотетического:
— Другой чувак: питон так же быстр, как C++.
— Вы: нет, вот пример.
— Я: а чего тогда на C++ не пишут бекенды?
Здесь ничего и близко нет к тому, о чем я вам говорю. Как по мне, так это какое-то говно, к которому я не имею никакого отношения от слова совсем. Но вы что-то за меня додумываете и потом с этим же додуманным старательно сражаетесь, да еще и приписывая подмены мне.
Осталась вторая половина — чтобы вы увидели то же самое в ваших исходных словах.
Вы упорно хотите заставить меня искать темную кошку в темной комнате. Только вот а) мне это не нужно и b) вряд ли эта кошка есть вообще.
Я сравнил этот более другой язык с хаскелем (на котором был предыдущий пример), потому что в хаскеле система типов недостаточно выразительна.
Сперва вы говорили про то, что C/C++ один большой unsafe, после чего перешли к более безопасным языкам. Т.е. все эти примеры на безопасных языках и есть сравнение с C++.
Простите за грубость, но статья откровенное Г. Возможно вы, как погруженный в тему, имеете представление о проблеме, а вот я, как читатель, так и не понял что именно вам нужно и почему вы этого не можете получить. Полагаю, очень не хватает иллюстрирующих суть происходящего примеров кода. Типа вот это есть, вот этого хотелось бы, вот из-за этого не получается.
Отдельно доставляют запрятанные под кат простыни диалога с ИИ. Они кому-то кроме вас интересны?
ИМХО, просто образец того, как писать статьи не нужно. Еще раз проссыте за грубость.
Может лучше не надо?
Уверен, что не понял суть ваших затруднений. Но сложилось впечатление, что вам нужно от класса Sensor сделать шаблонный класс-наследник. Который должен параметризоваться специальным классом с нужными вам свойствами. И в коде далее должен использоваться не Sensor, а этот шаблонный наследник. Что-то типа:
После чего для того, чтобы использовать BasicSensor пользователь должен определить соответствующий класс свойств со статическим членом внутри.
И ничего у вас компилятор выбрасывать не будет.
В копилку хороших парсеров аргументов командной строки надо бы добавить еще и args с Lyra
А статье, имхо, не хватает перечня недостатков в существующих библиотеках и компенсирующих их достоинств в FancyArgumentParser. Типа “вот в XX и в YY вот это не делается никак, а в ZZ – только через тридцать три лишних приседания, тогда как в FancyArgumentParser – двумя с половиной строчками”.
Без такого перечня складывается ощущение, что у всех отвергнутых автором библиотек был всего лишь один фатальный недостаток…
Мне-то чего переживать? ;)
Это вам еще на протяжении десятков лет за компьютером по много часов просиживать.
Если нет никакой физкультуры, то имеет смысл добавить какой-либо вид ОФП. Это поможет и повысить работоспособность сейчас, и сохранит эту самую работоспособность на долгие годы вперед. Лет через 30 организм только спасибо скажет за привитые в молодости привычки к физическим упражнениям. А эти самые 30 лет, увы, пролетят очень и очень быстро.
Не устану повторять, что в С++ принципы обеспечения exception safety прекрасно работают и для обычных return-ов. Поэтому если разработчик озадачился вопросами exception safety, то нет разницы, сообщается ли об ошибке через exception или через early return.
В обобщенном коде и обычный auto, и decltype(auto) встретить не проблема (тыц или тыц).
Особенностью моей работы является то, что пока в одном проекте можно использовать фичи свежего стандарта, рядом обязательно будет проект, отстающий на один два стандарта. Например, сегодня работаешь на C++20, завтра вынужден откатываться до C++17 или C++14 (вот C++11 давненько не было, к счастью). И каждый раз сразу видно скольких хороших вещей тебя лишили. Это ощущалось всегда: и при переходе с C++20 на C++17, и с C++17 на C++14… Особенно при переходе с C++14 на C++98/03. Тут вообще как будто на другой язык переучиваться приходилось.
Тем удивительнее в 2026-ом слышать панегирики C++98/03. Даже не смотря на то, что дичи в современные стандарты добавляют изрядно.
У меня есть версия, что статья написана специально для того, чтобы устроить перепись
ниасиляторовфанатов старого доброго “Си с классами” и Qt головного мозга. По типу вот этого или вот этого комментариев.юнит-тесты на этот код были бы написаны. С разными вариантами входных значений.
Но, можно предположить, ничего подобного не было.
И чтобы можно было присвоить новое значение (т.е. переинициализация присваиванием), если правильно помню.
Я уже давным давно сделал то, что нужно было лично мне. И даже давным давно об этом статью здесь же опубликовал.
Единственная мысль после просмотра листингов кода из статьи: как же хорошо, что не приходится иметь с этим дел!
Мне незачем определяться с тем, что ко мне отношения не имеет.
Возражать?
Хватит уже приписывать мне то, чего я не говорил.
Начать можно с того, чтобы сделать анализ а что из этих ваших “неоправданных предположений” были высказанны мной в реальности.
Вас опять несет не в ту сторону. Мне, например, не нравятся такие языки, как Си, Java и Go. Но я не бегаю по Хабру и не доказываю, что есть языки лучше. И не страдаю от необходимости начинать новые проекты на них.
А вот вы страдаете. Ну так не страдайте.
Раз вы разобрались с нюансами C++ и освоили Haskell-и с Agda-ми, значит должны быть интеллектуально развиты. Но эта развитость удивительным образом не позволяет видеть простых вещей: вот есть ваш комментарий про более безопасные языки. Допустим, что читатель, который устал от проблем C++, смотрит на ваши примеры и хочет взять какой-либо из “более других” языков вместо C++. Ну, например, чтобы сделать свой Excel. Или сильно специализированную альтернативу nginx. И…
И в реальности он быстро обнаружит, что даже у Rust-а не будет безоговорочного преимущества. Не говоря уже про Haskell-и.
Получается, что если язык программирования для читателя – это не вещь в себе и не самоцель, а всего лишь инструмент, то ваш комментарий тупо лишен практического смысла. Поэтому и не нужно разбираться с тем, какие еще смыслы вы туда вкладывали и какая запятая к чему относилась.
Обо мне это может говорить все что угодно. Например, что я в 10 раз тупее вас (что вполне соответствует действительности). Только вот каким бы ни был я сам, вы умным идиотом быть не перестанете.
Мне думается, что водораздел достаточно простой: у вас есть код проекта, в этом коде вы используете какие-то библиотеки напрямую. Вот это и имеет смысл рассматривать. А то, что библиотека где-то внутри как-то обращается к функциональности ОС – это уже за рамками разговора. Т.е. глубину рекурсии можно жестко ограничить.
Одна из сложностей разговора о новых проектах на C++ в том, что практически не бывает новых проектов, которые начинаются с абсолютного нуля и пишутся полностью самостоятельно, без переиспользования уже готовых библиотек.
Для C++ таких библиотек множество. Это только про чисто C++ны. Плюс огромное количество С-шных, которые из C++ используются как родные.
И если проект стартует на базе Boost+Folly+Abceil+ffmpeg+DearImGui и т.д., и т.п., то где грань между “новым” и “легаси”?
Поэтому и не хочется разводить рассуждения на эту тему.
Ну так не выбирайте. Вас кто-то силой заставляет?
Или это вам так кажется. Может вам хотелось бы, чтобы ваш комментарий, в котором вы приводите примеры на Haskell-е и Agda, воспринимался как многослойный с кучей поинтов и смыслов. Может вы даже пытались его таким сделать.
Но для одного конкретного читателя он выглядит гораздо проще: есть C/C++, которые сплошной unsafe, и есть более безопасные языки с парой конкретных примеров оных. И все.
Нет, я не умею предсказывать будущее.
Для каких-то выводов, которые странным образом рождаются в вашей голове и которые я не понимаю. Вы строите какие-то свои взаимосвязи и выдаете это за якобы следствия из моих слов.
Нет, я не это вам пытаюсь донести. Но, как уже было сказано выше, простые вещи вы не понимаете. Это доказано уже не первым разговором.
Мне кажется, что гораздо проще и гораздо точнее будет просто вас охарактеризовать как умного идиота.
Это не переход. Это ключевой момент касающийся вашей критики C++. Когда вы сравниваете C++ с Haskell-ем или Adga2, вы сравниваете огурцы с ананасами. И те, и другие можно есть, но они не являются друг другу заменой.
И может быть многие бы хотели бы есть больше ананасов, но даже экономические возможности этого не позволяют. Не говоря уже про другие факторы.
Это я вам на языке “аналогий” пытаюсь донести то, что вы никак не поймете.
О том и речь.
Только вот ваши примеры относились не к Rust-у.
ХЗ, я не пишу код Андроида. В том, чем занимаюсь я в последнее время, Rust лично мне не кажется 100% оправданной заменой. Т.е. где-то за счет Rust-а было бы проще. Где-то – сильно нет.
То, что замены C++у появляются меня лично радует, т.к. не смотря на всю мою любовь к C++, тратить время на разбирательства с падениями из-за порчи памяти жалко. Пока, к сожалению, из адекватных замен только Rust.
Вы изливаете на меня какую-то дурно пахнущую субстанцию из своей головы. Например, я вообще не могу понять как у вас возникла вот эта “аналогия”:
Здесь ничего и близко нет к тому, о чем я вам говорю. Как по мне, так это какое-то говно, к которому я не имею никакого отношения от слова совсем. Но вы что-то за меня додумываете и потом с этим же додуманным старательно сражаетесь, да еще и приписывая подмены мне.
Вы упорно хотите заставить меня искать темную кошку в темной комнате. Только вот а) мне это не нужно и b) вряд ли эта кошка есть вообще.
Сперва вы говорили про то, что C/C++ один большой unsafe, после чего перешли к более безопасным языкам. Т.е. все эти примеры на безопасных языках и есть сравнение с C++.