ПростоНуб писал(а):Уже видно по исходникам, что рассматриваемая from_chars() сделана излишне универсальной и перегруженной.
Ок, можно ведь протестировать... Компилируем следующий код на F7:
Код: Выделить всё
PerfCounter perf;
perf.start();
static char arr[] = "1234567890";
volatile int val = atoi(arr);
auto t = perf.getElapsedTicks();
rtt.println(t, val);
Сама функция atoi, которая возвращает 0 при ошибке, потому непонятно как ей парсить "0", добавила к бинарнику 680 байт и исполнялась 309 тактов. Однако даже IDE рекомендует вместо atoi() использовать strtol(), которой ноль уже распарсить можно и для нее получаем +676 байт и 300 тактов. У меня есть собственная constexpr функция, с ней получается +128 байт и 182 такта. Наконец from_chars() показывает практически идентичный результат: +128 байт и 183 такта
ПростоНуб писал(а):Во-вторых, плата за это - когда проект собирается даже на выделенном сервере часы. Тогда невольно жалеешь, что это не C, собирающийся по сравнению с C++ моментально, если не были затронуты корневые включаемые файлы, что происходит очень редко. Пробовали сделать крупный проект на QT? Сколько он собирался?
Специально откопал старенький ноут, создаю в VisualGDB сишный проект на HAL мигающий светодиодом, по умолчанию он компилирует намного больше *.c файлов из HAL, чем нужно для светодиода, но тем не менее, полная пересборка с -O2 -flto занимает 8 сек. Теперь берем эмулятор спектрума на H750 который картину выводит одновременно на дисплей и VGA и где все начиная c пина и заканчивая либами USB/FMC/LTDC/SDMMC/FatFs в виде шаблонный классов и получаем 23 сек. Но зачем после каждого изменения полностью пересобирать проект, если что-то поменять в парочке файлов, то сама компиляция займет секунд 5 и еще 13 сек. линковка и время линковки можно существенно сократить отключив LTO. На нормально железе все будет происходить в разы быстрее и это даже без учета модулей...
ПростоНуб писал(а):А как он не попадет, если base будет переменная? Я могу ограничить пользователя, например, base<=10 при вводе, но у меня большие сомнения, что оптимизатор настолько умен, что не только увидит и запомнит это ограничение, но еще и применит его при оптимизации case в __to_chars_i()
В большинстве случаев парсят десятичные числа, собственно потому у base значение по умолчанию равно 10, так что скорее всего будет константа или base не будет вообще, в таком случае можно изначально попасть в перегруженную функцию принимающую на один параметр меньше.
ПростоНуб писал(а):Вас несет. Возьмите и сравните c atof, как по размеру кода, так и по производительности, и уже после этого рассуждайте. А то уж очень демагогией попахивает. Если ничего не делать. то все будет "далеко не факт".
Так сравнил уже, к сожалению поддержку float для from_chars() добавили только в gcc 11, которого для ARM еще нет, но я изначально ожидал возможный выигрыш именно на float, а оказалось он есть даже для целых чисел.
ПростоНуб писал(а):Для имеющих проблемы со зрением использовал полужирное начертание )))
Можно хоть все посты полужирным выделить и третий раз Линуса процитировать, все равно никто не перестанет писать на С++ для Cortex-M потому что возможны какие-то гипотетические проблемы с ABI на Cortex-A
На ПК у меня никаких проблем с ABI нет, к С++ проектам линкуются либы от С, а C# грузит dll от C/C++, когда-то я даже портировал DirectX 9/10 на D, там с одной стороны либы в coff, а с другой в omf и ничего, большинство подобных проблем решаемо.
ПростоНуб писал(а):Почему это не надо? Он достаточно четко выразился, что один и тот же код в C++ может, в зависимости от контекста, выполнять совершенно разные действия. Вы же сами это пропагандируете шаблонами. Вот только это очень удобно при написании программы, но сильно повышает трудоемкость при ее сопровождении, что как раз и подчеркнул Линус. Например, я сам не раз сталкивался с совершенно негуманоидой логикой реализации операций сложения или сравнения для некоторых объектов некоторыми программистами.
Распространенный пример из мира эмбедда, пожалуйста. Лично у меня перегружены операторы для строгих перечислений, тут никаких вопросов быть не может, любой гайд по С++ будет рекомендовать не использовать сишные перечисления. Далее перегружен оператор "|" для пинов:
Еще операторы сравнения для списка пинов и еще класс для работы с фиксированной точкой, там много чего перегружено, но в результате такой тип может работать там где и float:
Код: Выделить всё
constexpr auto f1 = sin(1.2345f);
constexpr auto f2 = sin(Fixed<12>(1.2345f));
rtt.println(f1, (float)f2); // 0.94398332, 0.94397926
Вроде все, причем очень сильно подозреваю, что у других пишущих на полюсах в среднем еще меньше, а оказывается это не менее серьезная проблема, чем невозможность использовать исключения на AVR
