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

[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) Более привычный способ реализации ф-ции.

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

[AHTOXA]

AHTOXA, Указатель на нестатическую функцию член класса в с++ - это не настоящий указатель. Его структура и размер зависят от компилятора. Поэтому чтобы узнать адрес ф-ции, надо выяснить где именно в структуре этого указателя "сидит" конкретно адрес для перехода.

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

А зачем вообще нужна нестатическая функция для процесса? Всё равно каждый процесс существует в единственном экземпляре.

Чтобы обращаться к членам класса. Чтобы инициализировать их в конструкторе. Чтобы обращаться к унаследованным функциям класса, в конце концов. Короче, чтоб инкапсуляция

Не надо адрес функции-члена...

Ладно, ладно
Сделал вариант с виртуальным exec().
В процессе работы обратил внимание, что TKernelAgent::cur_proc() - private. Мне непонятно такое недоверие к потомкам TKernelAgent:)
Пришлось выкручиваться так:

Код

TBaseProcess* base = const_cast<TBaseProcess*>(get_proc(cur_proc_priority()));

вместо тривиального

Код

TBaseProcess* base = cur_proc();

Обратил внимание, что gcc довольно своеобразно понимает атрибут noreturn. Он перестаёт восстанавливать испорченные регистры, но всё равно сохраняет их!
За счёт этого, кстати, вариант с виртуальным exec не проигрывает по стеку варианту с вызовом Slon.exec() из SlonProc::exec().
Хотя нет, всё равно проигрывает. Там же вызов через виртуальный транк...

В общем, вот, смотрите/критикуйте:

CODE

#ifndef VIRTUALPROCESS_H_
#define VIRTUALPROCESS_H_

#include <scmRTOS.h>

namespace OS
{

class BaseVirtualProcess : public TBaseProcess, public TKernelAgent
{
public:
INLINE_PROCESS_CTOR BaseVirtualProcess(
stack_item_t * StackPoolEnd
, TPriority pr
#if scmRTOS_DEBUG_ENABLE == 1
, stack_item_t * aStackPool
#endif
) : TBaseProcess(
StackPoolEnd
, pr
, launch_exec
#if scmRTOS_DEBUG_ENABLE == 1
, aStackPool
#endif
)
{
}
protected:
OS_PROCESS virtual void exec() { for(;;){} };
private:
OS_PROCESS static void launch_exec()
{
for(;;) // eliminate compiler warning
{
TBaseProcess* base = const_cast<TBaseProcess*>(get_proc(cur_proc_priority()));
// TBaseProcess* base = cur_proc(); // private!
BaseVirtualProcess* proc = static_cast<BaseVirtualProcess*>(base);
proc->exec();
}
}
};


template<TPriority pr, size_t stack_size>
class VirtualProcess : public BaseVirtualProcess
{
public:
INLINE_PROCESS_CTOR VirtualProcess()
: BaseVirtualProcess(&Stack[stack_size/sizeof(stack_item_t)]
, pr
#if scmRTOS_DEBUG_ENABLE == 1
, Stack
#endif
)
{
}
private:
stack_item_t Stack[stack_size/sizeof(stack_item_t)];
};

} // namespace OS


#endif /* VIRTUALPROCESS_H_ */