Возможно я понимаю ваши намерения. Но не согласен с вашей точкой зрения.
До этого примера материал в статье не вызывал вопросов. Но когда этот пример появился, возникло ощущение, что вы только зря “тень на плетень” наводите. Что он не иллюстрирует тот момент, который вы хотели показать, а только усложняет восприятие и запутывает читателя.
Собственно, как и следующий пример с auto n = v; в функции normalize. Те же самые грабли есть и в обычных, не шаблонных, функциях.
На этом рассуждения про “проблемы” с шаблонами и жутью про защищенные страницы можно было бы и завершить. Потому что шаблоны здесь не при чем от слова совсем.
…то есть тем, что кратко называется перекладыванием джейсонов.
По сути это тоже работа которую кому-то нужно работать и за которую вполне себе хорошо платят. Но эту работу на моей памяти всегда пытались автоматизировать и сводить к максимально декларативному виду.
Я вообще удивлен, что столь очевидное и распространенное в каких нибудь американских стартапах мнение воспринимается здесь как троллинг.
Возможно это потому, что вы не говорите о каком именно программировании идет речь. Может вы занимаетесь тем, что читаете N полей из таблицы, отображаете их на форме, контролируете ввод пользователя на предмет того, что в число нельзя добавлять буквы, проверяете введенные значения на попадание в заданный диапазон, после чего записываете измененные поля обратно.
Да, конвейер диапазонов (ranges) капельку отстает на крошечных объемах данных, но на крупных массивах разница укладывается в рамки статистической погрешности. В этом и кроется суть: более элегантный и выразительный код не требует значительных издержек на абстракцию.
Тут бы еще и время компиляции сравнить. Особенно когда подобный код в одной единице трансляции используется не единожды. Или когда такой код находится в шаблоне функции, а эта функция используется в нескольких единицах трансляции.
Есть класс struct Sensor, который полностью определен в хидер-файле sensor.hpp, который включается в десятки файлов.
Из вашей статьи я не понял: вы сделали форк проекта dbus-sensors и пропатчили класс Sensor в своем форке? Или же вы собираетесь обновлять реализацию класса Sensor в самом проекте dbus-sensors (т.е. готовите патч, который затем отправите в апстрим)?
Простите за грубость, но статья откровенное Г. Возможно вы, как погруженный в тему, имеете представление о проблеме, а вот я, как читатель, так и не понял что именно вам нужно и почему вы этого не можете получить. Полагаю, очень не хватает иллюстрирующих суть происходящего примеров кода. Типа вот это есть, вот этого хотелось бы, вот из-за этого не получается.
Отдельно доставляют запрятанные под кат простыни диалога с ИИ. Они кому-то кроме вас интересны?
ИМХО, просто образец того, как писать статьи не нужно. Еще раз проссыте за грубость.
А я потом опубликую продолжение этого разговора в котором ИИ оправдывается-анализирует почему он не смог предложить мне, если не правильное решение
Может лучше не надо?
Уверен, что не понял суть ваших затруднений. Но сложилось впечатление, что вам нужно от класса 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 головного мозга. По типу вот этого или вот этого комментариев.
Есть простой критерий: если проблема воспроизводится в сценарии без шаблона, значит шаблон не при чем.
ИМХО, здесь universal references (как их называл Мейерс) были бы более уместны.
Возможно я понимаю ваши намерения. Но не согласен с вашей точкой зрения.
До этого примера материал в статье не вызывал вопросов. Но когда этот пример появился, возникло ощущение, что вы только зря “тень на плетень” наводите. Что он не иллюстрирует тот момент, который вы хотели показать, а только усложняет восприятие и запутывает читателя.
Собственно, как и следующий пример с
auto n = v;в функцииnormalize. Те же самые грабли есть и в обычных, не шаблонных, функциях.На этом рассуждения про “проблемы” с шаблонами и жутью про защищенные страницы можно было бы и завершить. Потому что шаблоны здесь не при чем от слова совсем.
По сути это тоже работа которую кому-то нужно работать и за которую вполне себе хорошо платят. Но эту работу на моей памяти всегда пытались автоматизировать и сводить к максимально декларативному виду.
Возможно это потому, что вы не говорите о каком именно программировании идет речь. Может вы занимаетесь тем, что читаете N полей из таблицы, отображаете их на форме, контролируете ввод пользователя на предмет того, что в число нельзя добавлять буквы, проверяете введенные значения на попадание в заданный диапазон, после чего записываете измененные поля обратно.
Спасибо за развернутый ответ.
И что, если не секрет?
Выглядит так, что только к 50 вы столкнулись с настоящим промышленным программированием.
Таки не понято, если вы программировали на работе, то разве это было не за деньги?
Ну как скажете.
Тут бы еще и время компиляции сравнить. Особенно когда подобный код в одной единице трансляции используется не единожды. Или когда такой код находится в шаблоне функции, а эта функция используется в нескольких единицах трансляции.
Для оценки адекватности описываемой проблемы и найденного решения. А судя по этому вопросу еще и автора статьи.
Из вашей статьи я не понял: вы сделали форк проекта dbus-sensors и пропатчили класс Sensor в своем форке? Или же вы собираетесь обновлять реализацию класса Sensor в самом проекте dbus-sensors (т.е. готовите патч, который затем отправите в апстрим)?
Простите за грубость, но статья откровенное Г. Возможно вы, как погруженный в тему, имеете представление о проблеме, а вот я, как читатель, так и не понял что именно вам нужно и почему вы этого не можете получить. Полагаю, очень не хватает иллюстрирующих суть происходящего примеров кода. Типа вот это есть, вот этого хотелось бы, вот из-за этого не получается.
Отдельно доставляют запрятанные под кат простыни диалога с ИИ. Они кому-то кроме вас интересны?
ИМХО, просто образец того, как писать статьи не нужно. Еще раз проссыте за грубость.
Может лучше не надо?
Уверен, что не понял суть ваших затруднений. Но сложилось впечатление, что вам нужно от класса 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 головного мозга. По типу вот этого или вот этого комментариев.