Есть такой (местами псевдо)код. asio::ip::udp::endpoint clientEndPoint; while(true) { char buff[4096] = {0}; size_t bytesReceived = serverSocket->receive_from(asio::buffer(buff), clientEndPoint); if (bytesReceived != 0) { auto message = message(buff); std::thread t([message]() { process(message); }); t.join(); } } Который обрабатывает входящее сообщение, откуда бы оно не пришло, адрес клиента записывает в clientEndPoint и запускает обработку сообщения в отдельном треде. Но в методе process() описан сценарий диалога - что послать обратно по этому адресу и что ожидать в ответ, с тем же receive_from под капотом. Но дело в том что сообщение которое относится к диалогу может приняться в этом куске который я скинул, а не внутри process() Как это разрешить, и какой вообще нормальный архитектурный подход к такой проблеме?

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

Вот этот совет мне нравится :)

Товарищи, всем спасибо)

запихну в тред cv, с объектами буду хранить steady_clock::now + duration.

там еще вопрос нужен ли отзыв

технически есть стандартная схемка с двумя точками отзыва на shared_ptr

в которой из очереди вообще ничего не удаляется

Есть такой (местами псевдо)код. asio::ip::udp::endpoint clientEndPoint; while(true) { char buff[4096] = {0}; size_t bytesReceived = serverSocket->receive_from(asio::buffer(buff), clientEndPoint); if (bytesReceived != 0) { auto message = message(buff); std::thread t([message]() { process(message); }); t.join(); } } Который обрабатывает входящее сообщение, откуда бы оно не пришло, адрес клиента записывает в clientEndPoint и запускает обработку сообщения в отдельном треде. Но в методе process() описан сценарий диалога - что послать обратно по этому адресу и что ожидать в ответ, с тем же receive_from под капотом. Но дело в том что сообщение которое относится к диалогу может приняться в этом куске который я скинул, а не внутри process() Как это разрешить, и какой вообще нормальный архитектурный подход к такой проблеме?

делать один receive_from, завести dialog id, по треду на запрос весело =)

Товарищи, всем спасибо)

посмотри тут есть пример реализации https://github.com/chriskohlhoff/executors

посмотри тут есть пример реализации https://github.com/chriskohlhoff/executors

это же какая-то эксперименталка для С++14

да. от автора boost.asio

делать один receive_from, завести dialog id, по треду на запрос весело =)

Ну так-то по треду на диалог. Я знаю, что это плохо, но в упор не вижу нормального способа. Если получать только из одной метода, то как мне знать что вообще делать с прилетевшим сообщением? Грубо говоря, сейчас я могу описать сценарий диалога в виде void onScenario1() { send(someRequest); receive(someResponse); send(someOtherRequest); receive(someOtherResponse); } И все это ломается если добавить многопоточность.

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

например, без синхронизирующего потока невозможно давать гарантии отзыва на цепочках вычисления A(B(C()))

это очевидно что 1 поток 1 стейт, а чейнинг нейскольких потоков означает головняк с синхронизацией что бы действие казалось атомарным

реактивность не дебилы придумали

технически есть стандартная схемка с двумя точками отзыва на shared_ptr

А что за стандартная схемка? Где бы почитать? Отзыв есть. Коллекция — это, семантически, map. На тот же ключ может быть повешен другой объект, с другим таймаутом (или вообще без него).

А что за стандартная схемка? Где бы почитать? Отзыв есть. Коллекция — это, семантически, map. На тот же ключ может быть повешен другой объект, с другим таймаутом (или вообще без него).

А фиг знает, увидел где-то в разборе кода. Идея в том, что shared_ptr<структура с atomic_bool> отлично описывает многосторонний отзыв

#offtop российские пользователи часом не испытвают никаких проблем с плюсовой конфой в слаке? третий день треш какой-то, у товарища в неё вообще никак не пускает, у меня только через веб, приложеньки посдыхали в вечном connecting...

слак у роспровайдеров уже месяц как подох(но иногда оживает)

слак уле=еле работает, да

Есть такой (местами псевдо)код. asio::ip::udp::endpoint clientEndPoint; while(true) { char buff[4096] = {0}; size_t bytesReceived = serverSocket->receive_from(asio::buffer(buff), clientEndPoint); if (bytesReceived != 0) { auto message = message(buff); std::thread t([message]() { process(message); }); t.join(); } } Который обрабатывает входящее сообщение, откуда бы оно не пришло, адрес клиента записывает в clientEndPoint и запускает обработку сообщения в отдельном треде. Но в методе process() описан сценарий диалога - что послать обратно по этому адресу и что ожидать в ответ, с тем же receive_from под капотом. Но дело в том что сообщение которое относится к диалогу может приняться в этом куске который я скинул, а не внутри process() Как это разрешить, и какой вообще нормальный архитектурный подход к такой проблеме?

Стандартная схемка заводить сессию на каждый коннект, которая по сути fsm. Куски этой fsm реакции на сетевые или не сетевые события. Всё состояние хранится в членах класса или ссылаются на разделённые переменные. А вообще иди экзамплы от asio проботай

Стандартная схемка заводить сессию на каждый коннект, которая по сути fsm. Куски этой fsm реакции на сетевые или не сетевые события. Всё состояние хранится в членах класса или ссылаются на разделённые переменные. А вообще иди экзамплы от asio проботай

Макоронный монстр?

Макоронный монстр?

Ну это же boost:asio. Можно, конечно, что-то навертухать или spawn заиспользовать. Вдруг понял, что у @NikBond не знает как состояние пошарить между двумя тредами.

Доброй ночи. Есть живые?

Все got free'd

Disposed

Доброй ночи. Есть живые?

Это становится комичным. После питона ты решил переписать все на плюсы?))

Это end.

Это становится комичным. После питона ты решил переписать все на плюсы?))

На питоне горящий проект на бабло, а на крестах пишу курсовую)

)))

Пишу на Си две курсовые)

По сетям игруля с UDP и glBegin/glVertex3f

совмести и будет quake 3

И по базам данных веб-приложение с libmicrohttpd и SQLite

совмести и будет quake 3

Я Ricochet хочу свой сделать

Собсна, вопрос Как можно реализовать шарповский аналог += EventHandler, т.е. описанную пользователем функцию выполнять конкретным объектом

Там коллизии простые очень, цилиндры с цилиндрами

свой класс делегатов можно написать и добавить этот оператор

Собсна, вопрос Как можно реализовать шарповский аналог += EventHandler, т.е. описанную пользователем функцию выполнять конкретным объектом

По-хипстерски — std::vector из std::function

по-нормальному

По-анархопримитивистски — массив указателей на функции и счётчик

А, про this забыл

Ну, массив структур

у меня простенькая работа

но скрины сюда нельзя

по-нормальному

Реактивное программирование, но тут надо чуть мышление перестроить

коротко - фреймворчик для работы с дисплеями

коротко - фреймворчик для работы с дисплеями

Сделай один хендлер

у меня простенькая работа

А ну тогда метод напиши <зарегистрируй эту штуку как коллбек>

И храни вектор из function

И пускай в нём уже пользователь либы явно пишет, что ему надо

В том числе и пробегает по вектору коллбеков

Но это по желанию

Да в том то и дело, что на каждый экземпляр может быть свой метод

потому что разные кнопки вызывают разные действия

Ну кстати да, лучше задавать сразу толпой при конструировании чем регистрировать в процессе

опуститесь на один уровень ниже в речи, пожалуйста)

коротко - фреймворчик для работы с дисплеями

Хренаси простенько

я понимаю через слово

Люди до сих пор не придумали как это адекватно делать

а что там сложного

ногами мк подёргал

Ну смари: Button b; b.registerEvent(call back); Или Button b{call back};

разметку отправил

Если у тебя мк тебе может не подойти фанкшн

/help@FailsBot

/help@FailsBot

USAGE: /help - prints this message; /vzhuh [message] - do vzhuh; /start - info about bot.

Я бы попытался написать статический интерфейс на шаблонах логика которого максимально раскрывается в компильтайме

/start@FailsBot

/start@FailsBot

Hello! I am the FailsBot, working as daemon process written in C with love and in rush in one night in Vim at Android device. Now I use the *stupid* person which hardcoded on main module therefore I have been often restarted. Stay determined! Feel free to write your suggestions to the bot's author in the @fludpac chat.

Блеан, скиньте список чатов кто-нибудь)

@proDOT

Ну смари: Button b; b.registerEvent(call back); Или Button b{call back};

Ууууу

Ненавижу второй вариант

Ненавижу второй вариант

Второй вариант более статичен следовательно хорош не?

Как и вообще какие-либо серьёзные параметры в конструкторах

Второй вариант более статичен следовательно хорош не?

Ну, для статики больше подходит, да

Как и вообще какие-либо серьёзные параметры в конструкторах

Как ты на вулкане ваще пишешь

ООП это по большей части конструирование

Вообще, тут, скорее, статично будет создаваться

ООП это по большей части конструирование

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

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

Значит у тебя недостаточная декомпозиция

Как ты на вулкане ваще пишешь

Там структуры, в них можно в любой момент писать что хочешь при любых условиях

Вопрос: является ли std::cout потокобезопасным?

Там структуры, в них можно в любой момент писать что хочешь при любых условиях

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

Вопрос: является ли std::cout потокобезопасным?

Нет

Нет

Уверен на 100%? Это прям в стандарте написано?

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

Если б в C++ можно было вызывать конструкторы полей и super в теле конструктора, я бы был полностью доволен ими

А костыль, который после двоеточия, бесит

Уверен на 100%? Это прям в стандарте написано?

Уверен что он не потокобезопасен по стандарту, что там конкретно написано хз