[uquote="a5021",url="/forum/viewtopic.php?p=3384669#p3384669"]У вас наваждение такое случилось или вы и показать сможете, где я недостатки в gcc 7 вскрывал?[/uquote]
Началось все с девелоперской ветки GCC, значит он может и нестабильный еще, кроме того его и прикручивать куда-то нужно, что тоже не очень удобно, и даже не куда-то, а к эклипсу, который, я дал поиск по истории, ты тоже не любишь. А когда выяснилось, что про статус gcc, эклипс и прикручивание ты все просто выдумал, в ход пошел последний аргумент состоящий в том, что gcc 7 все равно никто не использует. Видимо это должно означать, что даже если как компилятор он и неплох, то толку от этого все равно мало. С ООП та же история, реальных фактов никаких, зато плох даже не ООП код который просто похож на таковой
Еще раз, обращаясь ко всем оппонентам в этом диспуте: ООП -- инструмент замечательный, новые правила и конструкции языка -- достижение. Только это не означает, что всем нужно подорваться строчить по три экрана кода, чтобы три бита перевернуть один раз во всей программе. Бред это.
Если хотелось просто показать изящество языка, нужно первым дело было придумать пример это иллюстрирующий. А на приведенном примере -- это скорее профанация.
Ладно, как насчет такого примера, шлем и принимаем строку через USART при помощи DMA(TX соединен с RX):
Спойлер
Код: Выделить всё
static char msg_in[16] = "Hello World!";
static char msg_out[16] = {};
using usart = Usart2<>;
usart::init<PinA<2, 7>, PinA<3, 7>>(115200);
usart::initChannelTx<Dma1Ch7>(msg_in, 12);
usart::initChannelRx<Dma1Ch6>(msg_out, 12);
usart::enable(UsartCr3::DmaReceiver | UsartCr3::DmaTransmitter);
while (!Dma1Ch6::isInterruptReady(DmaFlag::TransferComplete)) {}
Я запускал на F3, но этот код будет работать и на F1, где регистры портов совсем другие, а для RX еще и нужно выбрать другой режим. И на F4 тоже работает, но там вместо каналов DMA нужно передать стримы, а вторым параметром будет номер канала. Более того, все это можно передать дальше, у меня есть класс для работы с DS18B20, он как раз принимает USART, пин и пару каналов DMA, можно одной строкой сконфигурировать его для работы с требуемой периферией, а следующей строкой,если очень нужно, сделать это для второго датчика высящего на другом пине другого усарта. Ну и чтобы по-настоящему оценить изящество этого кода хотелось бы увидеть в ответ аналогичный код на регистрах столбиком, тогда будет проще сравнить какой вариант компактнее, понятнее, устойчивее к ошибкам программирования или переносимее. То что у моего варианта будет некоторый оверхед по размеру понятно и так, но, опять же, не из-за классов и шаблонов, а из-за того, что тот же USART, например, при инициализации запросит скорость своей шины, но именно это позволяет такому коду сидеть в модуле DS18B20 и ни от чего не зависеть. А на регистрах я сам прекрасно писать умею, весь код внутри этих классов на регистрах и написан, так что в этом плане меня ничем удивить невозможно.
Люди в упор не понимают зачем нужен ООП, при этом не писали огромных программ. Вот сейчас на столе платка размером с ATX материнку - 4 слейва на spi с опросом каждые 20 мС, архив и часы на i2c, 1-провод ключи на одном юарте и модбас на втором юарте. Остальные ноги забиты дискретными входами-выходами. А еще клиент желает логику работы на все случаи жизни. Без ООП это написать можно. Но с ООП ты долго стартуешь, зато быстро едешь (когда готовы классы - функционал перестраивается за пол часа). А с голым С поменять что-то надо неделю мозги сушить. Имел удовольствие такое наблюдать.