LINUX.ORG.RU

История изменений

Исправление next_time, (текущая версия) :

Условно говоря, делать так:

void read(Param params)
{ 
  pair<Periph*, DataParser*> x = builder(params);
  x.second->set_periph(x.first);
  to_new_thread(x.first);
  x.first->start();
  x.second->exec();
}

где Periph и DataParser — абстрактные классы

В реальности тот же код будет выглядеть похожим скорее на что-то вроде:

  void read(Param params)
{ 
  DataParser* x = builder(params);
  x->exec();
}

т.е., указатель на периферию сделать членом класса DataParser и новый поток запускать уже оттуда.

а запись в логи лучше ф-ями сделать

почему именно так? а потому, что одному потомку класса DataParser, в общем случае, может соответствовать несколько устройств — если вы их подключите, соответственно, очередь сообщений лучше сделать раздельной, уникальной для каждой пары Periph - DataParser

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

Исходная версия next_time, :

Глобальные переменные и, тем более, синглетоны, здесь не нужны

Условно говоря, делать так:

void read(Param params)
{ 
  pair<Periph*, DataParser*> x = builder(params);
  x.second->set_periph(x.first);
  to_new_thread(x.first);
  x.first->start();
  x.second->exec();
}

где Periph и DataParser — абстрактные классы

В реальности тот же код будет выглядить скорее что-то вроде:

  void read(Param params)
{ 
  DataParser* x = builder(params);
  x->exec();
}

т.е., указатель на периферию сделать членом класса DataParser и новый поток запускать уже оттуда.

а запись в логи лучше ф-ями сделать

почему именно так? а потому, что одному потомку класса DataParser, в общем случае, может соответствовать несколько устройств — если вы их подключите, соответственно, очередь сообщений лучше сделать раздельной, уникальной для каждой пары Periph - DataParser

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