Применение С++

[Variant99]

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

[mike-y-k]

А более системно подойти и попользоваться книгами?
Бьёрн Страуструп
Язык программирования С++
Справочное руководство по языку программирования С++ с комментариями
Программирование: принципы и практика использования C++

Можно купить и классически с карандашом и закладками, можно в электронном формате…
Потребность появится при росте объема систем, когда станет проще работать с объектами и классами, а не с переменными и функциями…

[Signalshik2]

В микроконтроллерах объекты не нужны. C достаточно для них.

[akegor]

В микроконтроллерах объекты не нужны.

В Тиньках - да. Опрометчивость заявления растет с ростом сложности задачи, решаемой погромистом.

[Signalshik2]

Да и в Мегах тоже.

[NewWriter]

Прочли - это хорошо Осталось теперь понять, что объектно-ориентированное программирование в С++, в отличие от процедурного (фукнционального) в обычном Си, оперирует понятием "объект программирования", у которого есть свойства и методы взаимодействия с ним.
Если раньше в процедурном Си вы просто писали функции и создавали переменные, которые описывали просто какие-то действия, без привязки ни к чему конкретному, то в объектно-ориентированном С++ как правило не существует просто отдельных оторванных фукнций. Вместо этого они привязаны к конкретным объектам и отражают то, что объект может сам делать, или наоборот, что с объектом можно сделать извне.

Вернее, применительно к микроконтроллерам, часть функций может быть всё-же оторвана от объектов.
Вызвать метод без создания объекта можно, написав в классе публичный static-метод, и тогда его вызов будет выглядеть как MyClass::MyMetod();

Если вы не поняли, зачем нужны все эти объекты в микроконтроллере, то загляните не с точки зрения работы с периферией МК, а с точки зрения того, какую работу выполняет микроконтроллер в качестве управляющего элемента какого-то устройства. То есть, смотрите шире и выше. Не глубже внутрь МК, а именно выше, поверх МК.
Вот например у вас есть объект - электрочайник. У него есть свойства - объем воды в нем и мощность нагревателя. И есть метод - греть воду. Вооот. То есть, теперь пишите класс "чайник", внутри него privat-свойства "объем" и "мощность нагревателя". И public-метод "греть воду".

class Teapot {
private:
	int volume;		// свойство "объем"
	int power;		// свойство "мощность"
public:
	/* конструктор при создании объекта
	 * присваивает переменным значения */
	Teapot(int volume, int power)
	{
		this-›power = power;
		this-›volume = volume;
	}

	/* метод "греть воду" */
	void HeatWater(int action)
	{
		if(action == 1)
			HEAT_ON();
		else
			HEAT_OFF();
	}
};

int main(void)
{
/* создали объект "мой чайник" класса "чайник", 3 литра, 2,1 кВт */
	Teapot MyTeapot(3000, 2100);  

/* сказали "моему чайнику" - "нагреть воду" */
	MyTeapot.HeatWater(1); 
}

В этом примере, правда, свойства volume и power не используются.
Ну вот, вы уже получили объектно-ориентированный метод программирования, когда у вас есть конкретный объект, а не просто функции.

В микроконтроллерах объекты не нужны. C достаточно для них.

В мелких мелкоконтролерах в принципе то и не нужны. Хотя, Ардуина на тех самых мелких использует как раз С/С++ язык! Правда, я не очень то смотрел, как у них там реализовано, но судя по синтаксису, используют как раз объекты. Хотя, мыслят они по-прежнему, на уровне процедурного программирования.

[Variant99]

Ну хорошо буду смотреть выше. Создали объект "мой чайник" и включили нагрев воды. Как то многовато действий. А нельзя просто включить чайник без того чтобы создавать этот чайник?
И еще зачем нужны гетеры и сетеры и почему именно через них надо делать? Разве нельзя попростому?

[mike-y-k]

Variant99, Вам на пальцах при минимуме показали принципы ООП…
Если про зачем - таки если чайник перерастет в объект с сотней переменных, количество разработчиков станет больше 1, потребуется использовать и вести общие библиотеки методов, появиться необходимость высокоуровневых абстракций,…
Тут вот работа с объектами и найдет свое место…
А если не абстрагироваться от чайника, то там на ассемблере написать все можно…
У меня есть хороший знакомый, который такие мелочи пишет просто в шестнадцатеричном редакторе - профдеформация человека, занятого большую часть времени анализом дампов прошивок и восстановлением из них алгоритмов…

[dgrishin]

А нельзя просто включить чайник без того чтобы создавать этот чайник?

Конечно можно. Но в ООП объект это сущьность, с которой можно выполнять действия и которая обладает определеннымси свойствами и все это "в одном флаконе"
Например ваш чайник также може иметь свойства - количество воды в нем и температура воды. Вы в функции включения нагрева можете проверяит эти свойства чайника вызовом дополнительных методов. Если воды мало или температура близка с 100градусам то включать его не нужно - именно эти действия обычно делают люди.
Это уже не процедурно-ориентированное программирование а "чайникоописание" - новый уровень абстракции.

[NewWriter]

[пока я писал, dgrishin опередил и уже написал как раз про температуру]

Конечно можно и не создавать объект, а просто в классе Teapot написать публичный статический метод вот так:
static void HeatWater(int action) { ... }
и тогда можно его вызывать без создания объекта:
Teapot::HeatWater(1);
static-методы и static-поля (переменные) являются общими для всех созданных экземпляров класса (т.е. объектов).

Коль уж вы решили писать на С++, то куда деваться, придется мыслить объектно. Хотя, С++ ардуинщикам не мешает мыслить по-прежнему процедурно, а классы и объекты использовать просто как синтаксис группировки по принадлежности.

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

class Teapot {
private:
	int temperature;	// температура воды
public:
	/* получение значения температуры воды */
	int getTemperature()
	{
		return temperature;
	}

метод getTemperature() является геттером и получает значение поля temperature. Вне этого класса никак невозможно изменить поле temperature, для внешних запросов это поле закрыто на запись, возможно только его чтение:
int t = MyTeapot.getTemperature();
Правда, в практической реализации надо прописать, каким образом поле temperature вообще получает реальное значение. Например, в том же геттере прописать чтение измерителя текущей температуры.

Пример сеттера:

	void setVolume(int volume)
	{
		if(volume › 4000) volume = 4000;
		if(volume ‹ 1000) volume = 1000;
		this-›volume = volume;
	}

он ограничивает максимальный и минимальный устанавливаемый объем воды, и не позволит задать например 50000 (50 литров).

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

На обчном Си подобное так же можно реализовать, написав отдельный файл исходника teapot.c, в нем записать переменную static int temperarure; и написать фукнцию
int Teapot_GetTemperature(void) { return temperature }
и перенести ее прототип в файл интерфейса модуля teapot.h
Получится то же самое. Разве что в Си хуже обстоит дело с областями видимости и наследованием, механизм сокрытия работает лишь частично.
В принципе, в С++ заложено то же самое, что и в Си, только это сделано более строго и сразу даны продвинутые инструменты для реализации безопасных "капсульных" методов.