Делегат на шаблонах

[DmitryM]

Интересное решение, но проблема в том, что в базовом классе возвращаемый тип не известен.

Ох, тогда возвращай variant/any

[alexis031182]

Ох, тогда возвращай variant/any

Спасибо большое, оно

[alexis031182]

Всё работает. Осталась оптимизация. Шаблон варианта автоматом разрулил все остальные проблемы. Спасибо

[alexis031182]

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

С горя полез в Loki Александреску. Документации по его библиотеке практически никакой нет. Книги его в свободном доступе найти не удалось. Разбирался с исходниками, точнее с той их частью, что напрямую касалась интересующей меня темы.

Шаблоны сами по себе вещь не сложная. Зачастую программеры ограничиваются использованием их лишь в роли дополнительной абстракции, позволяющей указать в compile-time некие типы неких объектов. Вот класс делегата, опубликованный в начале темы, как раз из этого разряда. Единственное, что там может смутить начинающего изучать шаблоны - это их специализация. Впрочем, разобраться при желании с этим вопросом совсем не трудно.

В Loki всё значительно веселее. Метапрограммирование на шаблонах - истинно то, что позволяет вынести мозг буквально с первых минут изучения. Тем не менее, когда начинаешь въезжать, мощь производит впечатление. Следует также иметь ввиду один очень важный момент: этот код выполняется в compile-time, а значит какое бы другое run-time решение, пусть даже самое супер оптимизированное, не было бы представлено взамен, оно всё равно будет выполняться медленнее. И вполне вероятно, что значительно медленнее. Вот такая вот "магия".

Публикую второй вариант делегата на шаблонах. Здесь всё работает как положено, как собственно мне и хотелось. Проверка типов, само собой, осуществляется ещё на этапе компиляции, поэтому подсунуть что-то левое будет довольно сложно. Естественно код содран с Loki (лицензия позволяет). Впрочем можно было вообще ничего не "сдирать", а использовать "as is", но мне хотелось разобраться, вникнуть, так сказать, в самое оно. Результатом стала "лёгкая" переработка имеющихся в составе Loki шаблонов. Конечно же с сохранением концепции.

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

Использовать новый делегат также просто как и предыдущий. Впрочем, можно подумать о специализации некоторых отдельных параметров, дабы лишний раз не указывать void при отсутствии возвращаемого значения и/или обозначать отсутствие аргументов функции. Но всё это уже не столь существенно и может быть легко настроено самостоятельно.

Код

C++ (Qt)
#include "adelegate.h"
 
class A {
public:
    void echo() {qDebug() << "A::echo()";}
};
 
class Base {
public:
    void foo() {qDebug() << "foo()";}
    void bar(int a) {qDebug() << QString("bar(%1)").arg(a);}
 
    A *test(QString a, int b) {qDebug() << QString("test(%1)").arg(a) << b; return new A;}
 
};
 
int main(int argc, char *argv[])
{
Base b;
 
typedef void(Base::*foo)();
ADelegate<Base*, foo> delegate(&b, &Base::foo);
delegate();
 
typedef void(Base::*bar)(int);
ADelegate<Base*, bar, void, ALoki::TypeSequence<int> > delegate1(&b, &Base::bar);
delegate1(2);
 
typedef A*(Base::*test)(QString, int);
ADelegate<Base*, test, A*, ALoki::TypeSequence<QString, int> > delegate2(&b, &Base::test);
A *r = delegate2(QString("tratata"), 10);
r->echo();
delete r;
 
return 0;
}
 

[DmitryM]

что в базовом классе возвращаемый тип не известен.

И как ты решил свою проблему? 

[alexis031182]

И как ты решил свою проблему?  

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

[m_ax]

Это всё можно проще сделать.. Накатаю пример, как приду домой..

[alexis031182]

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

[alexis031182]

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

Код

C++ (Qt)
#include "alokifunctor.h"
 
void a() {
    qDebug() << "a()";
}
 
class Base {
public:
    const QString test(const QString &txt) {return txt;}
};
 
int main(int, char**)
{
ALoki::Functor<> functor(&a);
functor();
 
Base obj;
typedef const QString(Base::*test)(const QString&);
ALoki::Functor<const QString, ALoki::TypeSequence<const QString&> > functor1(&obj, &Base::test);
qDebug() << functor1("tratata");
 
return 0;
}
 

Третий вариант отличается от второго прежде всего структурой. Помимо прочего, добавлено два класса для "разруливания" указателя на функцию и указателя на метод класса.

[m_ax]

Можно лучше. Например, используя библиотеку libssc (я использовал версию libssc-cpp11-1.0.3 http://www.prog.org.ru/topic_16829_90.html)

Тогда это будет выглядеть так:

Код

C++ (Qt)
#include <iostream>
#include <string>
#include "signal_slot.h"
 
void a() {
    std::cout << "a()" << std::endl;
}
 
class Base : public ssc::trackable {
public:
    void test1() {std::cout << "test1()";}
    void test2(int a) {std::cout << a << std::endl;}
    void test3(const std::string &b) {std::cout << b << std::endl;}
 
    int problemFunc() {
        std::cout << "We are the champions!!!" << std::endl;
        return 0;
    }
 
};
 
int main()
{
    ssc::signal<void> sig0;
    sig0.connect(a);
    sig0();
 
    Base base;
 
    ssc::signal<int> sig_int;
    sig_int.connect(&base, &Base::test2);
    sig_int(10);
 
    ssc::signal<void> sig_problemFunc;
    sig_problemFunc.connect(&base, &Base::problemFunc);
    sig_problemFunc();
 
 
    return 0;
}
 

Проект с библиотекой приаттачен.

А если подумать ещё, то можно и вовсе сделать так, как задумывалось в первоначальном варианте.
Немного почистить исходники libssc и этот делегат готов)

[alexis031182]

Можно лучше. Например, используя библиотеку libssc (я использовал версию libssc-cpp11-1.0.3 http://www.prog.org.ru/topic_16829_90.html)
...

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

...
А если подумать ещё, то можно и вовсе сделать так, как задумывалось в первоначальном варианте.
Немного почистить исходники libssc и этот делегат готов)

Мой первоначальный вариант меня не устраивал. В итоге темы получился третий, который делает всё что необходимо:
- независимый от какого-либо наследования функтор;
- выполнение любых функций/методов с любым набором аргументов;
- возврат любого значения без необходимости явного указания типа этого значения на этапе вызова делегированной функции;
- ну и конечно код должен формироваться не в run-time.

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

Update: и Вы, похоже, в аттач только мой вариант делегата запостили

[DmitryM]

Мой первоначальный вариант меня не устраивал. В итоге темы получился третий, который делает всё что необходимо:
- независимый от какого-либо наследования функтор;
- выполнение любых функций/методов с любым набором аргументов;
- возврат любого значения без необходимости явного указания типа этого значения на этапе вызова делегированной функции;
- ну и конечно код должен формироваться не в run-time.

Я бы взял функторы или сигналы из boost и не парился.

[alexis031182]

Я бы взял функторы или сигналы из boost и не парился.

Нужно было узнать, как это работает.

[m_ax]

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

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

Мой первоначальный вариант меня не устраивал. В итоге темы получился третий, который делает всё что необходимо:
- независимый от какого-либо наследования функтор;
- выполнение любых функций/методов с любым набором аргументов;
- возврат любого значения без необходимости явного указания типа этого значения на этапе вызова делегированной функции;
- ну и конечно код должен формироваться не в run-time.

Вот это всё можно более изяшно реализовать, подсмотрев как устроена libssc.

Update: и Вы, похоже, в аттач только мой вариант делегата запостили

Да, сорри, не то приаттачил)
Переаттачиваю)

[alexis031182]

Оно, во-первых безопаснее. Т.е. если объект (receiver) будет разрушен, соединение автоматически разорвётся.

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

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

Это в Loki есть. Очередь из делегатов. Мне как таковые сигнал/слоты не нужны, нужен именно делегат.

Вот это всё можно более изяшно реализовать, подсмотрев как устроена libssc.

Нет, ну так не очень подходит. Loki я стал рассматривать, потому что там это уже всё было. А тут получается нужно придумывать что-то, чтобы добиться необходимого результата. Как я тогда могу сравнить два подхода? Быстрый взгляд на исходники не дал положительного ответа на вопрос о наличии поддержки любых возвращаемых типов, помимо void.

Сигнал/слот, как я себе их представляю и то, что вижу в Вашем примере, подразумевают наследование от какого-либо базового объекта. Мне же нужен максимально независимый делегат. Наследование будет мешать в том проекте, которым я занят. Возможно позже сигнал/слоты понадобятся, но есть Qt. Тем не менее, для изучения принципа их подключения Ваша библиотека конечно подходит.