Форум РадиоКот

ArtDen писал(а): И как это относится к вопросу библиотеки C++ для работы с портами AVR?!

Недавно столкнулся с C++ - библиотекой для работы с портами ввода/вывода на STM32. Очень удобная штука.

То, что можно по ошибке написать

И можно всё-таки пояснить зачем нужно знать ассемблер, чтобы программировать на МК?

YS писал(а):В частности, чтобы понимать, почему C++ под такие мелкие системы неприменим.

Можно чем-нибудь подтвердить эту мысль?

YS писал(а):Я ведь уже приводил дизассемблированный код для ООП-варианта и чистого Си)

typedef Pins<'B', 0x1 | 0x2> LED1AND2Pins;
....
LED1AND2Pins::ConfOut();
for (;;)
{
	LED1AND2Pins::Cpl();
	_delay_ms(500); // Делаем задержку
}

подтверждения ненужности C++ для МК так и не получил

|Ассемблерный код тогда станет полностью аналогичный с Pure-C

YS писал(а):Мне за Вас погуглить сравнение эффективности Wiring (упрощенный C++ для AVR) и pure C?

YS писал(а):

|Ассемблерный код тогда станет полностью аналогичный с Pure-C

Уверены?

А разве разговор идёт о Wiring?

YS писал(а):Я ведь даже в скобках на всякий случай указал, что такое Wiring. Кстати компилятор там - тот же GCC, так что сравнение корректно.

YS писал(а):Только не говорите, что использующий плюсовые фичи остановится на их применении к портам.

YS писал(а):Смысл дефайнов в том, что абсолютное большинство кода, ими описанного, должно выполниться препроцессором либо оптимизатором и не войти в результирующий бинарник. А вот ООП-фишки такого преимущества лишены.

ArtDen писал(а): В общем, никто так и не понял в чём профит такого подхода

PS: подтверждения ненужности C++ для МК так и не получил

ArtDen писал(а): Не совсем понял

Тоже не понял.

Эта же тема про библиотеку для работы с портами ввода/вывода для AVR на C++.

Loop:
sbi PINx,LED
rjmp LOOP

Не вижу логической связи между утверждениями "Wiring генерирует тормозной код" и "Компилятор C++ генерирует тормозной код"

Не совсем понял

Тоже не понял. Код (бинарный) выполняется процессором. Если имелся ввиду исходный код, то он не выполняется ни оптимизатором, не препроцессором

a=((2+3)+4*8) | (1<<2);

a=37;

HHIMERA писал(а):2ArtDen
Если вы совсем не в теме, то и не стоит так нервничать...

HHIMERA писал(а):И если у С++ есть неоспоримые преимущества, так покажите их...

HHIMERA писал(а):И любовь/ненависть тут совсем не при чём... есть такие понятия как "целесообразность" и "наилучший/быстрый результат"...

ILYAUL писал(а):Так Вы нам не доказали чем она лучше традиционного подхода.

YS писал(а): Тогда я Вас очень удивлю. Если Вы напишете

Код: Выделить всё

a=((2+3)+4*8) | (1<<2);

то компилятор на этапе разбора (!) вычислит значение (((2+3)+4*8) | (1<<2)), и в код пойдет

Код: Выделить всё

a=37;

Да-да, компилятор выполнит написанный Вами код. А еще он может оптимизировать повторяющиеся части выражений. И при написании макросов вовсю этим пользуются. Макрос - не переменная. Он подставляется в исходник в виде строки.

YS писал(а): компилятор на этапе разбора (!) вычислит значение (((2+3)+4*8) | (1<<2)),

YS писал(а): И при написании макросов вовсю этим пользуются. Макрос - не переменная. Он подставляется в исходник в виде строки.

ArtDen писал(а): Повторюсь:
1. Нога определяется только в одном месте (1 строка). На си ради этого надо писать три строки:
#define XXXXX_PORT PORTA
#define XXXXX_DIR DDRA
#define XXXXX_BIT 0x01

2. Меньше вероятность допустить ошибки перепутав порты или биты

3. Лучшая читаемость

4. Проще переносить код между аппаратными платформами

HHIMERA писал(а):

ArtDen писал(а): 3. Лучшая читаемость

Надуманно... для этого есть абстракция...

HHIMERA писал(а):Надуманно... С++ не пользуюсь, а трудностей с переносом не ощущаю... "Что я не так делаю?" (С)

ArtDen писал(а):Ещё раз повторюсь: речь идёт не про С++, а про библиотеку работы с портами. Вопросы по С/С++ обсуждаются в соседней теме.