Спасибо за рекомендации.
inline я активно использую в header файле.
И для данной функции это бессмысленно из-за дублирования кода.

Я в принципе тоже так думал что нет такой возможности. Но надеялся что я чего-то не ведаю.
Еще раз спасибо.

Заходил. Видел борьбу начинающих со своей безграмотностью, борьбы ПРОГРАММИСТОВ с С++ не видел

Посоветуйте пажалуйста книгу
С++ с примерами для AVR

Боюсь, что таковых не имеется...

Примеры есть у меня, есть и свой подход к программированию для систем с сильно ограниченными ресурсами на С++(на примере AVR).
Будет свободное время - напишу статейку по этой теме (если будут желающие её читать ).
А так вкратце могу сказать, что программы на С++ получаются компактнее, быстрее и легче читаются аналогичных программ на Си.

Я, в принципе, охотно верю, но тем не менее не могу придумать, какие понятия в микроконтроллерных системах можно сделать классами. Слишком уж они отличаются от обычных программ.

Да хоть какие угодно.
Порт, например, чем вам не класс?
УАРТ?
АЦП?
Таймеры?
Есть физические данные, есть объекты в адресном пространстве, есть методы, работающие с этими данными и объектами.
Почему бы не соединить вместе?

Adc->Init();
Adc->StartConversion();
...
Uadc = Adc->GetResult();

Нет, это не классы. Это объекты, существующие в одном экземпляре. (Правда, в программировании есть понятие синглтона, но это все-таки экзотика). А класс - это в некий тип данных, как int или char. Можно создавать объекты таких типов в любом колчестве, они обладают некими свойствами. Примером класса может быть окно - можно создавать множество объектов такого класаа - окон с разными свойствами - размером, типом, - вызывать их методы с целью поменять их, выполнить какое-то действие - нарисовать на нем что-то и т.п. Можно например, как я писал в соседнем посте, создать класс кнопки и использовать его для обработки нажатий на кнопки, отличать длительное и короткое нажатие, выполнять полиморфно их обработку.

Это лишь видимость С++, в реальности это ничем не лучше вызова обычных функций. А от объектно-ориентированного программирования польза будет только если пользоваться всеми его особенностями - инкапсуляцией, наследованием, полиморфизмом. А для этого нужно весь проект рассматривать как поле для взаимодействия объектов, а не просто переделать проект на С++ потому что это модная фича.

Сообщение отредактировал 777777 - Aug 20 2010, 11:18

Ну так и АЦП может быть внутренним, а может быть внешним и подключаться через дополнительный драйвер SPI или I2C. Плюс, их может быть несколько. Так что, налицо класс, несколько объектов (возможно, разных) и единая методика работы. Тут и полиморфизм, а возможно, и перегрузка методов (в зависимости от типа АЦП).


Ни разу не видел контроллер с одним портом
Вот немного выше был пример, как можно очень удобно представить разрозненные пины разных портов как один обычный порт.
Лучшего примера, я думаю, не найти.
Ну и в конце концов, чуть приподнявшись и отвязавшись от железа, имеем обычную абстрактную программу, в которой можно применять все тонкости и возможности с++.
Я для пробы делал класс цифровых фильтров - очень удобно.
В одном объекте сосредоточен буфер с дискретными отсчётами, методы и выходное значение.
Опять же, можно сделать несколько разных фильтров с разными параметрами и характеристиками.

А уж если есть экранчик (хотя бы 128х64) и менюшки-поля-окошки, то тут уж вообще разговор молчит.
Однозначно, плюсы рулят.

То, что классы нужно заводить только при возникновении необходимости во множественном (> 1) использовании объектов, - распространенный стереотип-заблуждение. Классы - это просто типы, определяемые пользователем, и использовать их имеет смысл во всех случаях, когда описание программных сущностей удобно воспринимать в виде законченных объектов, даже если такой объект в программе всего один. Классы, как типы, определяемые пользователем, позволяют программисту провести близкие аналогии между объектами реального мира и сущностями программы, что значительно облегчает процесс разработки, т.к. выводит логику программы на более высокий уровень абстракции (от низкоуровневого железа). К тому же, это обстоятельство позволяет в значительной мере формализовать процесс проектирования программы - т.е. составить проект ("рыбу") будущей программы из кубиков структурной схемы еще до написания первой строки кода.

Кстати, на том же С очень удобно заводить в структуру объекты, относящиеся к одному и тому же (по смыслу) месту программы, даже если таких структур нужна всего одна.

Да, структура - частный случай класса.

Ну вот как раз сегодняшний пример.
ATmega48. Программа сравнительно древняя на С (и нет желания её переписывать начисто, но что-то новое даже такого объёма будет сразу писаться на С++).
Дописывается кусочек функционала, понадобилось при входе в некоторый режим сохранить состояние некоторых выходов, выключаемых в этом режиме, а при выходе из режима восстановить. Ну всё понятно, заводится флаг нахождения в этом режиме (в режим может быть повторный вход, который теперь отличается тем, что сохраняь уже отключенные ножки не нужно) и буферная переменная для сохранения состояния выходов. Т.е. появляются две глобальных переменных файловой области видимости и связь между функциями через них.
На С++ все эти функции изначально объединяются в класс-«драйвер режима» и потом хоть обдобавляйся в этом классе приватных полей.
Казалось бы, между


разницы не видно, «а она есть»©

Кстати, классы, изначально предназначенные для того, чтобы иметь только один экземпляр - вполне нормальное явление.

Может, напишем сообща?

Я уже название придумал.
"С++ в микроконтроллерах. Почему бы и нет?"
Экспортный вариант:
"С++ for microcontrollers. Why no?"

У "плюсов" есть ещё один несомненный плюс. Прежде чем сломя голову что-то писать, надо сначала продумать структуру.
То есть, дополнительный организующий момент.
Кстати, данная тема именно с этого и началась - с вопроса об оптимальной структуре.

Спор "плюсы против бесплюсов" считаю таким же контрпродуктивным, как "асм против си".
Си вобрал в себя основные на тот момент методики структурирования ассемблера.
Плюсы - также включают основные методики из сишного программирования. То, что на си пишется в виде отдельного модуля, на с++ можно поместить в класс. Закрытые члены - это аналог static-функций и переменных. В общем, всё то же самое, только проще, короче, быстрее и нагляднее.
Точно так же, есть надстройки над с, дающие дополнительную абстракцию, например, компонентно-ориентированный диалект Nes-C, на котором написана TinyOS

Сообщение отредактировал MrYuran - Aug 23 2010, 09:03

Идея интересная. Я статью по этой теме пишу - никак не допишу... Времени мало. А тут книгу...

Да это явление может и нормальное, я не спорю. Хуже когда этот класс в принципе не может иметь несколько экземпляров - это уже архитектурная проблема, говорящая о том, что классу тут делать нечего. Можно например написать класс CIdle, который будет инкапсулировать в себе бесконечный цикл, имеющийся в любом контроллере:

Применение

Но этот пример попахивает онанизмом, не находите? Даже если в него навтыкать указателей на функции и заставить их вызывать по кругу, пользы от него не прибавится.



По-английски это не звучит, надо по-французски: pourquoi pas?

Да, это действительно полезно...