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

[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]

А если сделать дополнительную статическую функцию, скажем, start(), с параметром типа "тип процесса", в init_stack_frame() использовать ее вместо exec, в стековый фрейм на место регистра, в котором передается параметр, класть this, А функция уже будет делать param->exec(). Т.е. мы не вдаемся в дебри реализации указателя на функцию-член, этим занимается компилятор в start(), exec может быть нестатическим. Как-то так... Еще неплохо бы объявить exec как noreturn, чтобы компилятор догалася заменить вызов exec() на переход в нее. В принципе, такое изменение достойно релиза 4.1. И продумать совместимость с текущими исходниками.

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

P.S. Сам пока этим заниматься не могу, завален по уши текучкой, т.ч. инициативные товарищи - ваша инициатива - ваша реализация. Делайте расширение (думаю, сразу в trunk). Кстати, интересный вопрос, можно ли будет использовать гибридную схему - часть процессов по традиционному варианту, часть по новому? Навскидку вижу препятствие - разный способ вызова (напрямую и через указатель). Вот если б можно было совместить этих ужа с ежом, это было бы действительно клёво. Хотя бы тем, что совместимость точно никуда не денется.