Об излучении и переизлучении сигналов

[Alp]

Не смог придумать лучшего перевода для emit/re-emit.

Хочу спросить вашего совета, как лучше делать:
- Класс испускает сигнал iAmDying
- Его "родитель" этот сигнал ловит и в слоте излучает свой сигнал childDying, в параметрах которого указывает на себя и индекс потомка в коллекции (закрытая).
- Сигнал родителя кто-то где-то использует.

Вопрос: как логичнее оформить сигнал iAmDying
- как iAmDying(QChild* childPtr), в предке излучать childDying(this, collection.indexOf(childPtr))?
или
- как iAmDying(), в предке излучать childDying(this, collection.indexOf(sender()))?

Вопрос в известной степени о вкусах различных фломастеров разного цвета, но интересно что считается более qt-way? =)

[niXman]

Не понял разницу между вашими вариантами.

[Alp]

Не понял разницу между вашими вариантами.

Код

C++ (Qt)
class A
{
signals:
    void updated(A*);    //!!!!!!
};
 
class B
{
    QVector<A*> coll;
 
protected slots:
    void OnAUpdated(A* a)    //!!!!!!
    {
        emit reemited(this, coll.indexOf(a));    //!!!!!!
    }
 
signals:
    void reemited(B*, int indexA);
}
 

Код

C++ (Qt)
class A
{
signals:
    voide updated();    //!!!!!!
};
 
class B
{
    QVector<A*> coll;
 
protected slots:
    void OnAUpdated()    //!!!!!!
    {
        emit reemited(this, coll.indexOf( sender() ));    //!!!!!!
    }
 
signals:
    void reemited(B*, int indexA);
}
 

Помечено комментириями. Разница тут исключительно в эээ... стилистике что ли.

В классе B все элементы коллекции коннектятся на слот, разумеется.

[niXman]

Я бы использовал QSignalMapper. Причина...эээ...стиль

[lit-uriy]

а зачем себя передавать в качестве аргумента?
ведь есть же sender(), который вернёт указатель на объект пославший сигнал.

[niXman]

Ну.. sender() - не совсем правильное решение. Для таких нужд, троли создали QSignalMapper. ИМХО удобнее.

[Alp]

а зачем себя передавать в качестве аргумента?
ведь есть же sender(), который вернёт указатель на объект пославший сигнал.

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

[Igors]

Вопрос в известной степени о вкусах различных фломастеров разного цвета, но интересно что считается более qt-way? =)

Встречный вопрос: а Вы этим на работе занимаетесь или дома?

[Alp]

Вопрос в известной степени о вкусах различных фломастеров разного цвета, но интересно что считается более qt-way? =)

Встречный вопрос: а Вы этим на работе занимаетесь или дома?

Я этим не занимаюсь, но вообще на работе.
Собственно, я удачно начал этим заниматься пару месяцев назад - объяснил руководителю, что писать UI под инду и под мак прощзе один раз, а не два.

[lit-uriy]

alp, а зачем вообще класс/объект пересыльщик?

[Alp]

alp, а зачем вообще класс/объект пересыльщик?

Дело в том, что те, кто подписываются на сигналы класса B ничего не знают (и не должны знать) о его внутренней структуре. Есть интерфейс обмена данными, а свой лайаут виджет А обновляет сам в соответствии с этими самыми данными.

[Igors]

alp, а зачем вообще класс/объект пересыльщик?

Дело в том, что те, кто подписываются на сигналы класса B ничего не знают (и не должны знать) о его внутренней структуре. Есть интерфейс обмена данными, а свой лайаут виджет А обновляет сам в соответствии с этими самыми данными.

Обозначим

A - источник сигнала
B - ре-эмиттер
C - получатель/подписчик

Путь сигнала A->B->C.  Получается что "B" знает всех (A и C). Без разницы "C" подписывается сам - или "B" подписывает его. А если так, то почему бы не поручить тому же "B" установить прямой коннект A->C? Не вижу никакого выигрыша в пере-испускании если ничего содержательного "B" с сигналом не делает

[Alp]

alp, а зачем вообще класс/объект пересыльщик?

Дело в том, что те, кто подписываются на сигналы класса B ничего не знают (и не должны знать) о его внутренней структуре. Есть интерфейс обмена данными, а свой лайаут виджет А обновляет сам в соответствии с этими самыми данными.

Обозначим

A - источник сигнала
B - ре-эмиттер
C - получатель/подписчик

Путь сигнала A->B->C.  Получается что "B" знает всех (A и C). Без разницы "C" подписывается сам - или "B" подписывает его. А если так, то почему бы не поручить тому же "B" установить прямой коннект A->C? Не вижу никакого выигрыша в пере-испускании если ничего содержательного "B" с сигналом не делает

А с какого перепугу В знает про С?? В просто переизлучает сигнал и кто на него подпишется - дело не его =) Здесь знание друг друга как раз такое, как ты нарисовал - однонаправленное, только направлено в другую сторону.

[Igors]

А с какого перепугу В знает про С?? В просто переизлучает сигнал и кто на него подпишется - дело не его =)

А каким образом C "подпишется"? Чтобы сделать connect источник нужно знать, значит как минимум указатель на B нужно подавать в C. То есть C знает B - никак не лучше. Зависимости никуда не исчезают при использовании сигналов. Хотя конечно - выглядит красиво/идейно

[Alp]

А с какого перепугу В знает про С?? В просто переизлучает сигнал и кто на него подпишется - дело не его =)

А каким образом C "подпишется"? Чтобы сделать connect источник нужно знать, значит как минимум указатель на B нужно подавать в C. То есть C знает B - никак не лучше. Зависимости никуда не исчезают при использовании сигналов. Хотя конечно - выглядит красиво/идейно

Я понял, что ты имеешь вы виду. Конечно, раз С использует сигналы, в которых упоминается А*, то, конечно по А он знает. Точнее, он знает про некоторый интерфейс обмена данными и все.