Альтернативный вариант задания функции процесса Опции

[ArtDenis]

Приветствую.

Начал смотреть scmRTOS. Сразу начал резать глаз способ реализации функции процесса:

Код

typedef OS::process<OS::pr0, 300> TProc1;

namespace OS
{
    template <>
    OS_PROCESS void TProc1::exec()
    {
        for(;;)
        {
            ef.wait();
            PB0.Off();
        }
    }
}

Необходимость реализовывать функцию процесса внутри поля имён OS, а добавление template <> вызывает некоторое удивление

Подумалось, почему-бы не сделать ф-цию exec просто ф-цией своего собственного класса? На скорую руку сделал несколько изменений в исходниках scmRTOS и весь код декларации и реализации процесса превратился в:

Код

class TProc1 : public OS::process<TProc1, OS::pr0, 300>
{
public:
    static void exec()
    {
        for(;;)
        {
            ef.wait();
            PB0.Off();
        }
    }
};

Что мы в итоге имеем? 1) Класс, в котором можно инкапсулировать данные и методы процесса. Закрытые и используемые только в TProc1 данные можно объявить в секции private класса и никто к ним не получит доступ. 2) Более привычный способ реализации ф-ции.

Кто что думает на этот счёт?

[dxp]

Проверил.
Предложенный вариант даёт полностью, до байта совпадающий бинарный файл прошивки. Но я его на всякий случай прогнал в железе. Работает!

Молодец!

А этого (регулировки уровня доступа) мало?

Конечно мало. Тут речь про инкапсуляцию ведут, а оная подразумевает наличие законченного целостного объекта. Но на деле никакого объекта и в помине нет, а есть сборная солянка из статических членов, засунутых в общее пространство имён. Т.е. ни абстракции, ни отделения интерфейса от реализации (т.к. и интерфейса-то никакого нет) - ничего этого нет. За что боремся?

Все процессы существуют в единственном экземпляре, поэтому статическая exec() не пугает.

Пугать-то не пугает, но и ничего этот подход не даёт.

Этот вот TSlon::exec() перестал быть функцией процесса. Потерял доступ к protected в TBaseProcess. Их там (пока) и немного, но тут уже «страдает чувство прекрасного» у меня.

А зачем ему этот доступ? Всё, что предназначено для доступа с уровня пользовательской программы, помещено в public секцию, остальное - для внутренних служебных целей. Поэтому разрешение доступа юзеру к этому представлению - это никакое не благо, а дырка в защите. Если там есть что-то, к чему надо дать доступ на уровне прикладного кода, это надо поместить в открытую секцию.

По поводу сущностей: «предоставлять функцию процесса» -- это задача базового класса процесса.

Не базового класса процесса, а собственно процесса. Базовый класс процесса нужен для повышения эффективности и является "технологическим".

И если про что-то в системе я думаю «это -- процесс», то мне естественно думать «занчит, оно должно біть потомком базового класса процесса».

Это почему это? Процесс - это транспорт, который выполняет "транспортную" функцию. А уж чем его загрузишь, то он и повезёт. Отождествлять грузовик с перевозимым грузом, является, имхо, не очень удачной идеей.

Ну так вот сижу я и думаю
«так, мне нужен процесс обслуживания индикации»
«другие будут дергать этот процесс такой-то функцией, которая будет помещать запросы в очередь»
«ага, у процесса должна быть очередь»

А если этот процесс не только обслуживает индикацию, но и, например, клавиатуру опрашивает? Что мешает на одном "автобусе" катать и пионеров, и бабушек? По моему опыту, как раз-таки, нередко один процесс обслуживает более, чем одну сущность.

Это совершенно неверно. Согласно стандарту языка С++, специализация шаблонной функции должно быть выполнено только в том пространстве имён где был объявлен шаблон. То, что некоторые компиляторы допускают иную трактовку, является их ошибкой.
Вот выдержка из стандарта (14.7.3/1):

Вы путаете declaration (объявление) и definition (определение). Также вы путате явную (explicit) специализацию и полную (full) специализацию. Приведённый вами пункт стандарта гласит о том, что если используется явная специализация, то она должна быть объявлена в том же простанстве имён. Но где там сказано, что на должна быть определена в этом пространстве имён? У нас там нигде явной специализации не объявляется.

В любом случае компиляторы подтянуться к стандарту, код перестанет компилироваться и придётся писать

CODE

namespace OS
{
    template <>
    OS_PROCESS void TProc1::exec()
    {
        ...

А этот код - это определение полной (а не объявление явной) специализации функции. Т.ч. всё в порядке, ничего компилироваться не перестанет, пусть там копиляторы хоть подтянутся, хоть отожмутся.

[ArtDenis]

Вы путаете declaration (объявление) и definition (определение). Также вы путате явную (explicit) специализацию и полную (full) специализацию. Приведённый вами пункт стандарта гласит о том, что если используется явная специализация, то она должна быть объявлена в том же простанстве имён. Но где там сказано, что на должна быть определена в этом пространстве имён? У нас там нигде явной специализации не объявляется.

На самом деле на этот пункт стандарта я вышел погуглив сообщение об ошибке. К сожалению, из той цитаты, что я привёл, действительно не ясно насчёт определения ф-ции.
В общем, задал вопрос на RSDN: http://www.rsdn.ru/forum/cpp/4963144.all. Там есть спецы, знающие стандарт наизусть