Comments 5
1) У вас не написаны ограничения Qt4, но используется строковое связывание между сгенерированным кодом и классами библиотеки. Связывание по указателям куда быстрее и надёжнее, а потокобезопасность не страдает. Зачем старый стиль?

2) Я понимаю, сигналы-слоты — это круто, но не было мысли прокручивать сообщения не через дорогую систему сигналов, а через более дешёвый QEvent? Получить доступ к системе эвентов можно даже из шаблонного класса, ведь макрос Q_OBJECT не является обязательным для наследников QObject, а без него всё отлично собирается. Ограничения остаются только на невозможность определить новые сигналы-слоты-проперти в классе, старыми можно пользоваться на все 100%.

3) В коде достаточно крепкая мешанина std и Qt классов. Вы уж определитесь хотя бы в примерах, у вас std::string или QString?

Добрый день.


  1. Ограничений на Qt4 нет. Но я до конца не определился, в каком случае примеры будут нагляднее. И решил оставить стиль Qt4. По поводу связываний по указателям вы абсолютно правы;
  2. Если честно, не задумывался про QEvent. Не было опыта встраивания своих событий в event loop. Плюс это нужно уметь делать из другого потока. Сигналы-слоты в этом плане уже умеют все, что нужно. В остальном я с вами согласен. Я бы с удовольствием посмотрел, как это будет работать через QEvent'ы. Но пока нет времени этим заниматься. Поэтому пока что сигналы-слоты;
  3. Я прошу прощения за мешанину. В ряде примерах я действительно дописал в ряде мест std::cout вместо QDebug для наглядности.
    Но поскольку примеры клиентского кода написаны на Qt, а вся реализация QgRPC на C++ без Qt, то до конца избавится от мешанины в статье, увы, не получится.
На счет «дорогой системы сигналов» я не соглашусь с комментатором выше — затраты в районе 200 инструкций на emit по сравнению с передачей данных по сети — вообще не соизмеримы. Если вы не делаете миллионы emit-ов в секунду, то сомневаюсь что система сигналов-слотов — узкое место. Так что хорошо что не ивентах, имхо, с ними было бы менее удобно.

С остальными замечаниями согласен)
Обычно сетевой стек имеет стремление к бесконечному расширению. Пока его размер мал, СС действительно очень удобны. Но с ростом стека и производительность, и удобство сигналов серьёзно просаживаются. У меня сетевой стек изначально был большим (>500 сообщений), так что простая попытка внедрения у меня вызывала вот такую реакцию. А так сообщение делаешь наследником QEvent, бросаешь его в очередь сообщений и пусть его ловят все заинтересованные. То же с обратным процессом.

Но тут, действительно, уже вкусовщина, тем более, что не у всех стек такой большой.
Eto vse silno — no moget bit uge imeutsa standartnie reshenia dla QT? Eshe mogno li sravnit eto reshenie s QT + RESRFull API?
Only those users with full accounts are able to leave comments. Log in, please.