[uquote="ПростоНуб",url="/forum/viewtopic.php?p=4169756#p4169756"]Даже элементарный pipeline не сделать. Сваливаемся на процедурный код с объектного.[/uquote]
У людей постоянно какие-то непонятные хотелки, то исключения хотят на С++ для AVR, но поскольку они не тянут, то нужно писать не на С++ без исключений, а на С. Другой товарищ хочет писать на Java, тоже для AVR, а пишет в итоге не на С++ и даже не на С, а на ассме
У меня исключений нет, динамического выделения памяти нет, виртуальная функций несколько на все либы, при этом какой фрагмент кода не возьми он весь привязан к фичам С++ и ощущения, что я сваливаюсь на процедурный код тоже почему-то не возникает.
В-третьих, далеко не факт, что другие функции, в том числе сишные, лучше справятся с парсингом чисел с плавающей точкой... Наконец в данный момент сама функция не constexpr, а в следующем стандарте уже может таковой стать и тогда можно будет без проблем парсить любые числа хоть на 4-х битных мк. У меня в либе портов на этапе компиляции одной строкой сортируется массив структур по трем параметрам при помощи std::ranges::sort() и лямбды, а несколько лет назад использования такой тяжелой функции на мк казалось маловероятным.
У людей постоянно какие-то непонятные хотелки, то исключения хотят на С++ для AVR, но поскольку они не тянут, то нужно писать не на С++ без исключений, а на С. Другой товарищ хочет писать на Java, тоже для AVR, а пишет в итоге не на С++ и даже не на С, а на ассме
У меня исключений нет, динамического выделения памяти нет, виртуальная функций несколько на все либы, при этом какой фрагмент кода не возьми он весь привязан к фичам С++ и ощущения, что я сваливаюсь на процедурный код тоже почему-то не возникает.Речь про value, но не в том смысле, что нельзя подобную функцию переписать с небольшими изменениями на С, просто эта и множество других функций уже написаны профессионалами и доступны всем желающим, многие из них шаблонные и работают на этапе компиляции, потому на С не могут быть написаны в принципе. А если могут, то сначала нужно написать или найти, в обоих случаях надежность и производительность будет под вопросом.ПростоНуб писал(а):Если же речь про параметр value, то в упор не понимаю, в чем тут разница между передачей указателя по значению в С и передачей ссылки в С++, которая в скомпилированном коде так же будет передаваться по значению адреса (того же значения указателя) в ней содержащегося.
Во-первых, то что там много шаблонного кода(еще и проскакивают constexpr функции) еще не означает, что хоть какой-то код имеющий отношение к парсингу чисел по основанию 36 попадет в бинарник. Во-вторых, from_chars() не бросает исключения, динамически не выделяет память и не работает с локалью, так что в каком-то смысле она эмбедд ориентированнаяПростоНуб писал(а):Другое дело, что при жестких требованиях к производительности и памяти, не возникает никакого желания тащить такого монстра, как from_chars, себе в код. Например, зачем мне куча кода для парсинга чисел по основанию 36, если мне нужен парсинг только целых десятичных чисел? Как это не компилируй, но ворох лишнего кода всегда прибежит.
В-третьих, далеко не факт, что другие функции, в том числе сишные, лучше справятся с парсингом чисел с плавающей точкой... Наконец в данный момент сама функция не constexpr, а в следующем стандарте уже может таковой стать и тогда можно будет без проблем парсить любые числа хоть на 4-х битных мк. У меня в либе портов на этапе компиляции одной строкой сортируется массив структур по трем параметрам при помощи std::ranges::sort() и лямбды, а несколько лет назад использования такой тяжелой функции на мк казалось маловероятным.О чем и речь, к мк все сказанное практически никакого отношения не имеет, тем более официально распространяемый gcc для ARM именуется не иначе как gcc-arm-none-eabiПростоНуб писал(а):Было бы смешно, если не было бы так грустно. Для примера, в MS SQL, PostgreSQL или Oracle подключить скомпилированное расширение в виде so/dll - элементарно, причем динамически без остановки сервиса. Потому что они написаны на C и ABI стандартизирован. А вот к Clickhouse - только с полной перекомпиляцией всего Clickhouse и рестартом сервиса, так как он написан на C++, а ABI в C++ меняется даже от версии к версии одного компилятора, не говоря уже о разных.
Тоже самое можно сказать и про ESP32, и про старшие МК на ARM, где расширения могут быть востребованы. а полная рекомпиляция или не желательна, или даже невозможна, так как все исходники недоступны.
Только не нужно Линуса приплетать, он сам на С++ не пишет и цитата относится к 2010 году, вероятно еще про С++03, по сути совершенно другой язык. А синтаксис у С то заметно проще, но это если брать языки в полном объеме, а если взять С и накатить поверх множество мелких улучшений из С++, то получится некое подмножество С++ с синтаксисом проще, чем у С. Последнее время мне даже попадалась парочка книг с подобным подходом, в одной из них автор называл такой С++ кажется Super C, а в D есть ключ компилятора отключающий часть возможностей и превращающий язык в Better CПростоНуб писал(а):Речь не о простоте для изучения (не думаю, что к C это относится, так же, как, для примера, к Lisp). А о простоте синтакиса.
