Как правильно использовать существующий объект одного класса в описании другого класса?

Я учусь использовать С++ для программирования микроконтроллеров.
И не могу понять, как выстроить правильно логику программы на С++

Расскажу на конкретном примере.
Допустим, я создал класс для обработки данных поступающих с UART (последовательный порт)
Класс представляет собой кольцевой буфер и несколько методов для работы с ним.
Методы самые простые: сохранить байт в буфер, вытащить байт из буфера, проверить буфер на пустоту, очистить буфер и т.д.

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

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

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

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

0

Сообщение от reti нарушаются правила ООП. Без этого программы будут медленными, а памяти и вовсе может не хватить

ерунда, кто такое напел?

0

Сообщение от TRam_ Проверку "масла масляного" делать не обязательно, if и так принимает в качестве аргументов true/false. А ещё он принимает 0 / 1/ 10 / 25 / и прочие целые числа (среди них false это 0, остальные true)

Да, это я знаю. Мне так привычнее читать программу. Было несколько раз, когда из-за этого путался в логике при проверки нескольких условий.

0

Сообщение от reti Поэтому подумал, что существует какое-то более элегантное решение.

Более элегантное - локальная переменная в main(), а ещё лучше поле класса, экземпляр которого создан локальной переменной в main().

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

Добавлено через 4 минуты
Если создание объекта BufferUart предполагается не сразу, либо предполагается его удаление из памяти раньше завершения программы, то лучше делать ему умный указатель. Это защитит от того, что другие объекты вдруг вызовут функции уже разрушенного/ещё не созданного порта, но от обязанности почистить те объекты от указателей на этот удаляемый порт не освобождает.

0

Сообщение от Алексей1153 ерунда, кто такое напел?

А вот это уже совсем другая история и для другой ветки форума.
Но, если кратко, то во встраиваемых системах очень часто используются глобальные переменные, иногда оператор goto, достаточно редко используют проверку передаваемых в функцию переменных и прочее. Ну, может не все относится к ООП, но суть думаю, понятна.
Потому что иначе код увеличивается, а быстродействие падает.
Конечно, есть и исключения.
В любом случае, подход к написанию программ для Attiny13 и STM32H4xx должен быть разный

0

reti, goto или классы не влияют сами по себе на размер кода и производительность. Зато наличие goto или отсутствие классов - сильно быстро превращает код в протухшую лапшу, где не поможет уже никакая производительность. Такие дела

Добавлено через 1 минуту
ООП - это рекомендация, образ мышления. В Си тоже можно использовать ООП

0