Використання emit vs виклику сигналу так, ніби це звичайна функція в Qt

Скажімо, я маю такий сигнал:

signals:
    void progressNotification(int progress);

Я нещодавно дізнався про ключове слово emit у Qt. До цього часу я виконував сигнали, просто викликаючи їх як звичайну функцію. Отже, замість:

emit progressNotification(1000 * seconds);

Я б написав:

progressNotification(1000 * seconds);

Викликати їх так здавалося, працювало, і всі підключені слоти виконувались, тож використання ключового слова emit спричиняє іншу поведінку, чи це просто синтаксичний цукор?

emitце просто синтаксичний цукор. Якщо ви подивитесь на попередньо оброблений вихід функції, яка випромінює сигнал, ви побачите, що emitїї просто немає.

"Чарівність" відбувається в сформованому коді для функції випромінювання сигналу, на який ви можете подивитися, перевіривши код C ++, згенерований moc.

Наприклад, fooсигнал без параметрів генерує цю функцію-член:

void W::foo()
{
    QMetaObject::activate(this, &staticMetaObject, 0, 0);
}

І код emit foo();попередньо обробляється простоfoo();

emitвизначається в Qt/qobjectdefs.h(у будь-якому випадку у відкритому джерелі джерела), наприклад:

#ifndef QT_NO_EMIT
# define emit
#endif

( no_keywordsЗахисник дефініції - дозволити вам використовувати Qt з іншими фреймворками, що мають імена, що стикаються, за допомогою опції налаштування QMake.)

Через 18 місяців ... Я почав із коментарів під відповіддю @ Mat, і швидко закінчився номер. Таким чином відповідь.

ІМО emitне є ні синтаксичним цукром, ні простим ключовим словом у тому сенсі

1. Він генерує код (як пояснив @Mat вище),
2. Це допомагає connectмеханізму визнати, що насправді це є signal, і
3. Це робить ваш сигнал частиною "більшої" системи, де сигнали та відповіді (слоти) можуть виконуватися синхронно або асинхронно, або в черзі, залежно від того, де і як сигнал випромінювався. Це надзвичайно корисна функція системи сигнал / слот.

Вся система сигнал / слот - це інша ідіома, ніж простий виклик функції. Я вважаю, що це випливає із моделі спостерігачів. Також існує велика різниця між a signalі a slot: сигнал не повинен бути реалізований, тоді як слот повинен бути !

Ви йдете вулицею і бачите палаючий будинок (сигнал). Ви набираєте номер 911 ( підключіть сигнал пожежі до гнізда відповіді 911 ). Сигнал був лише випущений , тоді як слот був реалізований пожежною службою. Можливо, це неточно, але ви зрозуміли ідею. Давайте розглянемо приклад OP.

Деякий серверний об'єкт знає, наскільки успішно досягнуто. Тож це могло просто emit progressNotification(...)сигналізувати. Клас, який відображає фактичну індикацію прогресу, повинен взяти цей сигнал і виконати на ньому. Але як подання підключається до цього сигналу? Ласкаво просимо до системи сигналів / слотів Qt. Тепер можна уявити клас менеджера (як правило, віджет сортів), який складається з об’єкта подання та об’єкта обчислення даних (обидва вони QObjectsможуть бути ) connect (m_myDataEngine, &DataEngine::progressNotification, m_myViewObj, &SimpleView::displayProgress).

Не будемо вдаватися до аспектів дизайну класу менеджера, але достатньо сказати, що саме тут світить система сигналів / слотів. Я можу зосередитись на розробці дуже чистої архітектури для мого додатка. Не завжди, але часто буває, я виявляю, що я просто видаю сигнали, але реалізую слоти .

Якщо можливо використовувати / викликати метод сигналу, ніколи його не видаючи , то це обов'язково означає, що вам ніколи не була потрібна ця функція як сигнал .

Другий варіант означав би, що ви завжди знаєте, що таке ім'я функції та параметри функції, і що об'єкт, до якого ви його надсилаєте, відомий саме цією функцією. Ці два випадки не завжди відповідають дійсності, тому це дві основні речі, чому були створені слоти та сигнали. "під капотом" механізм сигналу і слота - це просто таблиця з покажчиками на кожну функцію, яка підключена.

Крім того, подивіться на цей pdf, який дуже чітко пояснює природу механізму сигналів і слотів: http://www.elpauer.org/stuff/a_deeper_look_at_signals_and_slots.pdf