Всех Остапов этого треда понесло

Д'Артнаньян тоже определился :) А говорил, «не особенный».

Скатить тред к глобальным синглтонам - пошлятина. Давайте сразу о анальном сексе

Две рюмочки этому господину.

Все советы чисто по опыту или есть какие-нибудь хорошие источники по практическому проектированию?

Если брать qt то там все сигналы на сколько я знаю в главном потоке обрабатываются.

можно через потоки сигналы и слоты подключать с их данными
но тут можно и без потоков - получил данные, обработал, вывел в лог, элементарно же все

Вы еще раз перечитайте то, что мной было написано. Там простой вариант вообще не требует никаких нитей. А если нити потребуются, то потребуются и очереди сообщений. Которых в стандартной библиотеке нет. От слова вообще. И судя по вопросам ТС, thread safe event queue он не осилит.

Поэтому таки да, проще взять готовую библиотеку. SObjectizer при этом будет далеко не худшим выбором.

И судя по вопросам ТС, thread safe event queue он не осилит.
SObjectizer при этом будет далеко не худшим выбором.

ой вей, какой классический пример деления на 0.

Очереди не осилит, а либу, у которой хеловорлд 100500 строк осилит.

Давайте без давайте :) Скатить тред к вашим перверсиям — это очевидное ненужно.

SObjectizer при этом будет далеко не худшим выбором

Если оп без понятия про кокнуренси-примитивы — то монопенисуально :) Лучше сначала так или иначе набраться понятий :) Агностический подход тут не работает.

Давайте сразу о анальном сексе

Две рюмочки этому господину.

No comments.

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

И goto работало, и Big Kernel Lock работал и еще очень много очень плохих вещей. Почему такой подход хуже для тестов, я уже объяснял. Но мне уже в одном треде обьяснили что настоящие С++ программисты тестов не пишут ибо они заставляют код тормозить.

В современных проектах адекватные программисты давно перешли на DI.

Off-topic

Шел 2016 год. IBM активно демонстрирует своего Watsan'а, NASA регистрирует астероиды проходящие в ~1.2кк км от нашей родной планеты, ученые разрабатывают новые типы антибиотиков и наносят на карты геномы гренландских китов. В это время в России происходят нехилые страсти. Весь ЛОР обсуждает нужность singleton'а в C++.

настоящие С++ программисты тестов не пишут ибо они заставляют код тормозить.

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

В современных проектах адекватные программисты давно перешли на DI.

Если ты имел ввиду D, то те несколько адекватных добровольцев, которые его пробовали, уже вернулись на С++ (взять тот же OpenMW. Осталась только кучка маргиналов.

В современных проектах адекватные программисты давно перешли на DI.

Если ты имел ввиду D

Он имел в виду Dependency Injection. Правда, почему-то не привел пример проектов на Си++, которые на него перешли.

Он имел в виду Dependency Injection.

А, так его еще не отпустило.

Правда, почему-то не привел пример проектов на Си++, которые на него перешли.

Вероятно он имел ввиду себя лично.

Правда, почему-то не привел пример проектов на Си++, которые на него перешли.

Почему-почему... для интриги же.

Если оп без понятия про кокнуренси-примитивы — то монопенисуально :)

Ну, если вообще без понятия, то да. А если есть общее представление о потоке и очереди сообщений, то этого уже достаточно: можно будет обойтись std::thread из стандартной библиотеки C++ и очередями сообщений (mchain-ами) из SO-5. Может больше и не потребуется.

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

Ними никто не ограничивается. Но похоже unit тесты настоящим джедаям не нужны, они могут запросто запускать весь кластер для интеграционного тестирования на каждый коммит.

Если ты имел ввиду D

Не имел ввиду, а именно Dependency Injection. Возможно ты спутал с большинством контингента ЛОРа, которые любят влететь в тред и завопить «те кто пишут на цацеле молоды, а все остальные - школота». Я говорю о практиках программирования

Ну в плюсах куча легаси, часто в умах программистов. И да, мы используем DI, чему очень рады

Dependency Injection

Рано, сначала нужно осилить синглтоны. Этапы развития пропускать не получится.

Ну разве что так подходить к вопросу... Но их можно осилить за 5 мин

ну так потрать эти 5 минут, а то ниосилил и чота тут выступаешь.

мы используем DI, чему очень рады

Кто «вы», на чем вы программируете? Если на Си++ и фремворк DI открытый, хотелось бы знать его название.

Но их можно осилить за 5 мин

Ага, и потом DI минут за 10. Если всё так просто, откуда берётся столько говнокода?

1) Google

2) C++

3) Мы - без фреймворка, просто DI без IoC. А так https://github.com/ybainier/Hypodermic, https://github.com/google/fruit, https://github.com/boost-experimental/di, http://wallaroolib.sourceforge.net/

Не, я имел ввиду 3 минуты чтобы понять концепцию, 1 минуту чтобы обьяснить почему это плохо и 1 минуту чтобы забыть навсегда.

1 минуту чтобы забыть навсегда.

Тогда ты не сможешь объяснить, почему DI хорошо.

Ними никто не ограничивается. Но похоже unit тесты настоящим джедаям не нужны, они могут запросто запускать весь кластер для интеграционного тестирования на каждый коммит.

Внезапно, у нас так и есть. Для этого есть отдельные сервера, которые «на каждый коммит» автоматом делают сборки, запускают нужные сервисы и прогоняют тесты. Причем под разными платформами. И в случае чего сразу приходит сообщение, что что-то отвалилось после коммита. Да, может это лишний раз нагружает железо, но зачем его жалеть? И да, у нас тестами обязательно прикрывается каждая функция и методы, кроме приватных. Причем тестируется все - от обрывов соединения, мусора при передаче, испорченных файлов и до гуевых морд и печати на принтер (PDF-принтер ес-но). Если у вас не так, то зачем ты пытаешься на эту тему так напирать?

Я веду к тому что оба вида тестов нужны и хороши. Юнит тесты сложно написать без mock классов. Конечно можно попробовать обойтись injection через шаблоны, но это не масштабируемо для сложных систем.

программисты давно перешли на DI.

Звучит как cargo cult programming

Ну польза есть очевидная

Глобальные синглоты это конечно хорошо, но только тогда зависимости есть в классе, т.е в классе работы с перифирей вызывать обработчик - метод другого класса. Не думаю, что это прям такая редкая проблема..)

Синглтон нужен тогда и тоьлко тогда, когда нужно подчеркнуть(и гарантировать), что объект может быть только в одном экземпляре. (Типичный пример - logger.)

Если тебе надо просто посвязывать классы то самый простой вариант - хранить ссылки на эти объекты в твоем классе-композиции.

https://github.com/boost-experimental/di

Мама, вроди меня обратно... от такой класс-диаграмы даже не хочется дальше смотреть на это :D (или что это у них там за народные творчества) :)

struct ctor_inject_traits_no_limits {
  /*<<constructor with 20 parameters>>*/
  using boost_di_inject__ =
      di::inject<int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int>;

  ctor_inject_traits_no_limits(int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int,
                               int) {}
};

Нехилые такие примеры :D

Hypodermic я смотрел. DI - это же просто конфигурация графа объектов в программе, зачем для этого байда вроде Hypodermic - я не понял.

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

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

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

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

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

сказал vertexua и пошёл флудить про IoC )

Ну и чем перегрузка всех возможных операторов доступа к глобальной переменной с прописыванием среди них инициализации при первом обращении, ну или куда ты хотел ее пихнуть, лучше чем написать одно слово «singleton»? Маргиналы опять рекламируют всем свои любимые грабли?