Небольшая проблема с обработкой сообщений, сброс флага "Сообщение пусто" Опции

[sonycman]

Доброго времени суток!

Организую взаимодействие между двумя процессами с помощью сообщений.
Один процесс отправляет сообщение, другой - принимает.

Почему то казалось, что после считывания сообщения оператором = его статус автоматически устанавливается на "пусто".
Поэтому делал так:

CODE

//thread 1
command_message.send();
response_message.wait();
...

//thread 2
if (command_message.is_non_empty())
{
message_placeholder = command_message;
...
response_message.send();
...
}

Оказалось, что это не так, и необходимо после считывания принудительно сбрасывать сообщение функцией reset().

Но, может быть, удобнее было бы сделать автоматический сброс флага NonEmpty после отрабатывания оператора присваивания?

[jorikdima]

Я все-таки не понимаю, почему нельзя просто дописать свой код, который нужен. Или функцию, которая делает опрос и сброс, или, если уж так хочется работать непосредственно с объектом, отнаследоваться от message, добавить там свой operator=(), который будет сбрасывать внутренний флаг и выдавать наружу тело сообщения, как штатный оператор.

Кстати помните наш диалог про то, что неплохо было бы сделать все (большинство) методов и полей под квалификатором protected а не private, для того, чтоб наследоваться и расширять функционал класса. Вот пример, когда это было бы весьма кстати. А так товарищу формально нужно будет менять код ОС, чтоб иметь возможность отнаследоваться.

Если вас не устраивает такое решение, подождите некоторое время, как сказал Сергей, скоро будет новый релиз, в нем можно создавать пользовательские сервисы (для этого там будет документированный API), вы сможете сделать свою версию сообщения так, как вам нравится.

Сорри, не дочитал до конца. Судя по всему в этом направлении есть изменения! Здорово, буду ждать!

[dxp]

Кстати помните наш диалог про то, что неплохо было бы сделать все (большинство) методов и полей под квалификатором protected а не private, для того, чтоб наследоваться и расширять функционал класса.

Большинство функций-членов там вообще public. Приватные функции по пальцам можно пересчитать.

Вот пример, когда это было бы весьма кстати. А так товарищу формально нужно будет менять код ОС, чтоб иметь возможность отнаследоваться.

В данном случае это ничего бы не дало. Все представление, к которому нужен доступ, досягаемо через открытые функции-члены. В этом контексте имело бы смысл делать данные protected, но это как-то уже не совсем хорошо. Основной идеологический посыл в том, что классы сервисов не предназначены для непосредственного расширения. Для расширения будет предоставлен специальный механизм, на основе которого будут реализованы и штaные классы сервисов.