Вс ноя 29, 2020 11:04:04
Вс ноя 29, 2020 11:08:00
Пн ноя 30, 2020 08:25:33
Отлично, только я вот для микроконтроллера C99 (с некоторыми оговорками, типа отсутствия VLA) предпочитаю - по соображениям портабельности, предсказуемости и понятности мне того что компилер вытворять удумает. И вот как-то именно в сях - эти литералы ну вот не стандартизировали. И какая мне разнца что там в 14-х плюсах? Это другой ЯП, я им не пользуюсь, и он даже жуется другим бинарником компилера в случае gcc. Так что номинально грешок за мной водится, увы. И как угодно но свои огрехи в случае МК как мне кажется лучше знать. Чтобы понимать на что расчитывать.iddqd, двоичные литералы через 0b в стандарте C++14 ещё ввели.
Я gcc'ом LTO+GC секций научился делать, на более менее крупном (более ~4-5kb) коде добрая четверть кода нахаляву урезается. В том плане что логика не ломается, скорость не проседает - и все это просто потому что с LTO делается глобальная оптимизация, по всему коду. Это делает кодогенерацию довольно чудесатой, и иногда умеет прикалываться. Иногда даже перестановка statement местами меняет размер. Но работает круто. Особенно когда есть где развернуться. В этих примерах LTO + GC sections не используется и это соответствнено не максимум что можно извлечь из GCC. Может ли clang что-то сравнимое и насколько это (не)эффективно и (без)глючно пусть фаны clang исследуют. В силу природы оптимизаций оно может и поприкалываться.з.ы. для blink получается clang бинарник больше чем gcc
Пн ноя 30, 2020 12:53:53
Пн ноя 30, 2020 14:28:12
Пн ноя 30, 2020 15:08:43
Вт дек 01, 2020 00:29:13
Да меня и сишный устраивает, апгрейдить требования с C99 до C++14 я не планирую. Это бред сивой кобылы, что-то подобное я только у виндовых дев с студией, но они это потому что поддержка C99 в студиях лютое гэ, поэтому такой вот "си++", внутрях чистый си, а из ++ аж //целые. Не хочу уподобляться. И в этом месте я лучше формально признаю что юзаю "нестандартный" гнутый экстеншн чем скажу что это C++14. Настоящие плюсовики меня не поймут, а юзать полновесный C++14 в мк в мои планы не входит.Именно из-за таких мелочей и стоит даже С код компилировать С++ компилятором.
Gcc и под F1xx вроде нормально работает, а то что он свободный - так это хорошо, не получится так что корп утащит в свое логово, а остальные обломятся. Под F4 тоже собирает, но у меня этих монстриков просто нет, не надо мне столько, да и на тех кто F4 на асме пойдет наворачивать я бы посмотрелИсключительно свободное для STM32F0, дальше которых ты не ходишь. Просто ты такие восторги в соседней теме про Clang излучал, при том что люди давным давно им просто пользуются даже не подозревая.
Вт дек 01, 2020 06:51:34
Чт дек 03, 2020 06:37:24
С этого места предлагается либо крестик снять, либо трусы надеть. Вопрос то для вас, оказалось, религиозно-фанатичный.
Чт дек 03, 2020 08:06:32
Пт дек 04, 2020 11:24:34
Пт дек 04, 2020 12:06:35
Menu<lcd, menuItems> menu(...)
Пт дек 04, 2020 14:13:29
Пт дек 04, 2020 15:27:21
Пт дек 04, 2020 16:12:05
В сях нет никаких конструкторов-деструкторов... но чтобы об этом знать, надо наверное попробовать туда сунуться, а то и свой такой написать. А так то когда вам кто-то черный ящик прилинковал, конечно, поди там разберись есть ли разница.С какой стати? Тот же стартап.
Интересно, а сколько для этого asm дампы читать пришлось? На сях то удобную процу конструкцию довольно тривиально размудрить . Ну и вон serial.begin'щики этим редко могут похвастать.А в жизни, когда я показываю на плюсах более эффективное дёргание лапками чем на сях
При том что когда я на сях пишу мне более-менее понятно во что это скорее всего компилер трансформирует. Без всенепременного вштыривания в ассемблерный кусок каждый раз. С навороченной си++ штукой с какими-нибудь классами и прочими это как-то менее очевидно.Причём тут язык? Вы либо понимаете как работает железка, либо нет.
Пт дек 04, 2020 16:45:37
Menu<lcd, menuItems> menu(...) - на си наверное тоже можно нечто сравнимое сделать.
const int arr[] = { 10, 20, 30, 40, 50 };
Но вот лично меня МК интересуют не отрисовкой меню. А жестко реалтаймным управлением всяким, измерениями и проч. И предсказуемость волнует не в менюхе. А где-нибудь на стыке координирования железок, и всем таком. Там порой хочется чуть ли не потактово понимать что будет. А си++ этому как-то совсем не способствует. Ну, если не понимать под таковыми только 0bXXXX, при сплошных сях вокруг
digits::clear();
segs::write(comAnodeTbl[ch]);
digits::write(1 << digit);
using segs = PinList<PC7, PA4, PA10, PB10, PB11, PD3, PB9, PA11>;
using digits = PinList<PC0, PB8, PA3, PC6>;
Semiseg<digits, segs> semiseg;
Пт дек 04, 2020 18:32:30
for(void(**fConstr)() = __preinit_array_start; fConstr < __preinit_array_end; (*fConstr++)());
for(void(**fConstr)() = __init_array_start; fConstr < __init_array_end; (*fConstr++)());
*(volatile uint8_t *)&GPIOA->ODR = x;
Пт дек 04, 2020 19:54:33
const int arr[] = { 10, 20, 30, 40, 50 };
for(auto& v: arr)
{
rtt.print<"{}, {}\n">(&v, v);
}
const Transform<arr> trfm;
Пт дек 04, 2020 20:12:36
Пт дек 04, 2020 20:35:08