@evpartykolovratt  -- в @supapro

Если вы проектируете, что класс запрашивает список пользователей у виртуального хранилища, после чего кодирует его в JSON, вы заложили ошибку в проектировании. Правильный ответ - запросить у виртуального хранилища список пользователей сразу кодированным в JSON

Проблема  с nanomsg следующая:
Я в качестве пробы создаю сокет типа BUS, и делаю
for(int i=0;i<10;i++)
nn_send(...,"test").
Принимающая сторона получает одно сообщение из десяти.
Если добавить после отправки sleep(1ms), то все ок.
Учитывая, что zeromq/nanomsg заявляют высокую скорость отправки (200к+ сообщений в секунду), вопрос - как корректно отправлять большие партии сообщений?

template<class T...>
struct Returns{
  virtual void Execute(std::function<void(T...)>) = 0;
}

class Something : Returns<int>
{
}

но вызывающая сторона должна знать что у тебя там ожидается

ну или visitor в помощь

Там наверняка нет никаких секретов, ты просто отправляешь сообщение, оно отправляется.
Всё.

Понятий "большие партии сообщений" в месседжингах нет вообще. Ты можешь делать транзакции, и в рамках их отправлять сообщения , тогда они отправятся все, либо ни одного. Но не знаю, поддерживает ли ZeroMQ их.

А "больших партий" нет в природе, каждое сообщение посылается отдельно и индивидуально и там нет никаких особых сектеров, ты просто должен корректно работать по его API, и всё.  Так что ищи ошибки в твоей программе.

Ок, тоже так думаю. спасибо

template<class T...>
struct Returns{
  virtual void Execute(std::function<void(T...)>) = 0;
}

class Something : Returns<int>
{
}

Это никак не поможет

Если всё известно на этапе компиляции, то можно использовать статический полиморфизм на шаблонах

@blackleitus я тебе отвечал между прочим, что никак.
Всё руками проверять надо.

Подскажите пожалуйста, async функции в boost::asio работают в несколько потоков?

Почему  это ошибка?

(size_t)-1 + 1

Крайне сомнительное утверждение (и явно нарушающее SRP). Завтра ему захочется в XML или в протобуф. И что тогда делать?

Завтра у него за интерфейсом будут данные уже в JSON и он будет их пересериализовывать

Расширить формат выходного кодирования в 10 раз проще, чем упрощать избыточные требования

Зачем? Получение данных и их сериализация - это разные логические действия. И совершенно логично их разделить

Если вы написали encode_json(interface->users()) вы поставили избыточное требование за interface вида "отдать что-то итерируемое про users"

Единственное, как вы используете итерируемость, это кодирование в json

Я могу написать interface->users().serializeToJson(), например. И не накладывать никаких требований на итерируемость результата users()