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

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

Помещать функцию в пространство имён или не помещать - это личное предпочтение автора примера, ни язык, ни ОС этого не требуют. В других примерах - тот же AVR/IAR, в частности, этого нет.

Вообще-то она изначально туда помещена, в объявлении. То, что некоторые компиляторы до сих пор позволяют не указывать это в реализации, не выносит exec() из пространства имён OS.

Приводимыми агрументами и не удастся. Контрагументы, имхо, сильнее.

Или же кто-то просто упёрся

Не более лишняя, чем определение класса в предлагаемом варианте. Скажи, чем отношение наследования лучше отношения включения? В данном конкретном случае.

А где ты видишь здесь включение? Никакого включения нет. Есть вызов некой функции некоего стороннего объекта из функции exec() другого класса. Какое же это включение?

предлагаемый вариант предоставляет только один способ - безальтернативно включить весь код процесса в один класс.

Опять не так. Что мешает включить какой-то другой объект в класс процесса? Или же, по-нынешнему, вызвать из exec() функции любого другого объекта?
Короче, сплошные профиты от нынешнего варианта. А недостатков я по-прежнему не вижу

Что мешает тебе наследовать от process<>? Хотя я бы так не делал - лучше написать отдельный класс и вызывать его функцию (или функции) из exec.

Не помню, но что-то вроде мешает. Не получается, емнимс. Хотя надо попробовать...

[AHTOXA]

Йоу! Я придумал, как совместить эти два варианта

Короче, переименовываем в новом варианте process в customProcess, а process объявляем вот так:

Код

        template<TPriority pr, size_t stack_size>
        class process : public customProcess<process<pr, stack_size>, pr, stack_size>
        {
        public:
            OS_PROCESS static void exec();
        };

И всё! Старый вариант работает, и новый (наследование от customProcess) - тоже.
Получается вообще замечательно: старые проекты все подхватятся без изменений, а в новых пользователь имеет возможность выбрать для себя более удобный вариант.

[ArtDenis]

Йоу! Я придумал, как совместить эти два варианта

Да, удачное решение Мне оно в голову не пришло