Архитектурный вопрос, Команда, NVI и вct все все... xD Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Стандартный Переключить на: Линейный

[lanz]

В общем суть такова, есть некоторое количество(N) классов, наследующих от общего предка.
У предка есть интерфейс управления для обработки команд.

Раскрывающийся текст

class Base {
    public:
        virtual void Command (QString, QVariant);
};

Естественно конкретные реализации по разному обрабатывают команды.
В первом приближении примерно так:

Раскрывающийся текст

class DerivedN {
    public:
        virtual void Command (QString, QVariant) {
            switch (QString) {
                ...
                ...
            }
        };
};

Естественно это не очень красиво, поэтому сразу второе приближение:

Раскрывающийся текст

class DerivedN {
    public:
        virtual void Command (QString, QVariant) {
            this->map[QString] (QVariant);
        };
};

В map хранятся указатели на функции члены. Естественно мне захотелось вынести все это в базовый класс.

Раскрывающийся текст

class Base {
    public:
        void Command (QString, QVariant) {
            if (this->processors.contains (QString)) {
                this->processors[QString] (this, QVariant);
            };
        };
    protected:
        typedef std::function<void (Base*, QVariant)> CommandProc;
        QMap<QString,CommandProc> processors;

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

[Влад]

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

А еще я бы предложил подумать вот над чем: по-моему, тут как раз на схему обработки очень хорошо ляжет паттерн "Посетитель" (Visitor).

[lanz]

Вот так и описать.

Не выходит.

error C2647: '.*' : cannot dereference a 'void (__thiscall DerivedN::* )(QVariant)' on a 'Base'
error C2440: 'newline' : cannot convert from 'Base *' to 'DerivedN *'

Так понимаю поскольку это downcast, он отказывается неявно его преобразовывать, и в принципе правильно.

А еще я бы предложил подумать вот над чем: по-моему, тут как раз на схему обработки очень хорошо ляжет паттерн "Посетитель" (Visitor).

Посетитель не очень подходит ИМХО, поскольку у каждого наследника есть 3-15 уникальных для него команд.
Или я неправильно понимаю Посетителя или он нужен когда одну и ту же команду можно применить к объектам разного типа.

[Влад]

Так понимаю поскольку это downcast, он отказывается неявно его преобразовывать, и в принципе правильно.

И это правильно. Но в наследнике-то ты уже точно знаешь, с объектом какого именно класса ты работаешь; поэтому что мешает downcast'ить "ручками"? Или я чего-то не понимаю? Если так, попробуй накидать код минимального примера, иллюстрирующего проблему, - попробуем разобраться "на кошках".

[lanz]

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

Приложил минимальный пример.

Прикрепленные файлы

 qscratch.zip ( 1.12 килобайт ) Кол-во скачиваний: 128

 

[lanz]

Сделал так:

Раскрывающийся текст

class Base : public QObject {
    Q_OBJECT
    public:
        void Command (QString cmd, QVariant arg) {
            if (this->procs.contains (cmd)) {                
                QMetaObject::invokeMethod (this, this->procs[cmd], Q_ARG(QVariant,arg));
            };
        };
    protected:
        QMap<QString, const char*> procs;
};

Раскрывающийся текст

class Derived : public Base {
    Q_OBJECT
    public:
        Derived () {            
            this->procs["do-derived"] = "cmdDoDerivedThing";
        };
    private:
        Q_INVOKABLE    void cmdDoDerivedThing (QVariant arg) {        
            qDebug () << "hello!";
        };
};

Раскрывающийся текст

int main(int argc, char *argv[])
{
    Base *ptr = new Derived ();
    ptr->Command ("do-derived", QVariant());
    return 0;
}

Пинки, мысли вслух, философские размышления и критика приветствуются!

[Алексей1153]

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

по сути - экземпляру передаётся XML с названием функции и перечисленными атрибутами - параметрами (с их значениями)

Сообщение отредактировал Алексей1153 - 26.3.2013, 18:06

[Iron Bug]

Вот, по-быстрому написала, как в С++11 это сделать можно.
Это без Qt(я её не юзаю), но не суть. Можно любые классы и контейнеры использовать, это не принципиально.
У меня заюзан простой map и функция, принимающая int, для примера.
В GCC компилируется с опцией -std=c++11.

Раскрывающийся текст

#include <map>
#include <string>
#include <stdio.h>
#include <functional>

using namespace std;

class Base
{
public:
        typedef std::function<void(int d)> CommandProc;
        typedef map<string,CommandProc> map_type;

protected:
        map_type processors;
public:
        Base() {
                processors.insert(map_type::value_type("BaseCommand",std::bind(&Base::BaseCommand, this, std::placeholders::_1)));

        }
        void Command (string str, int value) {
                map_type::iterator iter = processors.find(str);
                if(iter != processors.end())
                        (iter->second)(value);
        };
protected:
        void BaseCommand(int value) {
                printf("this is Base::BaseCommand with argument %d\n",value);
        }
};

class Child1 : public Base
{
protected:
        void MyCommand(int value) {
                printf("this is Child1::MyCommand with argument %d\n",value);
        }
public:
        Child1() {
                processors.insert(map_type::value_type("MyCommand",std::bind(&Child1::MyCommand, this, std::placeholders::_1)));
        }
};

class Child2 : public Base
{
protected:
        void MyCommand(int value) {
                printf("this is Child2::MyCommand with argument %d\n",value);
        }
public:
        Child2() {
                processors.insert(map_type::value_type("MyCommand",std::bind(&Child2::MyCommand, this, std::placeholders::_1)));

        }
};


int main(int argc, char* argv[])
{
        Child1 test1;
        test1.Command("BaseCommand",10);
        test1.Command("MyCommand",10);
        Child2 test2;
        test2.Command("BaseCommand",20);
        test2.Command("MyCommand",20);
}

Сообщение отредактировал Iron Bug - 26.3.2013, 22:45

[lanz]

Вот, по-быстрому написала

Настоящая черная магия
Супер, спасибо!

Насколько я понимаю, в старом std/tr1 так не получится или я что-то упустил?

lanz, все названия функций - в текстовом виде, все параметры- в текстовом виде.

Кстати насчет массивов данных, что тут лучше, base64? Нормально будет для объемов до 500Кб?
А то что то меня душит, непойму что

[Iron Bug]

Насколько я понимаю, в старом std/tr1 так не получится или я что-то упустил?

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

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

[Алексей1153]

стати насчет массивов данных, что тут лучше, base64? Нормально будет для объемов до 500Кб?
А то что то меня душит, непойму что

жабу не слушай, делай строку хексов 00112233AAFF , а то на конвертации потратишь больше ресурсов )
500 кб - фигня для нечастых обменов

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

[lanz]

делай для этого отдельный быстрый метод без текста.

В итоге на этом и остановился.

Хочется чтобы потом легко распилилась программа на клиент-сервер.
Кстати какие лучше протоколы городить чтобы потом на TCP хорошо легло?
Свой придумывать с текстовыми командами + сегментами данных или ориентироваться на COM/Dbus, protobuf например?
Стоит ли морочится с TCP или сразу лучше взять zmq?

[Алексей1153]

lanz, а где, что и в каких объёмах будет гоняться ? От этого зависит

если это НЕ локалка, то можно составлять XML или JSON (он полегковеснее), ужимать стандартным

QByteArray qCompress ( const QByteArray & data, int compressionLevel = -1 )

(для ужимаемых случаев, так как короткую строку нет смысла жать) и пересылать.

Городить двоичные протоколы - фу фу, пройденный этап ) Потом в определённый момент заколебает несовместимость

если это всё локально, то и без сжатия будет летать. Ну там тесты и покажут

[lanz]

Графики кривых, 5-10К точек, хотелось бы хотябы 10-15 в секунду, локально естественно. Не локально я думаю раз-два в секунду где-то.
XML/JSON/сжатие-растяжение кажется тяжеловато будет.

Я тут глядел на камеры которые через Ethernet работают. Там все здорово аж до 30 fps, но они свои драйвера рекомендуют ставить и выделенную сетевуху, так что мне кажется становится тесновато для просто лобового подхода.

Надо пробовать в общем

Городить последнее дело, понятно, вот если взять готовый...
Как кстати насчет Dbus/COM, ни у кого не было опыта использования?

[Алексей1153]

lanz, ну тут, само собой, лучше оставить лазейку для передачи прямого пакета.

Как кстати насчет Dbus/COM, ни у кого не было опыта использования?

у меня нет

[Iron Bug]

Как кстати насчет Dbus/COM, ни у кого не было опыта использования?

c COM одно время дело имела - это было наследние тех, кто писал проект до меня. не понравилось просто ужасно. может, на С# или каком-нить вижуал бейсике это выглядит проще, но на С++ под него писать очень сложно, особенно если ты не потребитель ресурсов, а сам что-то предоставляешь. потом, регистрация объекта - дело довольно геморное. юзать COM можно, но удовольствия это не доставляет.
мне вообще кажется, что последние годы мелкософт хочет отойти от COM и "неуправляемых" (native) приложений. я даже подозреваю их в том, что они из-за этого не хотят развивать и поддерживать компилятор С++. может, это паранойя, но как-то так это выглядит.

Сообщение отредактировал Iron Bug - 27.3.2013, 19:38