Частный случай механизма сигнал-слот

[m_ax]

Я вернулся))

Дополнил libssc сигнал-сигнальным соединением. Т.е. сейчас возможно соединять сигнал одного объекта (или просто сигнал) с иным сигналом:

Код

C++ (Qt)
#include <iostream>
#include "signal_slot.h"
#include <cmath>
 
using namespace std;
 
class A
{
public:
    ssc::signal<int, float> sig_a2;
 
    void run() const {
        sig_a2(4, 2.5);
    }
};
 
class B : public ssc::trackable
{
public:
    B() {}
 
    double slot_b2(double x, float y) {
        double res = pow(x, y);
        cout << "slot_b2, x^y = " << res <<  endl;
        return res;
    }
};
 
int main()
{
    ssc::signal<double, double> sig_test;
    B b;
    sig_test.connect(&b, &B::slot_b2);
 
    A a;
    a.sig_a2.connect(&sig_test);
 
    a.run();
    return 0;
}
 

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

[whitecemetery]

Огромное спасибо за библиотеку.
Пишу программы под микроконтроллеры в среде uVision, в которой даже STL корректно не поддерживается на некоторых моделях.
Раньше писал унылый низкоуровневый код, а потом надоело, плюс выдалась пауза в работе, начал писать с нуля библиотеку, в которой все, что нужно для работы - от контейнеров до виджетов. Интерфейсы, в основном, максимально близки к Qt-шным. Ну и понятное дело, как тема с виджетами поднялась, сразу понадобились сигналы-слоты. Любая готовая либа не подходит по своему размеру.
А эта в самый раз. Плюс очень здорово, что можно в данной теме отследить развитие с самого простого варианта(потому что в магии шаблонов я не силен пока).

[m_ax]

Огромное спасибо за библиотеку.
Пишу программы под микроконтроллеры в среде uVision, в которой даже STL корректно не поддерживается на некоторых моделях.
Раньше писал унылый низкоуровневый код, а потом надоело, плюс выдалась пауза в работе, начал писать с нуля библиотеку, в которой все, что нужно для работы - от контейнеров до виджетов. Интерфейсы, в основном, максимально близки к Qt-шным. Ну и понятное дело, как тема с виджетами поднялась, сразу понадобились сигналы-слоты. Любая готовая либа не подходит по своему размеру.
А эта в самый раз. Плюс очень здорово, что можно в данной теме отследить развитие с самого простого варианта(потому что в магии шаблонов я не силен пока).

Да не за что)
Планирую её перевести на c++11, там появилось несколько вкусных плюшек)
Да и архитектуру тож, наверное, можно будет слегка поправить)
Если что не понятно, пишите...   

[whitecemetery]

Пока все понятно. Сегодня переписал свой класс List-а, чтобы максимально соответствовал STL-ному, повозился со всякими предикатами, заменил List в библиотеке. Подключается, работает. : )
C++11 круто, но не думаю, что Keil его скоро начнет поддерживать. : )

[Igors]

Пока все понятно. Сегодня переписал свой класс List-а, чтобы максимально соответствовал STL-ному,

А в чем идея своего класса  List(а) ?

[m_ax]

Пока все понятно. Сегодня переписал свой класс List-а, чтобы максимально соответствовал STL-ному,

А в чем идея своего класса  List(а) ?

Минимализм)) Видимо, идея в полной независимости от stl..
Хотя странно, что если такая плохая поддержка stl и нет проблем с шаблонами..
Ведь libssc практически вся на шаблонах написана... 

[whitecemetery]

Проблема заключается в двух вещах:
1) для работы STL требуется определение низкоуровневых функций, связанных с вводом-выводом, для корректной работы(на некоторых вариантах микроконтроллеров просто подключаются два C файла с этими определениями, и все работает, но на других нет). Пробовал сделать это вручную топором, но не получилось. Почему не хочется в этом особо разбираться. Нас двое - человек, который паяет платы и пишет драйвера под процессоры, знает их устройство, регистры и т.п. И я, пишу конечные программы. Есть понятное желание у меня полностью абстрагироваться от конкретного процессора и писать все программы одинаково. У человека тоже есть желание не лазить по моему коду и не искать, где нужно еще какой-нибудь регистр переназначить. Через библиотеку это решается замечательно - мы договариваемся об интерфейсе каких-то устройств(дисплея, ацп, файловой системы, органов управления и т.д.), я закладываю абстрактные интерфейсы в библиотеку и навешиваю на них все, что хочу. А он пишет их реализацию под конкретное устройство.
Второй аспект - я пишу программы как под эти процессора, так и на компьютере, у них очень много совпадающих кусков кода. Хочется и там и там писать в одном стиле и не переделывать код из-за того, что что-то не поддерживается.
2) упомянутый минимализм. Ограничение по размеру кода.

Ну и пункт со звездочкой(засекречен =))
*3) повышение собственных знаний и навыков.

[m_ax]

Круто) Для меня всегда это было чем-то таким космическим (процессоры, микроконтроллеры, драйвера, регистры...)
Мой респект)

[m_ax]

Нашёл тут узкое место в реализации libssc, которое отрицательно на производительности сказывается..

Посему такой вопрос: Так ли уж необходимо такое свойство, как connection_priority, которое для каждого соединения определяет порядок его обработки? А т при каждом конекте приходится сортировать весь список соединений..
Или сортировать только один раз, перед вызовом самого сигнала.. Пока не решил, что с этим делать.. 

[Igors]

Проблема заключается в двух вещах:
1) для работы STL требуется определение низкоуровневых функций, связанных с вводом-выводом, для корректной работы(на некоторых вариантах микроконтроллеров просто подключаются два C файла с этими определениями, и все работает, но на других нет).

Никогда не слышал о таких низкоуровневых ф-циях

Ну и пункт со звездочкой(засекречен =))
*3) повышение собственных знаний и навыков.

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

[whitecemetery]

Посему такой вопрос: Так ли уж необходимо такое свойство, как connection_priority, которое для каждого соединения определяет порядок его обработки? А т при каждом конекте приходится сортировать весь список соединений..
Или сортировать только один раз, перед вызовом самого сигнала.. Пока не решил, что с этим делать..

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

Никогда не слышал о таких низкоуровневых ф-циях

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

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

Да, конечно. Помню, мне как-то подкинули задачу для интереса реализовать функцию abs() без условного оператора. Придумал пару вариантов, один из которых, по-моему, оказался быстрее библиотечной функции для VS компилятора, но безнадежно проиграл Intel-овскому.
Мне сейчас очень полезно оказалось, что нужно думать не с нуля о какой-то архитектуре(ведь ничто не мешает сделать ее ужасной), а есть интерфейс, придуманный и отшлифованный умными людьми, под который надо подстроиться.
Автор этой темы, по-моему, мыслил в том же ключе - хотя реализации сигналов-слотов присутствуют в большом количестве, почему бы не попробовать сделать свою, хорошо зная, какой у этого должен быть конечный вид. : )

Тестирую под VS, залез в autoexp.dat, настроил отображение своих контейнеров при отладке, вообще красота. : )

[m_ax]

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

Да, сортируется только при создании соединения.. Вообще то, если соединений на один сигнал порядка сотни то это особо не ощутимо.. Но если динамически, например в цикле, подрят создать порядка тысячи соединений на один сигнал, то задержка в пару сек наблюдается( (Ну на моём компе, во всяком случае) Может и фигня, но можно это ускорить..
К тому же при написании гуя, так или и иначе, при создании виджетов будут происходить автомаические соединения..
Да, кстати, а как вы гуй реализуете? Что то стороннее используете или как? Как там всё это у вас происходит?

Сделал несколько изменений в libssc. Сейчас работает чуть быстрее.
1) Переименовал две виртуальные функции в base_connection:
valid  на is_valid;
compare на is_same

2) Убрал полностью из signal сортировку. Сейчас всё это выглядит так: В функции connect:

Код

C++ (Qt)
bool connect(const ptr_base_connection &p) {
 
        int priority = p->priority();
        m_iterator position = m_list.begin();
 
        for (m_iterator it = m_list.begin(); it != m_list.end(); ++it) {
            if (p->is_same((*it).get()))
                return false;
 
            if (priority < (*it)->priority())
                ++position;
        }
        m_list.insert(position, p);
        return true;
    }
 

 
и в функции set_connection_priority:

Код

C++ (Qt)
bool set_connection_priority(const ptr_base_connection &p) {
        for (m_iterator it = m_list.begin(); it != m_list.end(); ++it) {
            if (p->is_same((*it).get()) && (*it)->is_valid()) {
                if ((*it)->priority() != p->priority()) {
                   m_list.erase(it);
                   connect(p);
                }
            return true;
            }
        }
        return false;
    }
 

Соответственно отпала необходимость в предикате (статической функции класса signal) compare.

Пока серьёзно не тестил, выкладываю как есть) Но скорость при создании соединений возросла. Если раньше при больших N она была пропорциональна N log N, то сейчас линейна по N (N - число соединений на один сигнал)




 

[whitecemetery]

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

Для меня такие количественные цифры нереальны. Поэтому, например, ту же сортировку в своей библиотеке я реализовал не быструю, а Шелла. У последней O(n^(7/6)), это до десятков-сотен тысяч элементов занимает меньше, чем O(n ln n). Впрочем, чтобы более надежно что-то утверждать, надо реализовать и то, конечно, и сравнить.
Я тут напрягался, что у меня в List-е гораздо больший косяк по производительности - добавление элементов занимает терпимое время, а вот при опереции Clear() на сотнях тысяч элементов происходит подвисание на три-четыре секунды, а взял, попробовал сравнить с std::list, у него такая же шняга. Оказалось, у меня проигрывает как раз по добавлению в несколько раз. Буду разбираться.

Да, кстати, а как вы гуй реализуете? Что то стороннее используете или как? Как там всё это у вас происходит?

Нет, я уже писал об этом. Желания и возможности реализовывать навороченный гуй нет. Да и как, если на наших дисплеях видно невооруженным взглядом, как прямоугольник размером с экран перерисовывается ? : )
Просто не хочется, чтобы отрисовка, обработка тачпада и основные события были разбросаны по программе как попало, вот и появилась идея с простейшими виджетами, которые сами себя перерисовывают, когда надо, и сами проверяют, жмякали по ним или нет, шлют события.

[m_ax]

Понятно)
Я просто к тому, что никакой необходимости сортировать список при создании соединения, на самом деле нет. Достаточно лишь при создании конекта вставлять его (соединение) в нужное место, чтоб они (соединения) всегда располагались по убыванию свойства priority. Что собственно и было сделано в последней версии. 

[Igors]

whitecemetery, мы тут с m_ax обсуждаем один не совсем банальный контейнер (хотя возможно в теории это есть, просто не нашли). http://www.prog.org.ru/index.php?topic=21385.msg148007#msg148007. Возможно Вам будет интересно поучаствовать