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

[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() из пространства имён OS.

Ни разу не так. Помещено туда определение шаблона process, а exec просто объявлена внутри process, и её определение вполне без проблем может быть сделано где угодно.

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

А я и не говорю, что оно здесь есть. Я его и предлагаю взамен наследования на котором вы настаиваете, хотя в наследовании тут смысла вообще почти нет: из-за того, что exeс статическая, никакое наследование не позволит иметь нормальный объект с инкапсулированными данными внутри - это будет просто пространство имён с "регулировкой" уровня доступа, не более.

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

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

CODE

        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) - тоже.
Получается вообще замечательно: старые проекты все подхватятся без изменений, а в новых пользователь имеет возможность выбрать для себя более удобный вариант.

Выглядит слабочитаемо. Что мешает завести свой потомок TBaseProcess вне пространства имен OS, оставив в покое родной шаблон?

+1.

Тут TProc1 передается как параметр шаблона только для того, чтобы в конструкторе взять адрес его exec. Страдает мое чувство прекрасного. Возможно менее разрушительным будет добавить второй конструктор, который получает адрес exec в качестве параметра? Или сделать этот конструктор с параметром единственным, задав ему значение по умолчанию? А в потомке вызывать с адресом своего exec. Тоже некрасиво - забудешь в потомке описать такой конструктор и компилятор не отловит. Не знаю. Хотя отловит - линкер выругается, что не определен exec() в предке... Но такое сообщение неверно описывает причину ошибки.

Да, всяко не очень красиво получается. А главное - ради чего?

Как вариант - можно добавить обсуждаемую фичу в Extensions. Именно как отдельного наследника TBaseProcess.

Вот это было бы лучше всего. Расширения для того и предназначены, чтобы расширять. Там можно что угодно делать - желающие пусть юзают.

Почему слабочитаемо? Всего-то добавлен один-единственный параметр шаблона, который должен иметь функцию exec(). Родной шаблон тоже не пострадал, всего лишь получил одного дополнительного предка. С точки зрения результирующего кода - ничего не изменилось абсолютно. С точки зрения интерфейса, предоставляемого OS::process - тоже полная идентичность.
Единственное, что изменилось - добавился альтернативный способ создания процессов в оси. Имхо, сплошной профит

Не понимаю, чем оно мешает в том виде, как предлагается сейчас?

Ты уже попробовал в реальном коде? Работает? Кодогенерация идентична? Если на все эти вопросы ответ положительный, можно обсудить дальше.

Если хочется нормальной инкапсуляции, то не нужно городить огороды, это делается легко базовыми средствами языка:

CODE

class TSlon
{
    ...
   void exec()
    {
        for(;;) { ... }
    }
   ...
};

template<> void TProc1::exec() { Slon.exec(); }

Имеем полную настоящую инкапсуляцию. Кроме того, слонов тут можно катать сколько угодно. И не только слонов, но и мамонтов, бегемотов и весь остальной зоопарк.

В общем, ждём результатов обкатки в железе предложенного варианта (process : public custom_process<...>).