Russian Qt Forum

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

файл signal_slot.h

C++ (Qt)
#ifndef SIGNAL_SLOT_H
#define SIGNAL_SLOT_H
 
#include <list>
 
template <class T_receiver, class T_return, class T_arg>
class Slot
{
public:
    typedef T_return (T_receiver::*function_type_1)(T_arg);
    typedef T_return (T_receiver::*function_type_2)(const T_arg &);
    typedef T_return (T_receiver::*function_type_3)(T_arg) const;
    typedef T_return (T_receiver::*function_type_4)(const T_arg &) const;
 
 
    Slot(T_receiver *obj, function_type_1 slot);
    Slot(T_receiver *obj, function_type_2 slot);
    Slot(T_receiver *obj, function_type_3 slot);
    Slot(T_receiver *obj, function_type_4 slot);
 
    ~Slot();
 
    T_return operator() (const T_arg &arg);
 
private:
    Slot();
    function_type_1 _slot_1;
    function_type_2 _slot_2;
    function_type_3 _slot_3;
    function_type_4 _slot_4;
 
    T_receiver *_obj;
    int _index;
};
 
 
template <class T_receiver, class T_return, class T_arg>
inline Slot<T_receiver, T_return, T_arg>::Slot()
{
}
 
template <class T_receiver, class T_return, class T_arg>
inline Slot<T_receiver, T_return, T_arg>::Slot(T_receiver *obj, function_type_1 slot)
{
    _obj = obj;
    _slot_1 = slot;
    _index = 1;
}
 
template <class T_receiver, class T_return, class T_arg>
inline Slot<T_receiver, T_return, T_arg>::Slot(T_receiver *obj, function_type_2 slot)
{
    _obj = obj;
    _slot_2 = slot;
    _index = 2;
}
 
template <class T_receiver, class T_return, class T_arg>
inline Slot<T_receiver, T_return, T_arg>::Slot(T_receiver *obj, function_type_3 slot)
{
    _obj = obj;
    _slot_3 = slot;
    _index = 3;
}
 
template <class T_receiver, class T_return, class T_arg>
inline Slot<T_receiver, T_return, T_arg>::Slot(T_receiver *obj, function_type_4 slot)
{
    _obj = obj;
    _slot_4 = slot;
    _index = 4;
}
 
template <class T_receiver, class T_return, class T_arg>
inline T_return Slot<T_receiver, T_return, T_arg>::operator ()(const T_arg &arg)
{
    if (_index == 1)
       return (_obj->*_slot_1)(arg);
    if (_index == 2)
        return (_obj->*_slot_2)(arg);
    if (_index == 3)
        return (_obj->*_slot_3)(arg);
 
    return (_obj->*_slot_4)(arg);
}
 
 
template <class T_receiver, class T_return, class T_arg>
class Signal
{
public:
    typedef T_return (T_receiver::*function_type_1)(T_arg);
    typedef T_return (T_receiver::*function_type_2)(const T_arg &);
    typedef T_return (T_receiver::*function_type_3)(T_arg) const;
    typedef T_return (T_receiver::*function_type_4)(const T_arg &) const;
 
    Signal();
    ~Signal();
 
    void operator()(const T_arg &arg);
 
    void connect(T_receiver &obj, function_type_1 slot);
    void connect(T_receiver &obj, function_type_2 slot);
    void connect(T_receiver &obj, function_type_3 slot);
    void connect(T_receiver &obj, function_type_4 slot);
 
private:
    std::list<Slot<T_receiver, T_return, T_arg>* > _list;
    typedef typename std::list<Slot<T_receiver, T_return, T_arg>* >::iterator _iterator;
 
};
 
template <class T_receiver, class T_return, class T_arg>
inline Signal<T_receiver, T_return, T_arg>::Signal()
{
}
 
template <class T_receiver, class T_return, class T_arg>
inline Signal<T_receiver, T_return, T_arg>::~Signal()
{
    _list.clear();
}
 
template <class T_receiver, class T_return, class T_arg>
inline void Signal<T_receiver, T_return, T_arg>::connect(T_receiver &obj, function_type_1 slot)
{
    _list.push_back(new Slot<T_receiver, T_return, T_arg>(&obj, slot));
}
 
template <class T_receiver, class T_return, class T_arg>
inline void Signal<T_receiver, T_return, T_arg>::connect(T_receiver &obj, function_type_2 slot)
{
    _list.push_back(new Slot<T_receiver, T_return, T_arg>(&obj, slot));
}
 
template <class T_receiver, class T_return, class T_arg>
inline void Signal<T_receiver, T_return, T_arg>::connect(T_receiver &obj, function_type_3 slot)
{
    _list.push_back(new Slot<T_receiver, T_return, T_arg>(&obj, slot));
}
 
template <class T_receiver, class T_return, class T_arg>
inline void Signal<T_receiver, T_return, T_arg>::connect(T_receiver &obj, function_type_4 slot)
{
    _list.push_back(new Slot<T_receiver, T_return, T_arg>(&obj, slot));
}
 
template <class T_receiver, class T_return, class T_arg>
inline void Signal<T_receiver, T_return, T_arg>::operator ()(const T_arg &arg)
{
    for (_iterator it = _list.begin(); it != _list.end(); it++)
        (*it)->operator()(arg);
}
 
#endif // SIGNAL_SLOT_H
 

Краткое описание.

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

Класса Slot
Он фактически представляет из себя функторный класс, который биндит указатель на метод класса, который (метод) будет реализовывать слот.
Этот класс пользователь в своём коде явно нигде не использует. Он введён для удобства и используется классом Signal

Класс Signal объявлен как

C++ (Qt)
template <class T_receiver, class T_return, class T_arg> class Signal
 

где
T_receiver - это класс получатель
T_return - тип возвращаемого аргумента функции (слота)
T_arg - тип аргумента (слота и сигнала, соответственно)

Используется это так:

файл main.cpp

C++ (Qt)
#include <iostream>
#include <string>
 
#include "signal_slot.h"
 
 
template <class T>
class Sender
{
public:
    Sender() {}
    Signal<T, void, std::string> signal;
 
    void run() {
        signal("Hello word!");
    }
};
 
class Receiver
{
public:
    Receiver(){}
 
    void mySlot1(const std::string &str) {
        std::cout << "mySlot1 received a signal: " << str << std::endl;
    }
    void mySlot2(std::string str) {
        std::cout << "mySlot2 receiver a signal: " << str << std::endl;
    }
 
};
 
 
int main()
{
    Sender<Receiver> sender;
    Receiver receiver;
 
    sender.signal.connect(receiver, &Receiver::mySlot1);
    sender.signal.connect(receiver, &Receiver::mySlot2);
 
    sender.run();
 
    return 0;
}
 

Недостатком такого подхода является то, что общатся между собой могут лишь объекты тех классов, что указаны (в параметрах шаблона) при их создании. Т.е. в данном случае, объекты класса Receiver могут получать сигналы от объектов класса Sender. Но объекты класса Sender не могут слать сигналы объектам другого класса, если при определении класа Sender не указать дополнительный параметр шаблона и соответствующий сигнал с этим параметром.

Я пока не раскурил, как эта проблема решена, например в boost или в libsigc++  :(
Если кто подскажет, скажу спасибо)

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

Ещё такой вопрос: кто знает как присвоить указатель на метод одного класса к указателю на метод другого класса? И хорошо ли это?

В общем делаю это,  в первую очередь, чтоб разобраться со всем этим делом))   

архив с проектом прикреплён   

А чем boost::signal не устроил?

Вопрос носит чисто теоретический характер)

нет, это очень плохо, в частности из-за гемороя с указателями на виртуальные методы. Но есть другой путь. Можно хранить связанную пару объект-метод в виде boost::function. При этом boost::function требует только возвращаемый тип и типы аргументов, но не говорит какие классы сбайнженные с методами можно в него положить. Собственно библиотека сигналов это boost::function + накрутки. Как написать boost::function это отдельный вопрос. Накрутки это на первый взгляд не страшно, но на самом деле в них вся сложность. На тему можно почитать rationale в документации boost::signal, там очень наглядно разобрано что, как и зачем. После прочтения мне, например, расхотелось самому углубляться :).

Ну вот, так и знал))

Ладно, будем думать дальше)

boost::function

Спасибо)) Я кажысь раскурил как это всё можно реализовать)

Сейчас накатаю код, выложу

Вроде всё работает  :)

Теперь всё хорошо и работает так:

main.cpp

C++ (Qt)
#include <iostream>
#include <string>
#include "signal_slot.h"
 
class A
{
public:
    A() {}
    signal<void, std::string> my_signal;
 
    void run() {
        my_signal("Hello Word!");
    }
};
 
class B
{
public:
    B() {}
 
    void slot1(const std::string &str) {
        std::cout << "slot1, signal - " << str << std::endl;
    }
    void slot2(std::string str) const {
        std::cout << "slot2, signal - " << str << std::endl;
    }
};
 
int main()
{
 
    A a;
    B b;
 
    connect(&b, &B::slot1, &a.my_signal);
    connect(&b, &B::slot2, &a.my_signal);
 
    a.run();
 
    return 0;
}
 

Теперь всё как в Qt и только с использованием шаблонов  8)

Функция connect создаёт соединение между слотом объекта класса b и сигналом объекта a.
Сам сигнал представляет из седя шаблонный класс
template <class T_return, class T_arg> class signal
где
T_return - тип возвращаемого аргумента
T_arg - тип передаваемого аргумента

Если нужно чтобы ваш клас умел испускать сигналы необходимо просто включить класс сигнала в определение класса, как в примере:

C++ (Qt)
class A
{
public:
    A() {}
/*
Объявляем сигнал, который будет соеденён с функцией, которая возвращает void 
и принимает один аргумент std::string 
*/
    signal<void, std::string> my_signal;   
 
/*
В той функции, где необходимо вызвать сигнал, просто вызываем сигнал как обычную функцию  
*/                                    
    void run() {
        my_signal("Hello Word!");
    }
};
 

Сама реализация механизма сигнал-слот:

C++ (Qt)
#ifndef SIGNAL_SLOT_H
#define SIGNAL_SLOT_H
 
#include <list>
 
template <class T_return, class T_arg>
class base_signal
{
public:
    base_signal() {}
    virtual ~base_signal() {}
    virtual T_return operator() (const T_arg &) = 0;
};
 
template <class T_receiver, class T_return, class T_arg>
class manager_connection;
 
template <class T_return, class T_arg>
class signal
{
public:
    signal() {}
    ~signal() {
        for (_iterator it = _list.begin(); it != _list.end(); it++) {
            delete *it;
        }
        _list.clear();
    }
 
    T_return operator() (const T_arg &arg) {
        for (_iterator it = _list.begin(); it != _list.end(); it++) {
            (*it)->operator()(arg);
        }
    }
 
    template <class T1, class T2, class T3> friend class manager_connection;
 
private:
    std::list<base_signal<T_return, T_arg>* > _list;
    typedef typename std::list<base_signal<T_return, T_arg>* >::iterator _iterator;
 
    void connect(base_signal<T_return, T_arg> *_signal) {
        _list.push_back(_signal);
    }
};
 
template <class T_receiver, class T_return, class T_arg>
class manager_connection : public base_signal<T_return, T_arg>
{
public:
    typedef T_return (T_receiver::*function_type_1)(T_arg);
    typedef T_return (T_receiver::*function_type_2)(const T_arg &);
    typedef T_return (T_receiver::*function_type_3)(T_arg) const;
    typedef T_return (T_receiver::*function_type_4)(const T_arg &) const;
 
    manager_connection(T_receiver *obj, function_type_1 slot, signal<T_return, T_arg> *s) {
        _receiver = obj;
        _slot_1 = slot;
        _index = 1;
        s->connect(this);
    }
 
    manager_connection(T_receiver *obj, function_type_2 slot, signal<T_return, T_arg> *s) {
        _receiver = obj;
        _slot_2 = slot;
        _index = 2;
        s->connect(this);
    }
 
    manager_connection(T_receiver *obj, function_type_3 slot, signal<T_return, T_arg> *s) {
        _receiver = obj;
        _slot_3 = slot;
        _index = 3;
        s->connect(this);
    }
 
    manager_connection(T_receiver *obj, function_type_4 slot, signal<T_return, T_arg> *s) {
        _receiver = obj;
        _slot_4 = slot;
        _index = 4;
        s->connect(this);
    }
 
    ~manager_connection() {
    }
 
    T_return operator()(const T_arg &arg) {
        if (_index == 1)
            return (_receiver->*_slot_1)(arg);
        if (_index == 2)
            return (_receiver->*_slot_2)(arg);
        if (_index == 3)
            return (_receiver->*_slot_3)(arg);
        if (_index == 4)
            return (_receiver->*_slot_4)(arg);
 
        return T_return();
    }
 
private:
    T_receiver *_receiver;
    function_type_1 _slot_1;
    function_type_2 _slot_2;
    function_type_3 _slot_3;
    function_type_4 _slot_4;
    int _index;
    manager_connection() : _receiver(0), _index(0) {}
    manager_connection(const manager_connection &) {}
 
};
 
 
template <class T_receiver, class T_return, class T_arg>
void connect(T_receiver *obj, T_return (T_receiver::*slot)(T_arg), signal<T_return, T_arg> *s) {
    new manager_connection<T_receiver, T_return, T_arg>(obj, slot, s);
}
 
template <class T_receiver, class T_return, class T_arg>
void connect(T_receiver *obj, T_return (T_receiver::*slot)(const T_arg &), signal<T_return, T_arg> *s) {
    new manager_connection<T_receiver, T_return, T_arg>(obj, slot, s);
}
 
template <class T_receiver, class T_return, class T_arg>
void connect(T_receiver *obj, T_return (T_receiver::*slot)(T_arg) const, signal<T_return, T_arg> *s) {
    new manager_connection<T_receiver, T_return, T_arg>(obj, slot, s);
}
 
template <class T_receiver, class T_return, class T_arg>
void connect(T_receiver *obj, T_return (T_receiver::*slot)(const T_arg &) const, signal<T_return, T_arg> *s) {
    new manager_connection<T_receiver, T_return, T_arg>(obj, slot, s);
}
 
#endif // SIGNAL_SLOT_H
 

Архив с проектом прикреплён.

Уже симпатично выглядит. А что будет если объект 'b' разрушится (delete например), а потом 'a' испустит сигнал?

Известно что: грохинг программы  ;D

Я как раз курю на эту тему)) Если есть предложения буду рад выслушать.

m_ax, мои замечания - чисто субъективны, я не пытаюсь о чем-то авторитетно судить, делать выводы и.т.п.

Если возникнет вопрос "пользоваться этим или нет", то мой однозначный ответ "нет", и (возможно) я буду здесь совсем не один. Наверняка Вы сделали все правильно, но каждый template требует как-то "настроить мозги". То есть "врубиться" конечно можно, но это обходится недешево, это надо держать в памяти и не забывать. Когда программист сосредоточен на прикладном аспекте - это особенно болезненно. Нет желанной "простоты использования".

Еще раз - это мое субъективное мнение, не более того  :)

Отчасти я Вас понимаю, но с другой стороны не писать же с нуля весь инструментарий? Я например, как и многие другие использую Qt и я совсем не парюсь по поводу сколько там у них template или ещё чего. Я в исходники то их от силы раза 3-4 заглядывал)) Мне остаётся только довериться разработчикам)

Или Вы что-то другое имеете ввиду?
Просто в последним варианте, при использовании этого механизма никаких явных template писать уже не нужно, говорю ж всё максимально приближено к Qt варианту сигнал-слот.
Есть, тут правда ещё недопиленные места, но это детали..
 

Ну а зачем Вы выбрали тему которая уже известна, более того (в каком-то смысле "авторитетна")? Это, на мой взгляд, неразумно/непрактично. Ну посидеть пару вечерков конечно можно - но на этом дело кончится.

Да и что "такого уж хорошего" в ихней схеме слот/сигнал? Везде есть нормальное "sendEvent" (выполнить немедленно) и "postEvent" (засунуть в очередь). Нормальный программист легко этим пользуется, зачем это накручивать в виде MOC компилятора? В результате мы часто видим "месиво из сигналов" вместо нормального, логичного текста.

Ну во-первых лично моё имхо, механизм сигнал-слот - это очень удобная штука. И реализация в Qt это не единственная её реализация. Я не хочу сказать, что в Qt с помощью moc - это круто, напротив, вызов обходится дороже, чем например в схеме сигнал-слот в boost.

Во-вторых я предложил вариант сигнал-слот отличный от реализованного в Qt и отличный от реализации в boost::signal. (как правильно заметил brankovic в boost всё завязано на boost::function)
Это своего рода ещё одна вариация на тему)) И я считаю имеет право быть, хотя бы как объект теоретического исследования)
Короче,
Нет ничего практичнее хорошей теории))

В общем самое простое решение я вижу так:
Нужно разорвать соединение, если объект b разрушится.
Это можно сделать, если завернуть объект b в умный указатель, который занулит себя при уничтожении b. А поскольку этот указатель хранится в manager_connection
то перед тем как вызывать operator()() проверять его на валидность.
Как то так.. Сейчас попробую код накатать..   

У схемы qt есть и преимущества, но в контексте программирования их бессмысленно обсуждать. Потому что схема qt не програмисстская -- это бизнес-схема. Во времена создания qt не было _ни одного_ компилятора, который поддерживал бы шаблоны в полном объёме, и глючили они все по-разному. Кросс-платформенная библиотека основанная на шаблонах была бы обречена. Оставались макросы. Тролли решили, что moc выделит их из серой толпы макросовых фреймворков, и были по-своему правы.


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


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


Жил некогда Чжу, который учился убивать драконов.. :)

Но упражнение в любом случае полезное.

Дописал)

Теперь соединение автоматически разрывается, если один из объектов уничтожается.
Пришлось для этого писать свой умный указатель (smart_ptr), который следит за всем этим делом..
Зато получаем все плюшки автоматического удаления объектов  ;D

Все классы помещены в пространство имён ssc (от signal slot connection)
Базовые два класса это:
1) signal
2) smart_ptr

Используется так:

C++ (Qt)
#include <iostream>
#include <string>
#include "signal_slot.h"
 
class A
{
public:
    A() {
        std::cout << "A()" << std::endl;
    }
    ~A() {
        std::cout << "~A()" << std::endl;
    }
    ssc::signal<void, std::string> my_signal;
 
    void run() {
        my_signal("Hello Word!");
    }
};
 
class B
{
public:
    B() : _i(0) {
        std::cout << "B()" << std::endl;
    }
    B(int i) : _i(i) {
        std::cout << "B(int  i = " << _i << ")" << std::endl;
    }
    ~B() {
        std::cout << "~B();  i = " << _i << std::endl;
    }
 
    void slot1(const std::string &str) {
        std::cout << "slot1, signal - " << str << "  i = " << _i << std::endl;
    }
    void slot2(std::string str) const {
        std::cout << "slot2, signal - " << str << "  i = " << _i << std::endl;
    }
private:
    int _i;
};
 
int main()
{
    ssc::smart_ptr<A> a = new A;
    // A *a = new A;        можно и так, но придётся удалять руками
 
    //{  если раскомментировать, соединения автоматически разорвуться
 
        ssc::smart_ptr<B> p(new B(12));
    /*  B *b = new B(12)       а вот так можно, но в connect мы его не сможем засунуть
         поскольку connect хочет чтоб b был умным))    
    */
        connect(a->my_signal, p, &B::slot1);
        connect(a->my_signal, p, &B::slot2);
 
    //} см. выше
 
    a->run();
 
    return 0;
}
 

Исходники прилогаются. Прошу потестить, кому не лень. Возможно я где нить накасячил)
Конструктивная критика приветствуется)

 

smart_ptr просто ужасный:

1. деструктор и operator= должны вызывать общий метод destroy, чтобы их поведение было консистентным (в operator= вы забыли *valid=0, кроме того is_killer обнуляется и объект никто не удалит -- утечка памяти)

2. smart_ptr это симметричный объект, не может быть один "киллер", потому что если он погибнет раньше остальных, у других ptr-а не станет. Каждый владелец ptr может оказаться последним, "киллером".

По сигналу: теперь ресивера _обязательно_ заворачивать в smart_ptr?

Теперь обязательно, для того что бы при уничтожении receiver а разрывалось и соответствующее соединение.
Хотя есть и другой вариант как это сделать без использования smart_ptr.

Постараюсь объяснить логику этого указателя (для краткости в дальнейшем просто ptr):
ptr может быть либо киллером либо нет. У киллера есть право убить объект. Т.е. право убить объект принадлежит тому, кто первый им завладел. пример:

C++ (Qt)
smart_ptr<B> p1(new B); // p1 - киллер и убъёт объект
smart_ptr<B> p2 = p1; 
/* p2 - не имееет права убивать объект, он просто копирует указатель на 
на него. флаг _is_killer = false. Сам объект не клонируется.  */
 

Другая ситуация:

C++ (Qt)
smart_ptr<B> p1(new B); // p1 - киллер и убъёт объект
smart_ptr<B> p2(new B); // p2 - тоже киллер!
// Внимание фокус!
p2 = p1; /* Поскольку p2 - киллер он вначале убъёт объект на который ссылается, 
затем скопирует указатель на объект на который ссылается p1. 
Далее он сбросит флаг _is_killer = false и лишится права удалять объект, 
поскольку им уже владел до него p1 и владеет. 
Флаг _valid он скопирует также, и соответственно _valid == true, так что пока всё хорошо))  */
// А вот здесь: 
 
p1 = p2; /* Ничего не произойдёт, поскольку  operatop=() сначало проверяет не ссылаются
ли они на один и тот же объект. И если да (а в данном случае так и есть)
то return *this и всё.*/
 

Т.е. идея в том, что указателей на объект может быть много, но среди них только у одного есть право его убить. Каждый указатель может изменять данные объекта, но не клонировать его при этом. После того, как киллер  убъёт объект, все остальные смогут узнать об этом, за счёт флага _valid, который будет равен *_valid == false.
Кстати, вот он так и будет висеть и никто его никогда не удалит, но это 1 висячий байт... За то польза))


Если киллер умрёт, то он за одно убъёт и сам объект и зделает не валидными оставшиеся ptrЫ. Я такого поведения от него и добивался.

А как Вы видете это всё? Как по Вашему более правильно организовать логику?
Спасибо за обсуждение)  

Чем не нравится такой ptr:

1. утечка памяти (не удаляется valid)
2. туманная семантика (хотя тут я, возможно, просто мыслю шаблонами типа "должно быть как boost::shared_ptr")
3. не тред-сейф (легко исправить)

Почему бы не выкинуть is_killer и вместо bool is_valid не сделать int counter? Завладев указателем счётчик увеличиваем, потеряв его (через деструктор или operator=) счётчик уменьшаем. Последний владелец это тот, кто опустит счётчик до нуля, тогда можно удалить и счётчик и T.


как раз хочется другой вариант. smart_ptr всё равно понадобится, но чтобы спрятать его внутрь

operator= должен установить is_valid для p2 в ноль

Да, Вы правы, я малость перемудрил с ptr. Вариант с каунтером гораздо лучше.
У меня просто в голове крутилась идея что убить объект должен именно тот, кто им первым завладеет..

 
Другой вариант заклюсается в том, что мы создаём в класса receivera некий объект шпион, который будет следить за своим хозяином:

C++ (Qt)
class B
{
public:
    B() {}
 
    void slot1(const std::string &str) {
        std::cout << "slot1, signal - " << str << std::endl;
    }
    void slot2(std::string str) const {
        std::cout << "slot2, signal - " << str << std::endl;
    }
 
    ssc::spy spy;     // Вот этот объект. Его предназначение, следить за своим владельцем. 
 
private:
    int _i;
};
 

Но теперь, при создании соединения необходимо также передать ссылку на шпиона (млин, теперь в connect на один аргумент стало больше  >:( ) пример:

C++ (Qt)
int main()
{
    A *a = new A;
    B *b = new B(12);
 
    connect(a->my_signal, b, &B::slot1, b->spy);
    connect(a->my_signal, b, &B::slot2, b->spy);
 
    a->run();
 
    return 0;
}
 

Всё.. Если теперь удалить объект delete b то соединение разорвётся.

Сам шпион представляет из себя следующее:

C++ (Qt)
class spy
{
public:
    spy() : _valid(new bool(true)) {}
    ~spy() { *_valid = false; }
    bool operator()() const { return *_valid; }
    template <class T1, class T2, class T3> friend class manager_connection;
private:
    bool *_valid;
};
 

Хотя на первый взгляд, при уничтожении spy происходит утечка (остаётся висячим _valid) это не совсем так, поскольку его другом является manager_connection и соответственно имеет доступ к его закрытым членам и он ответственен за зачистку указателя _valid.
Теперь, при уничтожении хозяина: delete b, будет также вызван деструктор шпиона, который сделает: *_valid = false;
Но соединение с объектом b создано раньше и владеет указателем на _valid и поэтому всегда знает, что в данный момент происходит с b.

Следующий шаг - это наследование класса recivera от класса spy, вместо создания его экземпляра и можно переименовывать spy в trackble.  :)

А если делать это по простому/народному, не связываясь ни с какими указателями? Ну у объекта 2 контейнера указателей - кому он посылает и кто ему посылает. Деструкторы вычеркивают из этих контейнеров, оператор = может копировать контейнеры, а может и нет (как нравится). Ну "навести песики" типа

C++ (Qt)
class CMyClass : public CSignalReceiver, public CSignalSender {..
 

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

А что если я хочу посылать сигналы объектам разных классов и принимать сигналы от объектов разных классов? И не думать о том каким именно объектам мне слать и получать до того момента когда наступет нужда создать соединение (уже в самом пользовательском коде)? 

Переписал smart_ptr, как предложил brankovic
Вроде сейчас утечек нет:

C++ (Qt)
#ifndef SMART_PTR_H
#define SMART_PTR_H
 
namespace ssc {
 
template <class T>
class smart_ptr
{
public:
    smart_ptr();
    smart_ptr(const smart_ptr<T> &other);
    smart_ptr(T *p);
    ~smart_ptr();
 
    bool is_null() const;
    T* operator->() const;
    T& operator*() const;
    T* get() const;
 
    smart_ptr<T> &operator=(const smart_ptr<T> &p);
 
private:
    T *_obj;
    int *_counter;
 
    void try_destroy();
    smart_ptr<T> &operator=(T*);
};
 
template <class T>
inline smart_ptr<T>::smart_ptr()
    : _obj(0), _counter(0)
{
}
 
template <class T>
inline smart_ptr<T>::smart_ptr(const smart_ptr<T> &other)
    : _obj(other._obj), _counter(other._counter)
{
    if (_counter)
        (*_counter)++;
}
 
template <class T>
inline smart_ptr<T>::smart_ptr(T *p)
    : _obj(p), _counter(new int(1))
{
}
 
template <class T>
inline void smart_ptr<T>::try_destroy()
{
    if (!_obj)
        return;
 
    if ((*_counter) == 1) {
        delete _counter;
        _counter = 0;
        delete _obj;
        _obj = 0;
    }
}
 
template <class T>
inline smart_ptr<T>::~smart_ptr()
{
    try_destroy();
}
 
template <class T>
inline bool smart_ptr<T>::is_null() const
{
    return !_obj;
}
 
template <class T>
inline T* smart_ptr<T>::operator->() const
{
    return _obj;
}
 
template <class T>
inline T& smart_ptr<T>::operator*() const
{
    return *_obj;
}
 
template <class T>
inline T* smart_ptr<T>::get() const
{
    return _obj;
}
 
template <class T>
inline smart_ptr<T>& smart_ptr<T>::operator=(const smart_ptr<T> &p)
{
    if (_obj != p._obj) {
        try_destroy();
        _counter = p._counter;
        _obj = p._obj;
 
        if (_counter)
            (*_counter)++;
    }
    return *this;
}
 
template <class T>
inline smart_ptr<T>& smart_ptr<T>::operator=(T*)
{
    return *this;
}
 
template <class T>
inline bool operator==(const T *o, const smart_ptr<T> &p)
{
    return o == p.operator->();
}
 
template<class T>
inline bool operator==(const smart_ptr<T> &p, const T *o)
{
    return p.operator->() == o;
}
 
 
template <class T>
inline bool operator==(T *o, const smart_ptr<T> &p)
{
    return o == p.operator->();
}
 
template<class T>
inline bool operator==(const smart_ptr<T> &p, T *o)
{
    return p.operator->() == o;
}
 
template<class T>
inline bool operator==(const smart_ptr<T> &p1, const smart_ptr<T> &p2)
{
    return p1.operator->() == p2.operator->();
}
 
template <class T>
inline bool operator!=(const T *o, const smart_ptr<T> &p)
{
    return o != p.operator->();
}
 
template<class T>
inline bool operator!= (const smart_ptr<T> &p, const T *o)
{
    return p.operator->() != o;
}
 
 
template <class T>
inline bool operator!=(T *o, const smart_ptr<T> &p)
{
    return o != p.operator->();
}
 
template<class T>
inline bool operator!= (const smart_ptr<T> &p, T *o)
{
    return p.operator->() != o;
}
 
template<class T>
inline bool operator!= (const smart_ptr<T> &p1, const smart_ptr<T> &p2)
{
    return p1.operator->() != p2.operator->();
}
 
}
 
#endif // SMART_PTR_H
 

Как сделать теперь его тред-сейф ?

Так какой вариант: со шпионом (он же trackable в libsigc++) или через умные указатели использовать? Как идеалогически правильнее?

А в чем помеха? Объект создается с пустыми контейнерами sender'ов (receiver'ов), connect (который так или иначе неизбежен) их заполняет

Помеха в том, что в контейнере должны будут находится объекты одного класса.
Либо сделать один абстрактный класс, но тогда придётся писать интерфейс на все случаи жизни, что не есть гут)
Идея в том, что общаться могут объекты совершенно разных классов. Задаётся лишь общий шаблон функции сигнала и слота.

Или как Вы имеете в виду?

Вобщем остановился на варианте BRE: отнаследовать receiver от trackable (он же в прошлом spy), т.е. на схеме используемой в libsigc++.
Это означает, что объект который получает сигналы (receiver) должен быть отнаследован от класса trackable. trackable - автоматически разрывает соединение, если receiver будет уничтожен.

Выглядит это так:

C++ (Qt)
#include <iostream>
#include <string>
#include "signal_slot.h"
 
/* Класс A испускает сигналы */
class A
{
public:
    A() {}
 
    ssc::signal<void, std::string> my_signal;
 
    void run() {
        my_signal("Hello Word!");
    }
};
 
/* Класс B  содержит слоты, поэтому он должен отнаследоваться от trackable */
class B : public ssc::trackable
{
public:
    B() {}
 
    void slot1(const std::string &str) {
        std::cout << "slot1, signal - " << str << std::endl;
    }
 
    void slot2(std::string str) const {
        std::cout << "slot2, signal - " << str << std::endl;
    }
};
 
int main()
{
    B *b = new B;
    A *a = new A;
 
    connect(a->my_signal, b, &B::slot1);
    connect(a->my_signal, b, &B::slot2);
 
    a->run();
 
    delete b;
    delete a;
 
    return 0;
}
 

 

Сам механизм сигнал-слот здесь реализован по следующей схеме:
1) Класс base_signal:

C++ (Qt)
template <class T_return, class T_arg> class base_signal
 

Чисто абстрактный класс, реализующий интерфейс:

C++ (Qt)
virtual T_return operator() (const T_arg &) const = 0;
virtual bool valid() const = 0;
 

2) Класс signal:

C++ (Qt)
template <class T_return, class T_arg> class signal
 

Знает о всех соединениях со слотами: имеет список (std::list) соединений (manager_connection) являющихся потомками base_signal.
Имеет перегруженный оператор

C++ (Qt)
T_return operator() (const T_arg &arg) const
 

 
в котором перебирается весь список соединений и для каждого объекта manager_connection вызывается свой переопределённый virtual T_return operator() (const T_arg &) const.

3) Класс manager_connection:

C++ (Qt)
template <class T_receiver, class T_return, class T_arg>
class manager_connection : public base_signal<T_return, T_arg>
 

наследуется от класса base_signal и реализует весь функционал.

4) Класс trackable и trigger:

C++ (Qt)
class trigger
{
public:
    trigger() : _flag(true) {}
    void set(bool flag) { _flag = flag; }
    bool get() const { return _flag; }
 
private:
    bool _flag;
};
 
class trackable
{
public:
    trackable() {
        spy = smart_ptr<trigger>(new trigger);
    }
    virtual ~trackable() {
        spy->set(false);
    }
    smart_ptr<trigger> spy;
};
 

trigger - простой класс имеющий два состояния: true - receiver жив, false - уничтожен
Класс trackable - обёртка над trigger, причём trigger заворачивается в умный указатель, который знает сколько других указателей ссылаются на объект. smart_ptr уничтожит объект если число ссылок counter == 1.
manager_connection также содержит

C++ (Qt)
private:
    T_receiver *_receiver; // указатель на receiver
    smart_ptr<trigger> _spy; // шпион, он же trackable
    ...
 

При вызове одного из 4 конструктора  manager_connection происходит следующее:

C++ (Qt)
manager_connection(signal<T_return, T_arg> &s, T_receiver *obj, function_type_4 slot) {
        _receiver = obj;  // копируем указатель
        _spy = _receiver->spy;  /* копируем шпиона, который вкурсе что происходит с receiverОМ 
                                                по средством функции bool get() const */
        _slot_4 = slot;
        _index = 4;
        s.connect(this);  // Заносим данное соединение в список соединений нашего сигнала 
    }
 

 

Конечно, в пользовательском коде реально используется только два класса: signal и trackable
и ещё один из вариантов перегруженной функции connect:

C++ (Qt)
template <class T_receiver, class T_return, class T_arg>
void connect(signal<T_return, T_arg> &s, T_receiver *obj, T_return (T_receiver::*slot)(T_arg)) {
    new manager_connection<T_receiver, T_return, T_arg>(s, obj, slot);
}
 

в которой просто создаётся объект manager_connection и передаются все аргументы.

Как то так..
 
Выкладываю для тестирования файл проекта.
Немного причесал код, сейчас вроде всё работает адекватно))
 

Обобщил решение))

Теперь при создании объекта signal в классе который будет его имитеть, нужно лишь указать один шаблонный аргумент - T_art:

C++ (Qt)
class A : public ssc::trackable
{
public:
    A(){}
 
    ssc::signal<std::string> my_signal;  /* вот здесь указываем [b]только[/b] 
                                                                 тип передаваемого арг:  std::string */
 
    void run() {
        my_signal("Hello Word!");   // эмитем сигнал
    }
 
};
 

Соединятся сигнал может с любой функцией, представимой в виде:

C++ (Qt)
    typedef T_return (T_receiver::*function_type_1)(T_arg);
    typedef T_return (T_receiver::*function_type_2)(const T_arg &);
    typedef T_return (T_receiver::*function_type_3)(T_arg) const;
    typedef T_return (T_receiver::*function_type_4)(const T_arg &) const;
 

 

Т.е. в дальнейшем всё как обычно:

C++ (Qt)
class B : public ssc::trackable
{
public:
    B() {}
 
    void slot1(const std::string &str) {
        std::cout << "slot1, signal - " << str << std::endl;
    }
 
    int slot2(std::string str) const {
        std::cout << "slot2, signal - " << str << std::endl;
        return 123;
    }
};
 
int main()
{
    B *b = new B;
    A *a = new A;
 
    connect(a->my_signal, b, &B::slot1);
    connect(a->my_signal, b, &B::slot2);
 
    a->run();
 
    delete b;
    delete a;
 
    return 0;
}
 

Исходники прилагаются.

И вновь обобщил решение))

Теперь с сигналом могут соединятся не только методы класса, но и обычные функции:

C++ (Qt)
int my_func(const std::string &str) {
    std::cout << str << std::endl;
    return str.size();
}
 
class A
{
public:
 
    ssc::signal<std::string> my_signal;
 
    void run() {
        my_signal("Hello Word!");
    }
};
 
int main()
{
    B *b = new B;
    A *a = new A;
 
    connect(a->my_signal, b, &B::slot1);
    connect(a->my_signal, b, &B::slot2);
    connect(a->my_signal, my_function);  // Соединение с обычной функцией
 
    a->run();
 
    delete b;
    delete a;
 
    return 0;
}
 

Далее я изменил название основных классов:
Основным абстрактным классом соединения, предоставляющем интерфейс теперь является

C++ (Qt)
template <class T_arg>
class base_connection
{
public:
    base_connection() {}
    virtual ~base_connection() {}
    virtual void operator() (const T_arg &) const = 0;
    virtual bool valid() const = 0;
};
 

вместо base_signal, что правильнее отражает суть и предназначение этого класса

Соответственно класс signal теперь содержит список всех своих соединений base_connection

C++ (Qt)
std::list<base_connection<T_arg>* > _list;
 

Класс manager_connection переименован в mem_func_connection:

C++ (Qt)
template <class T_receiver, class T_return, class T_arg>
class mem_func_connection : public base_connection<T_arg>
 

и предназначен для создания соединений с методами класса

Появился новый класс func_connection

C++ (Qt)
template <class T_return, class T_arg>
class func_connection : public base_connection<T_arg>
 

перназначенный для создания соединения с обычными функциями

Соответственно появились версии перегруженных функций connection для соединения сигнала с обычными функциями.

Исходники приатачены, прошу потестить.

Решил дополнить функционал, добавив
1) функцию disconnect, которая бы разрывала соединение
2) В самом соединении connect, вначале проверять, есть ли в списке уже зарегистрированное такое же соединение и если есть, то не вносить его повторно в список.

Но столкнулся с маленькой проблемкой.  Суть которой в следующем:
Поскольку список соединений содержит указатели на объекты base_connection - предоставляющим интерфейс соединения, то манипуляции все происходят через его интерфейс.
Т.е. это означает, что я например, мог бы определить например функцию address в базовой реализации:

C++ (Qt)
template <class T_arg>
class base_connection
{
public:
    base_connection() {}
    virtual ~base_connection() {}
    virtual void operator() (const T_arg &) const = 0;
    virtual bool valid() const = 0;
    virtual long address_obj() const = 0; /* Вот эта новая функция, которая, к примеру,  
                                                                   будет возвращать адрес объекта receivera */
    virtual long address_mem_func() const = 0; /* А это адрес функции (слота) */
};
 

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

А вот пример реализации этих функция в mem_func_connection:

C++ (Qt)
long mem_func_connection::address_obj() const
{
    return (long)_receiver; // _receiver - это указатель
}
long mem_func_connection::address_mem_func() const
{
    return (long)&_slot; /* _slot - принадлежитодному из 4 типов: 
                                        typedef T_return (T_receiver::*_function_type_1)(T_arg); (N = 1, 2, 3, 4) 
                                        typedef T_return (T_receiver::*_function_type_2)(T_arg) const;
                                        ...
*/
}
 

Но меня мучают сомнения в корректности реализации address_mem_func() const
Хотя формально всё работает..
Дело в том, что как выяснилось sizeof(long) и sizeof(function_type_N) (N = 1,2,3,4) различаются, причём последний в два раза больше чем размкер long.  

Как быть? Куда копать?
Спасибо за помощь)

Надо же, проект цветёт и колосится! Наискосок просмотрел, похоже на полную победу сил разума.

Про connect, может вместо address сделать так:

C++ (Qt)
 
template <typename T>
class base_connection
{
  virtual bool operator== (base_connection const &) const = 0;
};
 
template <typename T, typename Obj, typename Method>
class custom_connection : public base_connection <T>
{
   Obj *o;
   Method m;
 
   bool operator== (base_connection <T> const &b) const
   {
      custom_connection *c = dynamic_cast <custom_connection *> (&b);
      return c && c->o == o && c->m == m;
   }
};
 
 

если я правильно понял проблему..

P.S.: про шаред птр -- его трудно сделать полностью тред-сейф, но чтобы он стал не хуже бустовского, нужно заменить ++counter и --counter на атомарные ++ и --. В кьют это будет QAtomicInt, а в gcc есть __sync_fetch_and_add для такого.

Спасибо)) Это именно то что нужно :)
Сейчас сделаем)

Так, сделал по совету brankovic: определил оператор

C++ (Qt)
template <class T_arg>
class base_connection
{
public:
    base_connection() {}
    virtual ~base_connection() {}
    virtual void operator() (const T_arg &) const = 0;
    virtual bool valid() const = 0;
    virtual bool operator==(base_connection<T_arg> *) const = 0;  // Вот этот оператор
};
 

И всё заработало, но.. Но работает только так:

C++ (Qt)
class signal
{
public:
    signal() {}
    ~signal() {
        for (_iterator it = _list.begin(); it != _list.end(); it++) {
            delete *it;
        }
        _list.clear();
    }
 
    void operator() (const T_arg &arg) const {
        for (_const_iterator it = _list.begin(); it != _list.end(); it++) {
            if ((*it)->valid())
                (*it)->operator()(arg);
        }
    }
 
    template <class T1, class T2, class T3> friend class mem_func_connection;
    template <class T1, class T2> friend class func_connection;
 
private:
    std::list<base_connection<T_arg>* > _list;
    typedef typename std::list<base_connection<T_arg>* >::iterator _iterator;
    typedef typename std::list<base_connection<T_arg>* >::const_iterator _const_iterator;
 
    void connect(base_connection<T_arg> *c) {
        for (_iterator it = _list.begin(); it != _list.end(); it++) {
            if (c->operator ==(*it)) {  /* Вот здесь приходится явно вызывать operator==(...) 
                                                          а если просто c == *it то не сработывает :(   Где подвох?
                                                          я сейчас немного не в состоянии думать))                   */
                delete c;
                return;
            }
        }
        _list.push_back(c);
    }
};
 

Вот полный код signal_slot.h

C++ (Qt)
#ifndef SIGNAL_SLOT_H
#define SIGNAL_SLOT_H
 
#include <list>
#include "smart_ptr.h"
#include <iostream>
 
namespace ssc {
 
template <class T_arg>
class base_connection
{
public:
    base_connection() {}
    virtual ~base_connection() {}
    virtual void operator() (const T_arg &) const = 0;
    virtual bool valid() const = 0;
    virtual bool operator==(base_connection<T_arg> *) const = 0;
};
 
 
class trigger
{
public:
    trigger() : _flag(true) {}
    void set(bool flag) { _flag = flag; }
    bool get() const { return _flag; }
 
private:
    bool _flag;
};
 
class trackable
{
public:
    trackable() {
        spy = smart_ptr<trigger>(new trigger);
    }
    virtual ~trackable() {
        spy->set(false);
    }
    smart_ptr<trigger> spy;
};
 
template <class T_arg>
class signal
{
public:
    signal() {}
    ~signal() {
        for (_iterator it = _list.begin(); it != _list.end(); it++) {
            delete *it;
        }
        _list.clear();
    }
 
    void operator() (const T_arg &arg) const {
        for (_const_iterator it = _list.begin(); it != _list.end(); it++) {
            if ((*it)->valid())
                (*it)->operator()(arg);
        }
    }
 
    template <class T1, class T2, class T3> friend class mem_func_connection;
    template <class T1, class T2> friend class func_connection;
 
private:
    std::list<base_connection<T_arg>* > _list;
    typedef typename std::list<base_connection<T_arg>* >::iterator _iterator;
    typedef typename std::list<base_connection<T_arg>* >::const_iterator _const_iterator;
 
    void connect(base_connection<T_arg> *c) {
        for (_iterator it = _list.begin(); it != _list.end(); it++) {
            if (c->operator ==(*it)) {
                delete c;
                return;
            }
        }
        _list.push_back(c);
    }
};
 
template <class T_return, class T_arg>
class func_connection : public base_connection<T_arg>
{
public:
    typedef T_return (*function_type_1)(T_arg);
    typedef T_return (*function_type_2)(const T_arg &);
 
    func_connection(signal<T_arg> &s, function_type_1 slot) {
        _slot_1 = slot;
        _index = 1;
        s.connect(this);
    }
 
    func_connection(signal<T_arg> &s, function_type_2 slot) {
        _slot_2 = slot;
        _index = 2;
        s.connect(this);
    }
 
    void operator()(const T_arg &arg) const {
        if (_index == 1) {
            (*_slot_1)(arg);
            return;
        }
        if (_index == 2) {
            (*_slot_2)(arg);
            return;
        }
    }
 
    bool valid() const {
        return true;
    }
 
    bool operator==(base_connection<T_arg> *bc) const {
        func_connection<T_return, T_arg> *fc = dynamic_cast<func_connection<T_return, T_arg>* >(bc);
        if (fc) {
            if (_index == 1)
                return (fc->_slot_1 == _slot_1);
            if (_index == 2)
                return (fc->_slot_2 == _slot_2);
        }
        return false;
    }
 
private:
    function_type_1 _slot_1;
    function_type_2 _slot_2;
    int _index;
    func_connection();
    func_connection(const func_connection &);
};
 
template <class T_receiver, class T_return, class T_arg>
class mem_func_connection : public base_connection<T_arg>
{
public:
    typedef T_return (T_receiver::*function_type_1)(T_arg);
    typedef T_return (T_receiver::*function_type_2)(const T_arg &);
    typedef T_return (T_receiver::*function_type_3)(T_arg) const;
    typedef T_return (T_receiver::*function_type_4)(const T_arg &) const;
 
    mem_func_connection(signal<T_arg> &s, T_receiver *obj, function_type_1 slot) {
        _receiver = obj;
        _spy = _receiver->spy;
        _slot_1 = slot;
        _index = 1;
        s.connect(this);
    }
 
    mem_func_connection(signal<T_arg> &s, T_receiver *obj, function_type_2 slot) {
        _receiver = obj;
        _spy = _receiver->spy;
        _slot_2 = slot;
        _index = 2;
        s.connect(this);
    }
 
    mem_func_connection(signal<T_arg> &s, T_receiver *obj, function_type_3 slot) {
        _receiver = obj;
        _spy = _receiver->spy;
        _slot_3 = slot;
        _index = 3;
        s.connect(this);
    }
 
    mem_func_connection(signal<T_arg> &s, T_receiver *obj, function_type_4 slot) {
        _receiver = obj;
        _spy = _receiver->spy;
        _slot_4 = slot;
        _index = 4;
        s.connect(this);
    }
 
    void operator()(const T_arg &arg) const {
        if (_index == 1) {
            (_receiver->*_slot_1)(arg);
            return;
        }
        if (_index == 2) {
            (_receiver->*_slot_2)(arg);
            return;
        }
        if (_index == 3) {
            (_receiver->*_slot_3)(arg);
            return;
        }
        if (_index == 4) {
            (_receiver->*_slot_4)(arg);
            return;
        }
    }
 
    bool valid() const {
        return _spy->get();
    }
 
    bool operator==(base_connection<T_arg> *bc) const {
        mem_func_connection<T_receiver, T_return, T_arg> *mfc = dynamic_cast<mem_func_connection<T_receiver, T_return, T_arg> *>(bc);
        if (mfc && (mfc->_receiver == _receiver)) {
            if (_index == 1)
                return (mfc->_slot_1 == _slot_1);
            if (_index == 2)
                return (mfc->_slot_2 == _slot_2);
            if (_index == 3)
                return (mfc->_slot_3 == _slot_3);
            if (_index == 4)
                return (mfc->_slot_4 == _slot_4);
        }
        return false;
    }
 
private:
    T_receiver *_receiver;
    smart_ptr<trigger> _spy;
    function_type_1 _slot_1;
    function_type_2 _slot_2;
    function_type_3 _slot_3;
    function_type_4 _slot_4;
    int _index;
    mem_func_connection();
    mem_func_connection(const mem_func_connection &);
};
 
template <class T_return, class T_arg>
void connect(signal<T_arg> &s, T_return (*slot)(T_arg)) {
   new func_connection<T_return, T_arg>(s, slot);
}
 
template <class T_return, class T_arg>
void connect(signal<T_arg> &s, T_return (*slot)(const T_arg &)) {
    new func_connection<T_return, T_arg>(s, slot);
}
 
template <class T_receiver, class T_return, class T_arg>
void connect(signal<T_arg> &s, T_receiver *obj, T_return (T_receiver::*slot)(T_arg)) {
    new mem_func_connection<T_receiver, T_return, T_arg>(s, obj, slot);
}
 
template <class T_receiver, class T_return, class T_arg>
void connect(signal<T_arg> &s, T_receiver *obj, T_return (T_receiver::*slot)(const T_arg &)) {
    new mem_func_connection<T_receiver, T_return, T_arg>(s, obj, slot);
}
 
template <class T_receiver, class T_return, class T_arg>
void connect(signal<T_arg> &s, T_receiver *obj, T_return (T_receiver::*slot)(T_arg) const) {
    new mem_func_connection<T_receiver, T_return, T_arg>(s, obj, slot);
}
 
template <class T_receiver, class T_return, class T_arg>
void connect(signal<T_arg> &s, T_receiver *obj, T_return (T_receiver::*slot)(const T_arg &) const) {
    new mem_func_connection<T_receiver, T_return, T_arg>(s, obj, slot);
}
 
}
 
#endif // SIGNAL_SLOT_H
 
 

не

virtual bool operator==(base_connection<T_arg> *) const = 0;

а

virtual bool operator==(base_connection<T_arg> const &) const = 0;

мы же хотим сравнивать объект и другой объект, а не объект и указатель.

Понял в чём баг..
Но в самой вункции connect  я сравниваю именно указатели

C++ (Qt)
void connect(base_connection<T_arg> *c) {
        for (_iterator it = _list.begin(); it != _list.end(); it++) {
            if (c == *it) {
                delete c;
                return;
            }
        }
        _list.push_back(c);
 

Может здесь целесообразнее объявить функцию сравнения указателей?
Например:

C++ (Qt)
virtual bool compare(base_connection<T_arg> *) const = 0;
 

А какой в этом смысл?

В смысле?
Я должен их сравнивать, чтобы не дублировать соединения.. Если в списке уже имеется такое же соединение то и нефиг его туда вновь заносить..
Потом, мне нужно в саму функцию compare я передаю указатель и если соединение уже создано ранее, то я уничтожаю текущее.\
Или я чего то не понммаю?

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

И может указатели:

C++ (Qt)
    function_type_1 _slot_1;
    function_type_2 _slot_2;
    function_type_3 _slot_3;
    function_type_4 _slot_4;
 

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

Это да, но я сейчас ввёл функцию compare:

C++ (Qt)
template <class T_arg>
class base_connection
{
public:
    base_connection() {}
    virtual ~base_connection() {}
    virtual void operator() (const T_arg &) const = 0;
    virtual bool valid() const = 0;
    virtual bool compare(base_connection<T_arg> *) const = 0;
};
 

которая сравнивает не сами указатели на соединения непосредственно указатели на receiverОв и указатели на функции классов: (вот пример её реализации в классе mem_func_connection)

C++ (Qt)
bool compare(base_connection<T_arg> *bc) const {
        mem_func_connection<T_receiver, T_return, T_arg> *mfc = dynamic_cast<mem_func_connection<T_receiver, T_return, T_arg> *>(bc);
        if (mfc && (mfc->_receiver == _receiver)) {
            if (_index == 1)
                return (mfc->_slot_1 == _slot_1);
            if (_index == 2)
                return (mfc->_slot_2 == _slot_2);
            if (_index == 3)
                return (mfc->_slot_3 == _slot_3);
            if (_index == 4)
                return (mfc->_slot_4 == _slot_4);
        }
        return false;
    }
 

аналогично и в случае func_conection:

C++ (Qt)
bool compare(base_connection<T_arg> *bc) const {
        func_connection<T_return, T_arg> *fc = dynamic_cast<func_connection<T_return, T_arg>* >(bc);
        if (fc) {
            if (_index == 1)
                return (fc->_slot_1 == _slot_1);
            if (_index == 2)
                return (fc->_slot_2 == _slot_2);
        }
        return false;
    }
 

и теперь в самой функции connect (класс signal):

C++ (Qt)
void connect(base_connection<T_arg> *c) {
        for (_iterator it = _list.begin(); it != _list.end(); it++) {
            if (c->compare(*it)) {
                delete c;
                return;
            }
        }
        _list.push_back(c);
    }
 

Такой вариант работает, я проверял))
Хорошая идея, спасибо)

Замени

C++ (Qt)
...
if (_index == 1)
...
 

на

C++ (Qt)
...
switch(_index) {
}
...
 

а то всё забываешь  :)

Сделал)
Список изменений:
1) Ввёл в базовый класс (base_connection) функцию compare замещающую функции operator==()
2) Объединил указатели на функции в union
3) Заменил все if (_index) ... на switch(_index)
4) Дополнил функционал функцией disconnect, которая возвращает true если соединение было удачно разорвано и false  в противном случае. Также теперь bool возвращают и функции connect - true в случае успешного соединения, false - в противном случае.
5) По мелочи: причесал код...

Исходники для тестирования прилагаются.

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

Я тут внёс ещё одно изменение, которое не отражается на интерфейсе сигнала, но так думаю, будет более нагляднее: изменил в base_connection

C++ (Qt)
virtual void operator()(const T_arg &) const = 0
 

на

C++ (Qt)
virtual void handle_evant(const T_arg &) const = 0;
 

приаттачеваю на последок исходники release версии

Всем спасибо)

Выявил тут один баг, когда внедрял эту штуку в програмку..
Вобщем возникала проблема, при использовании типа void

C++ (Qt)
class A
{
public:
    ssc::signal<void> sig;
};
 

Сигнал sig - соединяется с функциями которые возвращают T_return и не имеют аргументов:

C++ (Qt)
class B : public ssc::trackable
{
public:
    int slot() const {   // Вот например с такой функцией
        return 123;
    }
};
 

Сейчас проблема решена с помощью специализации шаблонов на тип void..
Кстати, такой приём в стандартной библиотеке применён и для std::vector<bool>  

Исходники прилагаются

Млин! Ещё одна опечатка выявилась, которая приводит к утечке :
В файле smart_ptr.h в методе try_destroy():

C++ (Qt)
template <class T>
inline void smart_ptr<T>::try_destroy()
{
    if (!_obj)
        return;
 
    if ((*_counter) == 1) {
        delete _counter;
        _counter = 0;
        delete _obj;
        _obj = 0;
    }
}
 

Забыл уменьшить счётчик _counter
Правильно так:

C++ (Qt)
template <class T>
inline void smart_ptr<T>::try_destroy()
{
    if (!_obj)
        return;
 
    if ((*_counter)-- == 1) {
        delete _counter;
        _counter = 0;
        delete _obj;
        _obj = 0;
    }
}
 

Изменил архитектуру ssc
Теперь сигнал может принимать два аргумента и связываться с функциями вида:

C++ (Qt)
// не методы класса
T_return (*fun_type)(T_arg1, T_arg2);
T_return (*fun_type)(T_arg1);
T_return (*fun_type)();
 
// методы класса
T_return (T_receiver::*mem_fun_type)(T_arg1, T_arg2);
T_return (T_receiver::*const_mem_fun_type)(T_arg1, T_arg2) const;
T_return (T_receiver::*mem_fun_type)(T_arg1);
T_return (T_receiver::*const_mem_fun_type)(T_arg1) const;
T_return (T_receiver::*mem_fun_type)();
T_return (T_receiver::*const_mem_fun_type)() const;
 

Сам интерфейс практически не изменился, пример:

C++ (Qt)
#include <iostream>
#include <string>
#include "signal_slot.h"
 
void func(const std::string &str) {
    std::cout << "func slot: " << str << std::endl;
}
 
class A
{
public:
    A() {
        std::cout << "A()" << std::endl;
    }
    ~A() {
        std::cout << "~A()" << std::endl;
    }
 
    ssc::signal<const std::string &> sig_fun;  /* теперь нужно тип аргумента расписывать подробно!
                                                                       И чтоб он в точности соответствовал арг. слота  */
    ssc::signal<int> sig_1;
    ssc::signal<const std::string &, int> sig_2;
 
    void run() const {
        sig_fun("Hello!");
        sig_1(2011);
        sig_2("Hello World!", 1234567);
    }
};
 
class B : public ssc::trackable
{
public:
    B() {
        std::cout << "B()" << std::endl;
    }
    ~B() {
        std::cout << "~B()" << std::endl;
    }
 
    void slot1(int x) const {
        std::cout << "slot1: x = " << x << std::endl;
    }
    int slot2(const std::string &str, int x) const {
        std::cout << "slot2: " << str << "  x = " << x << std::endl;
        return 67;
    }
};
 
int main()
{
    A *a = new A;
    B *b = new B;
 
    connect(a->sig_fun, func);
    connect(a->sig_1, b, &B::slot1);
    connect(a->sig_2, b, &B::slot2);
 
    a->run();
 
    delete a;
    delete b;
    return 0;
}
 

P.S. Valgrind сказал, что утечек нет))