wxWidgets 2.7

>А что, QT даёт реально переносимый код? Т.е. кто-то на этом форуме может это лично подтвердить?

qmake && make

> redvasily (*) (12.08.2006 12:15:40)

Спасибо за аргументированный ответ.

> И что там? Первая же фраза в статье: "Signals and slots is a software design pattern introduced in Qt by the moc." Далее говорится, что эта схема эквивалентна паттерну Observer. Оправдания использования другой терминологии по сравнению с уже существующей там нет.

А с какой стати Qt должен перед тобой оправдываться? Может, они ещё должны принести извинения в письменной форме?

http://www.scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html

The terminology comes from Trolltech's implementation in Qt, which has used signals and slots since its initial public debut in 1994. The concept of signals and slots is so compelling that it has become a part of the computer science landscape; the pattern and terminology have been re-used again and again in various implementations. Signals and slots remain a key part of Qt's architecture; they have become fixtures in several other general purpose toolkits as well as a few popular libraries that exist solely to provide this machinery.

Так доступнее? Загляни в англо-русский словарь, найди там слово slot и долго думай, почему Qt использовала именно его. Кстати, изобретателю слова "робот" ты тоже иск вчинишь (посмертно)?

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

в моде Qt::QueuedConnection или Qt::AutoConnection (для сигналов вручаемых объектам, созданным в треде отличном от того, в котором сигнал испущен) вручение сигнала может быть отложено в очередь

http://doc.trolltech.com/4.2/qt.html#ConnectionType-enum

> в моде Qt::QueuedConnection или Qt::AutoConnection

В документации как-то расплывчато написано. Я правильно понял, что если указать Qt::QueuedConnection, то слот будет выполнен именно в том треде, в котором создан его хозяин?

> > И что там? Первая же фраза в статье: "Signals and slots is a software design pattern introduced in Qt by the moc." Далее говорится, что эта схема эквивалентна паттерну Observer. Оправдания использования другой терминологии по сравнению с уже существующей там нет.

> А с какой стати Qt должен перед тобой оправдываться? Может, они ещё должны принести извинения в письменной форме?

> http://www.scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html

> The terminology comes from Trolltech's implementation in Qt, which has used signals and slots since its initial public debut in 1994. The concept of signals and slots is so compelling that it has become a part of the computer science landscape; the pattern and terminology have been re-used again and again in various implementations. Signals and slots remain a key part of Qt's architecture; they have become fixtures in several other general purpose toolkits as well as a few popular libraries that exist solely to provide this machinery.

> Так доступнее? Загляни в англо-русский словарь, найди там слово slot и долго думай, почему Qt использовала именно его. Кстати, изобретателю слова "робот" ты тоже иск вчинишь (посмертно)?

тише-тише, не ссорьтесь гооооряааачииииеее эээстоооонскиииеээ паарниии :)

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

sendToPeer((*reinterpret_cast< int(*)>(_a[1])),(*reinterpret_cast< int(*)>(_a[2])),(*reinterpret_cast< int(*)>(_a[3])),(*reinterpret_cast< const QByteArray(*)>(_a[4]))); break;

из файла examples/network/torrent/.moc/debug-shared/moc_torrentclient.cpp

Сигналы Qt не имеют никакого отношения к асинхронному средству IPC называемому сигналы, как и слоты это просто удобное название.

>Не флейма ради, просто до кучи, еще один реальный пример >http://libsigc.sourceforge.net/

++
http://root.cern.ch/root/HowtoSignalSlot.html

да, по дефолту "в том треде, в котором создан его хозяин" (если под "хозяином" вы понимаете объект, для которого вызывается слот). Но, если event loop был поменян с помощью

void QObject::moveToThread ( QThread * targetThread )

http://doc.trolltech.com/4.2/qobject.html#moveToThread

то сигнал будет отложен и вызов слота произойдёт в event loop, принадлежащем targetThread. Кстати согласно определению Qt::AutoConnection (http://doc.trolltech.com/4.2/qt.html#ConnectionType-enum), если и сигнал вызван в targetThread, то слот будет вызван напрямую при испускании сигнала.

игрища с коммутацией могут привести к интересным "извращениям", мне, например, удалось встроить механизм отложенного выполнения в систему передачи сообщений с колбеками, имеющими один целочисленный параметр - флаг. Старая версия лежит тут: http://sourceforge.net/projects/atoqu/ Как соберусь, выложу последнюю версию где есть второй колбек (в старой у каждого объекта есть только один). Никакого интереса с точки зрения механизмов передачи сообщений эта либа не представляет, ёе tagret - реализация отложенного выполнения и ничего больше. Чтобы не быть голословным, помещу часть доки новой (не выложенной) версии:

Lazy Evaluation Engine Basics Lazy Evaluation Engine (LEE) component of Atoqu toolkit is described in the section.

Commonly used Observer design pattern lacks capability to organize nested structures of dependent objects and capability to provide synchronized notification/updating of dependent objects in such structures. A modified design pattern called LEE Observer (AQLeeObserver) is proposed to provide lacking capabilities. The described below implementation is based on pull approach as of propagation of data changes, i.e. all required data are to be queried by dependent observers.

The idea of lazy evaluation (deferred execution) is to remember new values (or changes) of parameters and to perform recalculation (evaluation) of dependent member-data by the values when dependent data are to be used, so if parameters are changed more frequently than dependent data are requested the number of recalculations is minimized.

A simple change of member-data in one observer (called below notifier) can cause changes in other observers (called below syncers). Moreover if syncers are notifiers for other syncers then cascades of changes must be performed in dependency graph order, so implementation of lazy evaluation must lighten developer's burden to trace and change states of dependent observers. This is the Lazy Evaluation Engine which solves the task.

LEE provides a way:

to keep state of each stateful observer by a set of boolean flags, to perform cascaded notification of syncers (called notifying) in dependence graph order about changes being performed in notifiers, to start cascaded evaluation of notifiers (called syncing) in dependence graph order when evaluation is requested. Attached observers share common parameters such as AQLee::NotifyMode, AQLee::ThreadMode, mutex in threaded mode and so on. The parameters are kept in a special structure called dependency graph and implemented as AQLeeDependencyGraph class. Each observer belongs to one and only one dependency graph. If two observers owned by different dependency graphs are attached then one of graphs is set for bouth observers and abandoned graph is deleted. Conversly if two observers with the same dependency graph are detached and no links more exist between observers (indirect links are checked too) then new dependency graph is created and set for one of observers and all observers attached to it.

из FAQ:

Q: At a first glance LEE looks like a kind of performance optimization. There are some ways to improve performance e.g. optimization with compiler and/or linker, instruction reordering and data caching in modern CPUs or optimization of data handling algorithms. Does LEE provide some unique kind of optimization? A: Yes it does. Automatic optimization based on static source code analysis has some limitations, e.g. non-trivial executables are linked with shared libraries and linker can't build code of shared library functions in executable because one of main features of shared objects (transparent replacing of compatible library versions) contradicts to the optimization. A dynamic automatic optimization can be used to remove this overhead as well as provide extra performance gain based on run-time information, e.g. modern CPUs can include a set of tricks like instruction reordering, read/write caching and branch prediction but there are strong restrictions in hardware on this kind of optimization like a limited size of instruction window, cache, statistics sample and complexity of algorithms implemented in hardware. As well automatic optimization can't replace manual one in all cases due to limited intelligence of optimization algorithms. Classic manual optimization requires from programmer to analyse algorithms/sources (and/or profiling information) and to change statically algorithms/code the data are handled by while LEE as a kind of manual optimization helps to reduce dynamically the number of needless computations during execution. So the classic approach helps to speed-up execution while approach implemented by LEE helps to make it more effective like instruction reordering does in very strong hardware restrictions. LEE is not the first implementation of the approach but enough clear and flexible.

если кому-нибудь интересно узнать подробности, добавлю:

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

новая версия вдобавок помогает разделить выполнение на две части, "внутреннюю" и "внешнюю" с целью задействования дополнительных cpu, "внутренняя" оперирует только внутренними и внешними, не связанными с другими объектами данными (какой-нибудь неразделяемый ресурс, например, дивайс с одним потребителем внутри процесса), "внешняя" может использовать другие объекты. "Внутренняя" запускается по notify, и поскольку никому не мешает, может быть запущена отдельным тредом на свободном cpu. "Внешняя" запускается по sync, который лочит все связанные объекты mutex'ом (если используется ThreadSafe мода) и ожидает завершения "внутренней" части каждого объекта перед выполнением его "внешней" части. Понятно, что задача разделения на эти две части может быть нетривиальна и облегчению программирования эта либа не способствует (в отличие от Qt'ишного signal-slot), её цель - попытка оптимизации в ран-тайм, если кто-нибудь плохо продумает реализацию и отстрелит себе ногу с её помощью, я ответственности за это не несу :)