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

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

Ладно, раз уж у Гарри такая идиосинкразия к этому варианту, то давайте сделаем его расширением. Я попробовал, оказывается это работает точно так же
Вот, приаттачу пока сюда, а на днях выложу в репозиторий (Уж здесь-то, я думаю, возражений не последует?).
[attachment=72666:CustomProcess.h.zip]

Э-э, мы, вроде, договорились, что если реализация не страдает, то принимаем. Т.ч. это можно не расширением, а основным вариантом делать. Клади в trunk, попробуем при случае.

Хотя нынешний процесс -- скорее шасси, на которое можно пассажирскую газельку навесить, можно бортовую. Предлагается только вариант на шлее тянуть за этим шасси телегу.

Да, скорее просто платформа для перевозки. Проблема в том, она не очень хорошо переделывается ни в полноценный грузовик, ни в автобус (из-за статика).

Ну да. Только я считаю абсолютно полноправным (равноправным с другими) вариант

CODE

class Тгрузовик : public Ттранспорт;
class Тавтобус : public Ттранспорт;

И не считаю, что всегда и везде единственно правильно

CODE

class Тгрузовик { public: едь(); };
Ттранспорт<..> транспорт1;
Тгрузовик грузовик;
транспорт1::толкай() { грузовик.едь(); }

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

И ещё попробую сделать вариант с нестатическим exec(). Тоже в виде расширения. Чтоб уж совсем была инкапсуляция

то тогда в корне пересмотрим подход. Почему там статик, я сейчас уже не помню, то ли что-то не получалось по-иному сделать, то ли тогда видение было таким, идеология. Исторически сложилось. Исходно упор был на минимизацию и лёгкость, нынче времена меняются, можно и основные концепции пересмотреть в каких-то пределах.

Может, я наглухо испорчен борландсишным

CODE

class TMyThread : public TThread {
    protected:
        virtual void execute(); // А в этой теме предлагается вместо virtual передать базе тип потомка

но мне это не кажется настолько ненормальным, что нельзя это добавить в саму ОС. Другое дело, если бы это ломало все существующие наработки, но оно же прозрачно для старых проектов.
И не у меня последнего такая хотелка, как видим.

Ну, с методами (виртуальными функциями) в борланде всё понятно - там-то это как правило именно тред - поток управления, который имеет начало и конец - вызвали его, он отработал и кончился. И тут нужна гибкость при вызове, чтобы можно строить элегантные схемы с обработкой - вызывать автоматом нужный в каждом контексте метод. Это не про нас.

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

[Сергей Борщ]

Почему там статик, я сейчас уже не помню, то ли что-то не получалось по-иному сделать,

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

[Сергей Борщ]

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

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

[AHTOXA]

Давайте я сюда добавлю ссылки на уже придуманные варианты. Вот вариант раз, вот вариант два. Я собственно их и хотел покрутить. Тем более, что с новым параметром шаблона это делать проще.

[Сергей Борщ]

вот вариант два

Я изобрел ведосипед. "Говорят, у дураков мысли сходятся. Но у умных - ЧАЩЕ!"

[AHTOXA]

Я вот что подумал. В момент вызова TBaseProcess::init_stack_frame() у нас уже гарантированно имеется в нужных регистрах указатель на TBaseProcess. Таким образом, ничего формировать не надо, достаточно лишь честно сохранить контекст, подменив PC адресом начала функции-члена exec().
Для пробы можно сделать в конструкторе наследника, как-то так:

Код

class BaseVirtualProcess : public TBaseProcess
{
public:
    INLINE_PROCESS_CTOR BaseVirtualProcess(stack_item_t * StackPoolEnd, TPriority pr)
        : TBaseProcess(StackPoolEnd, pr, 0 // - не нужен)
    {
        reinit_stack_frame();
    }
protected:
    OS_PROCESS virtual void exec() {}; // это наш виртуальный exec()
private:
    void reinit_stack_frame()
    {
        StackPointer += 16;                           // отменим деятельность TBaseProcess::init_stack_frame()
        *(--StackPointer)  = 0x01000000L;             // xPSR
        *(--StackPointer)  = reinterpret_cast<uint32_t>(&exec); // вот здесь адрес виртуального exec
        // и тут честно сохраняем остальные регистры, в том числе и self. (наверное будет ассемблерная процедура в порте)
    }
};

Правда reinterpret_cast здесь не проходит, надо какой-то ещё способ получить адрес exec().

---
Добавлю ссылочку про получение адреса функции-члена. На завтра