Привет всем.
Хочу составить письмо с предложением в nokia. Английский знаю, но боюсь ошибиться (да и форумный разум составит более корректно)
А предложение следующее:
Во всех форумах (не только на vingrad) очень частый вопрос - не коннектится сигнал к слоту, а причина - почти всегда одна и та же: не убрали (при копировании) формальный параметр в макросе SIGNAL или SLOT. 
Предложение же следующее: пусть функция connect/disconnect будет чуть-чуть "поумнее", и сама вырежет определение формальных параметров

P.S. Кстати, куда лучше отправить письмо с предложением ? (поручик - молчать 

поясните...

очень часто в форумах задаётся вопрос типа: не работает сигнал/слот, вот мой код

при этом connect не будет работать, т.к. нужно было убрать formal_parameter_name из макроса SIGNAL. IMHO совершенно не сложно сделать это внутри функции connect. Под "совершенно не сложно сделать" я имею ввиду разработчиков Qt, конечно.

borisbn, ах вот вы о чем.
я все же склонен полагать, что это целиком обязанность программиста.

Вообще у них об этом в документации сказано. Не пойму откуда можно скопировать код, который заведомо не будет работать:



Мета-объектный компилятор это не полноценный компилятор типа C++, он не собирает информацию о пользовательских типах, поэтому информацию "int value" можно трактовать точно также как и возможное определение типа "int &", "int *"

Это сообщение отредактировал(а) SABROG - 5.4.2010, 09:37

boostcoder, 

согласен. пускай это будет обязанность программиста из Nokia 


SABROG, 

нет. я предлагаю, чтобы внутри функции connect имя аргумента убиралось бы из сигнатуры сигнала. Т.е. чтобы функция connect работала бы примерно следующим образом:


Это сообщение отредактировал(а) borisbn - 5.4.2010, 10:08

Пожалуйста


хотя и полностью согласен с

azesmcar, спасибо.

и всё же, разрешите немного по-hollywar'ить 
boostcoder, azesmcar, почему вы считаете, что умная функция connect хуже, чем каждый раз вручную удалять имена формальных параметров после копирования сигнатуры слота из h-ника ?

Это сообщение отредактировал(а) borisbn - 5.4.2010, 10:04

borisbn

Я вообще считаю что эти сигнал/слоты надо выкинуть из Qt и сделать по человечески, как в boost.
По вопросу - без имени формальных параметров код будет чище и красивее. Пусть учатся убирать.

Это сообщение отредактировал(а) azesmcar - 5.4.2010, 10:07

Сделайте, git репозиторий открыт для всех. Только ваш патч никто не примет. Сигналы boost не идеальны, как минимум они не поддерживают асинхронности и динамического подключения в runtime.

По теме. Предложите патч для moc компилятора или просто читайте документацию.

Это сообщение отредактировал(а) SABROG - 5.4.2010, 10:50

я никогда не пишу имя аргумента в декларации.


солидарен. изврат полный.
к чему дополнительная кодогенерация? при том, сигнал/слот, по своему существу, это объекты. тролли же, извратили эту идею полностью. непонятно во имя чего?!

плюсов, я не вижу ни одного.
а минусов, как минимум два.

зачем мне это? платить мне за это никто не будет, так зачем тратить свое время?


что же тогда сказать о сигналах Qt? Все на макросах, малейшая ошибка и либо сигнал не ловится, либо программа вылетает. Никаких ошибок компиляции, сиди и ищи где что-то пропустил.

нет ничего идеального  


кютешные сигналы/слоты, тоже. потому они обрабатываются в очереди событий(или как это в Qt зовется?). точно так же, это реализуется и с бустовыми сигналами, очередь обрабатывает boost::asio::io_service. реализовано, проверенно, работает.


приведите пример когда это необходимо? или когда это единственный способ решить задачу?

Все ошибки сыпятся в консоль во время выполнения.


.ui форма передается через сокет, правила соединения тоже в виде текстовой информации. Связывание происходит на клиентской машине.


Может быть тогда вам лучше изучить Qt, чем браться её обвинять?


Покажите мне пример, где 2 объекта находящихся в разных потоках общаются между собой посредством boost::signals2 и boost::asio::io_service. Один объект посылает сигнал другому, не дожидаясь выполнения завершает свою работу, второй объект продолжает выполнять долгую задачу, например на секунд 10. Тогда я отстану.

Вот именно. Но если это спор - то бессмысленный, я нв думаю что вы не считаете сигналы Qt идеальными. Я не говорил об использовании boost, я лишь сказал "сделать по человечески, как в boost". Это просто мое мнение, я не жалуюсь. Я считаю сигналы в Qt реализовали плохо.

Это сообщение отредактировал(а) azesmcar - 5.4.2010, 11:15

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

Ок.


Тролли сами советуют использовать тот же паттерн Observer, если система сигналов-слотов не удовлетворяет.

Статья старая и в ней еще не сравнивается boost::signals2, но большинство написанного правда: http://web.archive.org/web/20070703100120/...-and-slots.html

Плюс вы забываете почему Qt не может использовать boost'овское подобие сигналов и слотов на основе шаблонов:

Why Doesn't Qt Use Templates for Signals and Slots?

Это сообщение отредактировал(а) SABROG - 5.4.2010, 11:39

Мне кажется это проблема новичков в Qt. Я давно уже за собой таких ошибок не наблюдаю. 

честно говоря аргументы не убедили

давно уже не видел таких компиляторов..такое можно было сказать лет 5-6 назад, но никак не сейчас.
Им что, надо чтобы Qt компилировался под Borland C++ 3.1? Я думаю этим можно спокойно пожертвовать во имя красоты кода и дизайна, но это мое мнение.

Это сообщение отредактировал(а) azesmcar - 5.4.2010, 13:36

вообще бред полнейший 
ощущение такое, что Qt-программисты, вообще не используют шаблоны.
вот вы попробуйте в качестве слота, указать функциональный объект созданный при помощи std::bind(), или лямбда выражение?!  
а как без этого писать?! как же метапрограммирование, boost.mpl?!
в итоге, во имя своей сигнал/слотовой модели, они отрубили большую часть С++. настоящего С++ !...эх...


Это сообщение отредактировал(а) boostcoder - 5.4.2010, 13:43

вот именно, новичков. ведь полно же вопросов: "у меня не коннектятся сигналы со слотами ..."
почему бы не сделать им жизнь проще.
ведь сделали же они, например, в QDir::entryList параметр QDir::NoDotAndDotDot


интересно, откуда такое ощущение ? У меня весь сетевой обмен построен на шаблонах. Одно другому не мешает. Да, в сигнал/слотах их использовать нельзя. IMHO с таким ограничением но с такой библиотекой, как Qt, жить можно 


никто ничего не отрубал. я использовал boost в приложениях на Qt.

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

boostcoder, а вы шутник. Функциональщина - да, это "настоящий с++". Очень смешно, спасибо.

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

У меня успешно используется и boos::bind в Qt приложении. Но, естественно, не в качестве слотов. Даже если бы была такая возможность, я бы не стал её использовать. Потому что мешать boost::bind и qt::connect это просто неверно с т.з. архитектуры. Каша какая-то получается. А так всё прекрасно, никто не отменял функторы и Q_OBJECT в своих классах. qt specific и boost specific разделены.

А вообще Qt-шные сигнал-слоты хороши своей чрезвычайной динамичностю. В бусте же они статически прибиты гво^Wшаблонами.

А если с переводом на русский?

не понял, о чем речь?


естественно. даже если бы захотели 


связыватели и сигналы/слоты, разные по идее. что общего? о чем речь?


?

пора переносить в религиозные войны.

про метапрограммирование создатели Qt не слышали 
и аргументация детская какая-то.

Добавлено через 53 секунды
да, пора сворачивать дискуссию.

Добавлено через 5 минут и 13 секунд
похожий вопрос уже обсуждался здесь: http://forum.vingrad.ru/index.php?showtopi...t&p=2113889

OK, вы все, вместе с троллями, меня убедили. Я им в JIRA написал. И вот ответ:

совсем другое дело  

Омг опять развели флуда на вечную тему BOOST сигналы против QT =))))

А по мне так почти весь BOOST это ужасный синтаксический изврат демонстрирующий то что на С++ решая какие либо задачи приходиться чаще всего не думать над самой задачей а над тем как виртуозней применить костыль из метапрограммирования. При этом эти самые мета-костыли создаются таааким синтаксисом что ковырять его приходится огого чтобы въехать в суть дела.
И недайбог нету готового костыля, изобретение своего под свои нужды может занять приличное время. Так что это проблема языка - С++, а всякие костыли портят удобочитаемость и красоту синтаксиса.

Считаю систему сигнал слот из QT одной из самых идеологически правильных (хотя это тоже костыль), только в Qt я могу чувствовать что каждый класс может быть полностью независим от другого. Изменив или удалив код мне ненужно править другие, достаточно убрать связь.

А про связь с объектами в скриптах, про QML, и прочие вкусности где нужно связывать динамически я думаю говорить и не стоит =)
Можно хоть звязывать объекты находящиеся в разных процессах на разных машинах в сети.
Харош хвалить изврат и костыли одного метода перед костылями другого.

Это сообщение отредактировал(а) Kipter - 8.4.2010, 02:15