ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
20 июля
530606 Топик полностью
VVB (15.07.2014 07:51 - 07:58, просмотров: 93) ответил Ациль Шифер на Не. структура{длина, пре1, пер2, црц}, а отдать указатель.
Ну тут ньюансы. Требуемые для ИВЛ физические данные я хочу в виде классов сделать. На основе некоторых базовых классов (например, базовый класс с интерфейсом для получения данных из CAN, базовый класс с интерфейсом для получения из UART и т.д.). Такой подход даст возможность "зарегистрировать" обработчик принятого пакета CAN, относящийся к требуемым данным, в объекте "контроллер CAN", что даст возможность автоматического вызова нужного обработчика при приходе пакета CAN. То есть имею: 1. класс "поток", в котором будет находится обработчик пакета CAN, и данные, представляющие сам поток. 2. объект класса "контроллер CAN", который ничего не знает о информации в шине и тупо вызывает зарегистрированные обработчики. Пусть сами классы разбираются с данными внутри пакета CAN Поэтому сделать список это лишние сложности. В конструкторе режима ИВЛ (или в конструкторе промежуточного кэширующего класса) надо инициализировать указатели. Что-то типа:
class CanRx {
public:
  virtual void processID(const CAN_MSG &msg) = 0;
};

class Flow : public CanRx {
  int32_t flow;
public:
  const uint32_t ID;
  virtual void processID(const CAN_MSG &msg); /* виртуальная функция, наследуемая из базового класса CanRX. Именно она будет вызываться из контроллера CAN при приходе сообщения */
  int32_t get() const;

}

class IVLmode {
  Flow *finsp;
public:
  IVLmode(...,
    Flow *_finsp) : finsp(_finsp){}
}

где-то в коде:
Flow fInsp;
can.register(&fInsp, fInsp.ID);
IVLmode cmv(...,
  &fInsp);

для получения потока из членов класса IVLmode: finsp->get()
Как-то так. При такой архитектуре списки неактуальны. Каждый модуль делает своё дело независимо от других модулей.