oleg110592 писал(а):off не для холивара:
Почему Си - хорошо, а Си++ - плохо http://www.codenet.ru/progr/cpp/c-vs-cpp/
Да уж, Ваня Жуков расставил-таки точки над i в своей версии письма на деревню дедушке...ArtDen писал(а):Более аргументированной статьи по поводу C vs C++ я не встречал
Таки да. Но дело в том, что (к счастью) Tiny13 на сегодняшний день не единственный процессор (и даже не самый мощный), к тому же далеко не все программы укладываются в килобайт кода, а крайне ценное мнение Вани высказано о языке в целом безотносительно области его применения. И опубликовано письмецо отнюдь не в разделе "Программировуем Tiny13", а, заметьте, "Языки программирования". Здесь весьма уместно мнение профессора Преображенского по аналогичному поводу:oleg110592 писал(а):Имхо, применительно для AVR Ваня Жуков прав. Писать на Си++ для тини13/26/2313 вряд ли кто будет
Да и вообще в качестве авторитетов в части программирования лучше ссылаться на Дейкстру, Вирта или Кнута, как-то весомее получается. Каждый должен заниматься своим делом:вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие-то советы космического масштаба и космической же глупости
Высечь и впрямь не мешало бы... Так, для порядку.Ванька покривил рот, потер своим черным кулаком глаза и всхлипнул.
"Я буду тебе табак тереть, -- продолжал он, -- богу молиться, а если что, то секи меня, как Сидорову козу. А ежели думаешь, должности мне нету, то я Христа ради попрошусь к приказчику сапоги чистить, али заместо Федьки в подпаски пойду."
Да как-то это:Goldsmith писал(а): Да и вообще в качестве авторитетов в части программирования лучше ссылаться на Дейкстру, Вирта или Кнута, как-то весомее получается. Каждый должен заниматься своим делом:
не вяжется с этим:ArtDen писал(а): 1. Код проще читается. Не надо напрягать мозги при виде RST_PORT &= ~RST_PINMASK;. Выражение RST_Pin::Off(); гораздо понятнее.
2. Нереально допустить такое ошибки как RST_PORT &= RST_PINMASK;
С каких это пор знание ассемблера обязательно для программирования на МК?
Дейкстра многократно предостерегал от попыток превратить разработку программ в некий тривиальный процесс; по его мнению, программирование, в сути своей — чрезвычайно сложная научная и инженерная деятельность, и никакие новые методы и инструменты не смогут кардинально изменить это положение — они лишь освобождают программиста от части рутинной работы. Попытки же превратить программирование в простое занятие, доступное каждому, обречены на провал.
Так, всё таки... решение не идеально... отвергаем???Goldsmith писал(а): Отвергать решение на основании того, что некто тиснул невнятную статеечку в интернетах по предмету, в котором сам толком не разобрался и потому напрочь отрицает, крайне неконструктивно.
Предлагаемое решение не идеально, но вовсе не по причинам, указанным в письме Вани Жукова Константину Макарычу.
И толку будет больше, чем от Меги на С++...oleg110592 писал(а): а по мнению профи, на этом форуме и не только на этом, вместо Mega надо применять ARM.
Тут вовсе не в жире дело. Языки общего назначения (как С и С++) создаются для решения определенных классов задач, а не под конкретные микросхемы.oleg110592 писал(а):Получается С++ придется применять на жирных Mega (особенно если использовать STL и исключения)
Я думаю, каждый должен решить это для себя сам.HHIMERA писал(а):Так, всё таки... решение не идеально... отвергаем???
Код: Выделить всё
typedef Pin<'B', 0, 'L'> LED1Pin;
typedef Pin<'B', 1, 'H'> LED2Pin; // 'H' можно не писать: Pin<'B', 1>
Угу... видать не все очки носят... не видят просто...Опрос, проведенный Embedded.com, показал, что 68% респондентов используют для разработки встроенного ПО язык С. По какой причине они предпочитают C, а не C++? Частично это объясняется доступностью инструментальных средств. Но помимо этого многие разработчики даже не подозревают, какие возможности открывает перед ними объектно-ориентированный подход.
Вот только "Бюро медвежьих услуг" и не хватало...Подчас репутация C++ страдает из-за того, что он услужливо выполняет за вас некоторые весьма дорогостоящие операции (например. передачу громоздких объектов по значению). Есть способы надежно защититься от этой непрошенной помощи, например, объявив закрытый конструктор копирования для таких классов. Аналогично можно защититься от возврата объекта по значению.
Вообще смахивает на примитивный маркетинг... типа "Тогда мы идём к вам!"(С)...Резюме автора: программисты используют C++ для встроенных разработок намного реже, чем следовало бы, причем это связано не с объективными недостатками языка и/или компилятора, а скорее с незнанием и склонностью верить ничем не подтвержденным слухам.
Код: Выделить всё
typedef Pin<'B', 0> InpPin;
InpPin::ConfInPulledUp(); // вход с подтяжкой к +
bool pin_value = InpPin::Signaled();
Код: Выделить всё
typedef Pin<'B', 1, 'L'> LED1Pin;
LED1Pin::ConfOut();
LED1Pin::On();
bool pin_out_value = LED1Pin::Latched(); // читаем выходное состояние пина
1) Ну, если точнее, то, в худшем случае, четыре строчки!ArtDen писал(а):1. Нога определяется только в одном месте (1 строка). На си ради этого надо писать три строки:
2. Меньше вероятность допустить ошибки перепутав порты или биты
3. Лучшая читаемость
4. Проще переносить код между аппаратными платформами
Код: Выделить всё
#define LED1 B, 1
#define LED2 B, 2
void main()
{
char a;
PIN_INIT_AS_INPUT(LED1);
PIN_PULLUP_ON(LED1);
a = PIN_GET(LED1);
PIN_PULLUP_OFF(LED1);
PIN_INIT_AS_OUTPUT(LED1);
PIN_INIT_AS_OUTPUT(LED2);
PIN_CLR(LED1);
PIN_CLR(LED2);
while (1)
{
PIN_NEG(LED1);
PIN_NEG(LED2);
}
}
Код: Выделить всё
void main()
{
char a;
DDRB &= ~(1 << (1));
PORTB |= (1 << (1));
a = PINB & (1 << (1));
PORTB &= ~(1 << (1));
DDRB |= (1 << (1));
DDRB |= (1 << (2));
PORTB &= ~(1 << (1));
PORTB &= ~(1 << (2));
while (1)
{
PORTB ^= (1 << (1));
PORTB ^= (1 << (2));
}
}