Можно попробовать как-то так:

Спасибо!

А я пробовал просто вставить функцию внутрь класса message вот так:

на что получаю такую ошибку:

Вроде бы наследующий класс должен получать доступ ко всем public членам наследуемого?

ЗЫ: в Вашем примере будет дважды формироваться критическая секция? Сначала внутри reset(), а затем самим оператором Т ?

Это потому, что фукнция объявлена с квалификатором const - в этой функции все члены класса рассматриваются как константные и изменять представление класса нельзя. А функция reset его изменяет. Надо const тут убрать.


К пабликам имеют доступ все. Производные имеют доступ еще к защищенным (protected).


Да. Лишние секции можно, очевидно, убрать.

Upd. Не сразу вник в вопрос. Критические секции будут формироваться внутри функций, и это необходимо для их корректной работы. Вложенных секций нет (я сначала про это подумал - протупил), две секции, каждая в своем коде (функции), это нормально.

А, может быть, тогда сменить статус NonEmpty на protected, убрать из функции квалификатор const и обнулять эту переменную напрямую, а не с помощью reset().

Это наиболее оптимальный способ, с генерированием только одной критич. секции.

Секция все равно останется - просто она выйдет на уровень этого оператора (определенного в наследнике), сбрасывающего NonEmpty. При обращении к представлению объектов сервисов должна быть обеспечена атомарность доступа, поэтому без критической секции не обойтись.

Конечно, останется, но только одна - которая определяется в операторе.
А в случае с использованием функции reset() - добавится вторая, совершенно не нужная, внутри этой функции.

Я так вижу, что мы про разное говорим. Я про свой пример:

Где тут дополнительная секция?

В вашем примере критическая секция сначала формируется внутри reset(), а затем внутри оператора.
Всего два раза.
Но ведь можно сделать оптимальнее:

всего с одной критической секцией.

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

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

"Будем ждать, будем настороже!" (с) Капитан Смолетт.

Особенно интересна фича по мониторингу стёка.

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


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

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


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