Сигналы и область видимости

[naf2000]

А что в Qt сигналы могут быть только публичными? То есть кто угодно может подписаться на сигнал объекта?

[Пантер]

А смысл в непубличном сигнале?

[Robotex]

А можно свой сигнал создать?

[Пантер]

В своем классе сколько хочешь.

[Denjs]

А смысл в непубличном сигнале?

гм.... не задумывался пока вопрос не был задан.
т.е. "кто угодно может подписаться на сигнал объекта?" - это то верно, и правильно...
если в какой-то точке программы нам известны ссылка на 2 объекта - источник и приемник - то мы можем спокойно связать их через сигнал-слот,
даже если они "не видят друг друга" - главное что бы сигнатуры функций совпадали.
С этим все понятно.

Но давайте подумаем в другом направлении:

Сигналы реализуются в виде методов класса если не ошибаюсь... да?
а так-как они публичные, то получается, что "в принципе" "некто" может вызвать "принудительное испускание сигнала",
если он конечно знает ссылку на объект и метод "в который был реализован" описанный в секции "public signals" сигнал...
т.е. мы вызываем метод, и в итоге класс испускает сигнал...
в этом смысле мне действительно интереснее видет мои сигналы как "protected signals"... потому что сигналы, имхо, должен испускать обект только по собственной инициативе... так? не?

кто из опытных гуру может дать разъяснения по этому вопросу?

[Пантер]

Эм. Приведи пример как кто-то может вызвать твой сигнал.

[GreatSnake]

сигналы, имхо, должен испускать обект только по собственной инициативе... так? не?

Для чего вам нужны такие ограничения?

Эм. Приведи пример как кто-то может вызвать твой сигнал.

QMetaObject::invokeMethod()

[Denjs]

сигналы, имхо, должен испускать обект только по собственной инициативе... так? не?

Для чего вам нужны такие ограничения?

потому что идеологически - задача сигналов - информирование внешнего мира об изменении состояния объекта)))

Но на самом деле все хорошо)
В ходе игрищЪ понял, что
метод определенный в секции signals - он попадает в секцию protected.
(собственно это и есть ответ на первую часть вопроса топик-стартера)

Виноват. Смел сомневаться в Троллях.  тут был не прав.

signalsender.h

Код:

class signalsender: public QObject
{
    Q_OBJECT

public:
    signalsender();
signals:
    void mysig();
};

main.cpp

Код:

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    MainWindow w;

    signalsender *mySignalSender=new signalsender();
    QObject::connect(mySignalSender,SIGNAL(mysig()), &w,SLOT(mySigSenderRcv()));


    mySignalSender->mysig(); // <<------------- вот это не пройдет! )


    w.show();

    return a.exec();
}

при попытке сборки получаем отлуп :

..\signaltest\/signalsender.h: In function 'int qMain(int, char**)':
..\signaltest\/signalsender.h:12: error: 'void signalsender::mysig()' is protected
..\signaltest\main.cpp:14: error: within this context

Для особых экспериментаторов - соответсвующий проект в приложении.

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

[Waryable]

Если б вы могли извне приказать чужому классу дружить с вашим, тогда на первый взгляд проблем не было бы. Но это, к счастью, практически не возможно.

[Akon]

Сигналы находятся в области protected (Q_SIGNALS расширяется в protected) по 2-м причинам:
- не допустить явного вызова Q_EMIT foo.fooSignal(...);
- сигналы должны быть доступными для классов-наследников.

Касательно 1-й причины - ничто не мешает приконнектить внешний сигнал к сигналу fooSignal(...) и вызвать его.

[naf2000]

Чтобы из вне нельзя было повесить слот на сигнал или наоборот, удалить его