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

[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. Там есть спецы, знающие стандарт наизусть

[ReAl]

В общем, задал вопрос на RSDN: http://www.rsdn.ru/forum/cpp/4963144.all. Там есть спецы, знающие стандарт наизусть

Ну да.
Только конкретно у gcc где-то нелады и вышло, что

Код

namespace OS {
    template<> TProc1::exec();
}

template<> TProc1::exec()
{
    ...
}

он всё компилирует нормально, но выдаёт предупреждение redundant redeclaration и как предыдущее объявление тычет носом в OS_Kernel.h, в объявление неспециализированной функции в теле

Код

        template<TPriority pr, size_t stack_size>
        class process : public TBaseProcess
        {
        public:
            INLINE_PROCESS_CTOR process();

            OS_PROCESS static void exec();  // <---- вот сюда

Но при этом просто

Код

template<> TProc1::exec()
{
    ...
}

не собирает, тут ему уже того объявления недостаточно.
Вот и вышло, что минимальной кровью так, определение-объявление одним махом:

Код

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

что тоже допускается.

[ArtDenis]

Ну да.
Только конкретно у gcc где-то нелады и вышло, что

Код

namespace OS {
    template<> TProc1::exec();
}

template<> TProc1::exec()
{
    ...
}

void потерялся. Поэтому и предупреждение вышло.

Тот пример, что я выкладывал сообщением выше компилируется без предупреждений.

[ReAl]

void потерялся. Поэтому и предупреждение вышло.

Ой, ну это я тут из головы забыл, в тексте void есть.
И без него совершенно другая ругань

Код

namespace OS {
   template<> TProc1::exec(); // Строка 161
}

template<> TProc1::exec() // Строка 164
{
    DRIVER(PROC1,OUT);
    DRIVER(TIMER1_TO_PROC1,OUT);
    for(;;) {
        OFF(PROC1);
        Timer1_Ovf.wait();
        ON(PROC1);
        OFF(TIMER1_TO_PROC1);
    }
} // TProc1::exec()

Код

==== Compiling ./src/main.cpp
./src/main.cpp:161:29: error: expected constructor, destructor, or type conversion before ‘;’ token
./src/main.cpp:164:25: error: ISO C++ forbids declaration of ‘exec’ with no type
./src/main.cpp:164:12: error: template-id ‘exec<>’ for ‘int OS::process<(OS::TPriority)0u, 100u>::exec()’ does not match any template declaration

Тот пример, что я выкладывал сообщением выше компилируется без предупреждений.

-Wredundant-decls есть?
С ним и с -Wredundant-decls

Код

namespace OS {
   template<> void TProc1::exec(); // Строка 161
}

template<> void TProc1::exec()  // Строка 164
{
    DRIVER(PROC1,OUT);
    DRIVER(TIMER1_TO_PROC1,OUT);
    for(;;) {
        OFF(PROC1);
        Timer1_Ovf.wait();
        ON(PROC1);
        OFF(TIMER1_TO_PROC1);
    }
} // TProc1::exec()

Код

==== Compiling ./src/main.cpp
./src/main.cpp:161:33: warning: redundant redeclaration of ‘static void OS::process<pr, stack_size>::exec() [with OS::TPriority pr = (OS::TPriority)0u, unsigned int stack_size = 100u]’ in same scope
../scmRTOS/Common/OS_Kernel.h:333:36: warning: previous declaration of ‘static void OS::process<pr, stack_size>::exec() [with OS::TPriority pr = (OS::TPriority)0u, unsigned int stack_size = 100u]’