[Serega Doc 0]

Спасибо за рекомендации.

inline я активно использую в header файле.

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

 

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

Еще раз спасибо.

 

[xvr 12]

ReAl

зайдите на любой форум программеров - война с языком идёт вечно. причём чуть ли не с базовыми конструкциями.

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

 

[alexvok 0]

Посоветуйте пажалуйста книгу

С++ с примерами для AVR

[demiurg_spb 0]

Посоветуйте пажалуйста книгу

С++ с примерами для AVR

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

[neiver 0]

Примеры есть у меня, есть и свой подход к программированию для систем с сильно ограниченными ресурсами на С++(на примере AVR).

Будет свободное время - напишу статейку по этой теме (если будут желающие её читать :) ).

А так вкратце могу сказать, что программы на С++ получаются компактнее, быстрее и легче читаются аналогичных программ на Си.

[777777 0]

А так вкратце могу сказать, что программы на С++ получаются компактнее, быстрее и легче читаются аналогичных программ на Си.

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

[MrYuran 16]

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

Да хоть какие угодно.

Порт, например, чем вам не класс?

УАРТ?

АЦП?

Таймеры?

Есть физические данные, есть объекты в адресном пространстве, есть методы, работающие с этими данными и объектами.

Почему бы не соединить вместе?

 

Adc->Init();

Adc->StartConversion();

...

Uadc = Adc->GetResult();

[777777 0]

Да хоть какие угодно.

Порт, например, чем вам не класс?

УАРТ?

АЦП?

Таймеры?

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

Есть физические данные, есть объекты в адресном пространстве, есть методы, работающие с этими данными и объектами.

Почему бы не соединить вместе?

 

Adc->Init();

Adc->StartConversion();

...

Uadc = Adc->GetResult();

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

Изменено 20 августа, 2010 пользователем 777777

[MrYuran 16]

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

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

 

Нет, это не классы. Это объекты, существующие в одном экземпляре.

Ни разу не видел контроллер с одним портом :)

Вот немного выше был пример, как можно очень удобно представить разрозненные пины разных портов как один обычный порт.

Лучшего примера, я думаю, не найти.

Ну и в конце концов, чуть приподнявшись и отвязавшись от железа, имеем обычную абстрактную программу, в которой можно применять все тонкости и возможности с++.

Я для пробы делал класс цифровых фильтров - очень удобно.

В одном объекте сосредоточен буфер с дискретными отсчётами, методы и выходное значение.

Опять же, можно сделать несколько разных фильтров с разными параметрами и характеристиками.

 

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

Однозначно, плюсы рулят.

[dxp 34]

Нет, это не классы. Это объекты, существующие в одном экземпляре.

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

 

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

[MrYuran 16]

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

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

[ReAl 0]

Ну вот как раз сегодняшний пример.

ATmega48. Программа сравнительно древняя на С (и нет желания её переписывать начисто, но что-то новое даже такого объёма будет сразу писаться на С++).

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

На С++ все эти функции изначально объединяются в класс-«драйвер режима» и потом хоть обдобавляйся в этом классе приватных полей.

Казалось бы, между

SomeModeOn();
SomeModeOff();

someMode.On();
someMode.Off();

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

 

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

[MrYuran 16]

С++ с примерами для AVR

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

:rolleyes:

Я уже название придумал.

"С++ в микроконтроллерах. Почему бы и нет?"

Экспортный вариант:

"С++ for microcontrollers. Why no?"

 

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

То есть, дополнительный организующий момент.

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

 

Спор "плюсы против бесплюсов" считаю таким же контрпродуктивным, как "асм против си".

Си вобрал в себя основные на тот момент методики структурирования ассемблера.

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

Точно так же, есть надстройки над с, дающие дополнительную абстракцию, например, компонентно-ориентированный диалект Nes-C, на котором написана TinyOS

Изменено 23 августа, 2010 пользователем MrYuran

[neiver 0]

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

[777777 0]

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

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

class CIdle
{
CIdle()
    {
    sei();
    while(1)
        {}
    }
}

Применение

main()
    {
    // инициализация периферии
    ...
    // дальше работают только прерывания
    CIdle idle;
    }

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

 

 

"С++ в микроконтроллерах. Почему бы и нет?"

Экспортный вариант:

"С++ for microcontrollers. Why no?"

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

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

То есть, дополнительный организующий момент.

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