Russian Qt Forum

1. Вот в качестве примера:
Нужно ли из этих паблик методов делать слоты? Или сделать слотом лучше только cellChange?
Понятно, что можно и вообще не делать слотов(или делать только те, что нужны именно в данном проекте). И только при  надобности либо изменять существующий класс, либо наследоваться.
Но все же как решить нужен слот или нет?
Я смотрел в Assistantе QWidget. Некоторые методы не понятно по какому принципу попали в слоты и наоборот-некоторые методы почему-то не попали. Опять же, чем руководствовались разработчики?

2. Почти тот же вопрос и по сигналам. Когда нужно делать сигнал?

3. Некоторые слоты возвращают значение. Я правильно понимаю, что в концепции сигнал-слот это значение роли не играет и никак не может быть использовано? Оно используется только если данный метод-слот вызывать чисто как метод?

Спасибо за внимание!

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

3 да, да.

Спасибо.
По первым двум пунктам: Так вот, что же делать если я класс планирую использовать дальше?
Хотя бы на моем примере покажите, что следовало бы сделать слотом и почему?
А класс я сделал Grid(с прорисовкой на виджете).  Grid может пригодиться везде, поэтому его дальнейшее использование может быть любым( игра Life, монохромное рисование...).

Все слотами сделай :) и будет счастье!

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

А впринципе какая разница? Это же никаких расходов не несет, а добавляет "+ " в то что метод можно будет с сигналом связать! (ИМХО) :)

1. слоты удобны там, где их можно соединить с актуальным сигналом (например, triggered -> setEnabled, close -> quit). если в обозримом окружении не наблюдается сигнала с параметрами "const int, const int, const bool [, ...]", то cellChange делать слотом мало смысла. (кстати, const int в параметрах - шибко перестрахованно...на мой взгляд); либо там, где предполагается какая-то польза от асинхронного вызова (например, update)

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

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

3. нет.
при синхронном вызове (либо асинхронном с ожиданием (что почти одно и то же)) можно получить результат работы метода так же, как и для вызова обычной функции, но через метаобъектную систему.
Юрий, опять "ай-ай-ай" :)
не знал, что можно написать

C++ (Qt)
int iResult = emit obj->pleaseStartSomethingAndReturnStatusCode();
 

? :)

2kuzulis
Даже если так, остается вопрос с Сигналами. Их придется дополнительно дописывать. Расход времени, если на то пошло. Хотя, я не уверен что слоты выполняются так же быстро как и методы.
2Константин
Спасибо. Стало понятней, хотя написано немного запутанно=)
Зато по сигнатуре сразу видно, что параметр внутри не меняется. Хотя, он и так не изменится. Но все равно, зачем-то же ввели такую возможность в язык.
Насколько я знаю в слотах нельзя использовать параметры по умолчанию.
Честно говоря, я этого не понял. Есть ощущение, что это из разряда извращений, и простым смертным такое не нужно в подавляющем числе задач.

qthelp://com.trolltech.qt.442/qdoc/signalsandslots.html
./src/corelib/kernel/qobjectdefs.h

> # define Q_SIGNALS protected
блин, так и думал, что кто-нибудь заметит :)
просто нужно было показать, что это член класса, а расписывать было лениво...

3. да, это в некоторой степени можно расценивать как извращение. но иногда можно и воспользоваться извращением, если это облегчает жизнь :) /* правда, сам я пока ещё не пользовался _этим_ "извращением" */

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

Странно, но в книге Макса Шлее( страница 45 ) написано:

Сигнал:

Слот:

Да, да, это я уже понял.
Просто я не верно поставил акцент
Странно, НО в книге Макса Шлее( страница 45 ) написано
->
Странно ТО, что в книге Макса Шлее( страница 45 ) написано
Вроде хорошая книжка, и такой косяк.

что-то примера я не понял. Получается, что когда выполнится связанный с сигналом "pleaseStartSomethingAndReturnStatusCode" слот, возвращающий значение, тогда в "iResult" поместится значение возвращенное слотом?

А нигде не написано что это сигнал ;)

C++ (Qt)
#ifndef QT_NO_EMIT
# define emit
#endif

зачем же тогда писать "emit" ?

для moc-а :)

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

+ для наглядности.

Я сейчас даже для boost-сигналов пишу:
/*emit*/ signalName( ... );
Сразу понимаешь, что происходит.

Совершенно верно уже сказали - для наглядности.

вообще такое поведение для меня открытие. Хотя, пожалуй, и бесполезное.

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

не торопись называть его бесполезным )
к примеру, возможность получить результат в invokeMethod - весьма полезная штука (и очень жаль, что не работает для асинхронных вызовов с ожиданием. т.е. даже не пытается узнать ответ, хотя от синхронного вызова в этом плане не отличается)
мне кажется, что пример с ret = emit ... - это как бы побочный эффект...но специально этим вопросом не озадачивался.

Оно действительно бесполезно как все недокументированные фичи и любой workaround. Пользуясь этим, всегда нужно помнить, что это работает только при синхронных вызовах, или что тролли могут в любой момент поменять поведие moc'а - и просто ничего не возвращать. НИКОГДА НЕЛЬЗЯ делать  временных решений - они как правило перерастают в постоянные, которые нужно сопровождать и поддерживать, причем другим разработчикам.

тут я говорил про invokeMethod. это часть апи и ввиду бинарной совместимости возврат значений просуществует по-крайней мере до 5.0

А что произойдет, если сигнал pleaseStartSomethingAndReturnStatusCode() оработают два или более слотов? Какое значение получим в результате?

Не проверял, но думаю от последнего отработанного слота.

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

раза два уже сказал, пользоваться следует именно invokeMethod.

Где можно прочитать по-русски что такое invokeMethod?

На кроссплатформе в переводах нету?

2 pastor, пока нету