использование connect при наследовании классов

[Vld2]

Код:

Class AA 
{
 public:
  go();
  readMessage();
};

AA::go()
{
 connect(pushButton, ... , SLOT(readMessage));
}

class BB :public AA
{
 readMessage();
};

int main()
{
 BB obj;
 obj.go();
}

Если сработает сигнал, то функция readmessage какого класса сработает? По идеи AA, а как сделать так чтобы именно класса ВB?

[pastor]

Сделать слот readmessage виртуальным?

[ритт]

сделать АА::readMessage виртуальным?

зы. стиль написания охеренный...до этого на пых-пыхе писал? )

[Mikhail]

сделать АА::readMessage виртуальным?

зы. стиль написания охеренный...до этого на пых-пыхе писал? )

Естественно, виртуальным.

[Red Devil]

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

[ритт]

кстати, да...и тролли тоже всегда так делают

в данном случае самое очевидное не есть самое правильное

[pastor]

В какой-то книге писалось, что при использовании с сигналах и слотах виртуальной функции производительность на несколько порядков меньше.

А вы не помните в какой книге это писалось? (Интересно читануть что нить по этому поводу)

[uriel]

Если не изменяет память, то читал это у Шлее в книге по Qt4. Только там не так много нового по сравнению с тем же ассистентом, на самом деле.

[Alex03]

В какой-то книге писалось, что при использовании с сигналах и слотах виртуальной функции производительность на несколько порядков меньше.

А вы не помните в какой книге это писалось? (Интересно читануть что нить по этому поводу)

+1 Нельзя ли текст оттуда...
Если заглянуть в любой moc_srcname.cpp то там есть функция

Код:

int ClassName::qt_metacall(QMetaObject::Call _c, int _id, void **_a)

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

[Alex03]

Как пример

Код:

        case 9: setVisible((*reinterpret_cast< bool(*)>(_a[1]))); break;
        case 10: setHidden((*reinterpret_cast< bool(*)>(_a[1]))); break;

из moc_qwidget.cpp.
setVisible - виртуальный метод, setHidden - нет.

[ритт]

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

[Hort]

... Слоты могут быть и виртуальными.
Примечание
По данным фирмы Trolltech, соединение сигнала с виртуальным слотом
примерно в десять раз медленнее, чем с невиртуальным. Поэтому не стоит
делать слоты виртуальными, если нет особой необходимости.

это из книги Макса Шлее.

[pastor]

это из книги Макса Шлее.

http://doc.trolltech.com/4.4/signalsandslots.html

You can also define slots to be virtual, which we have found quite useful in practice.

Compared to callbacks, signals and slots are slightly slower because of the increased flexibility they provide, although the difference for real applications is insignificant. In general, emitting a signal that is connected to some slots, is approximately ten times slower than calling the receivers directly, with non-virtual function calls.

Где тут говориться про то что коннект к виртуальнм слотам медленее? Шлее жжот. Поправьте если я неправ

[ритт]

либо переводчик отжёг, либо шлее

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

[Vld2]

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