Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > С/С++: Кроссплатформенное программирование, Qt/Gtk+/wxWidgets > Помогите составить письмо на english в nokia


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

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

Автор: boostcoder 5.4.2010, 07:09
Цитата(borisbn @  5.4.2010,  06:59 Найти цитируемый пост)
причина - почти всегда одна и та же: не убрали (при копировании) формальный параметр в макросе SIGNAL или SLOT. 

поясните...

Автор: borisbn 5.4.2010, 09:13
Цитата(boostcoder @  5.4.2010,  07:09 Найти цитируемый пост)
Цитата(borisbn @  5.4.2010,  06:59 )причина - почти всегда одна и та же: не убрали (при копировании) формальный параметр в макросе SIGNAL или SLOT. поясните...


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

connect( &obj
            , SIGNAL( somethingChanged( SomeThing & formal_parameter_name )
            , SLOT( onSomethingChanged( SomeThing & formal_parameter_name )
            );

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

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

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

Цитата

This example ensures that the label always displays the current scroll bar value. Note that the signal and slots parameters must not contain any variable names, only the type. E.g. the following would not work and return false:

 // WRONG
 QObject::connect(scrollBar, SIGNAL(valueChanged(int value)),
                  label, SLOT(setNum(int value)));


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

Автор: borisbn 5.4.2010, 09:42
boostcoder, 
Цитата(boostcoder @  5.4.2010,  09:29 Найти цитируемый пост)
я все же склонен полагать, что это целиком обязанность программиста.

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


SABROG, 
Цитата(SABROG @  5.4.2010,  09:33 Найти цитируемый пост)
То есть если имя аргумента не совпадает с именем объявленным в определении функции, то соединение не работает?

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

bool QObject::connect( QObject * senderObj, const char * signalSignature, const char * slotSignature )
{
    std::string signalSignature_p = remove_formal_parameters( signalSignature );
    std::string slotSignature_p = remove_formal_parameters( slotSignature );
    connect_internal( senderObj, signalSignature_p.c_str(), slotSignature_p.c_str() );
}

Автор: azesmcar 5.4.2010, 09:47
Пожалуйста
Цитата

Dear Qt Team (или как вас там по имени и отчеству),

I am using QT for a while now and I noticed that a very frequent problem for novices is SLOT-SOCKET connection. The cause is always the same - forgot to remove formal parameter name when calling SIGNAL/SLOT macros. I want to suggest to make the connect/disconnect function a bit smarter and remove formal parameter name if it is necessary.

Regards,
Me


хотя и полностью согласен с
Цитата(boostcoder @  5.4.2010,  09:29 Найти цитируемый пост)
это целиком обязанность программиста


Автор: borisbn 5.4.2010, 10:03
azesmcar, спасибо.

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

Автор: azesmcar 5.4.2010, 10:07
borisbn

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

Автор: SABROG 5.4.2010, 10:49
Цитата(azesmcar @  5.4.2010,  10:07 Найти цитируемый пост)
Я вообще считаю что эти сигнал/слоты надо выкинуть из Qt и сделать по человечески, как в boost.

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

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

Автор: boostcoder 5.4.2010, 10:51
Цитата(borisbn @  5.4.2010,  10:03 Найти цитируемый пост)
чем каждый раз вручную удалять имена формальных параметров после копирования сигнатуры слота из h-ника ?

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

Цитата(azesmcar @  5.4.2010,  10:07 Найти цитируемый пост)
Я вообще считаю что эти сигнал/слоты надо выкинуть из Qt и сделать по человечески, как в boost.

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

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

Автор: azesmcar 5.4.2010, 10:52
Цитата(SABROG @  5.4.2010,  10:49 Найти цитируемый пост)
Сделайте, git репозиторий открыт для всех

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

Цитата(SABROG @  5.4.2010,  10:49 Найти цитируемый пост)
Сигналы boost не идеальны

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

Автор: boostcoder 5.4.2010, 10:55
Цитата(SABROG @  5.4.2010,  10:49 Найти цитируемый пост)
Сигналы boost не идеальны

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

Цитата(SABROG @  5.4.2010,  10:49 Найти цитируемый пост)
как минимум они не поддерживают асинхронности

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

Цитата(SABROG @  5.4.2010,  10:49 Найти цитируемый пост)
и динамического подключения в runtime.

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

Автор: SABROG 5.4.2010, 11:06
Цитата(azesmcar @  5.4.2010,  10:52 Найти цитируемый пост)
Никаких ошибок

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

Цитата(boostcoder @  5.4.2010,  10:55 Найти цитируемый пост)
приведите пример когда это необходимо? или когда это единственный способ решить задачу? 

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

Цитата(boostcoder @  5.4.2010,  10:55 Найти цитируемый пост)
или как это в Qt зовется?

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

Цитата(boostcoder @  5.4.2010,  10:55 Найти цитируемый пост)
очередь обрабатывает boost::asio::io_service

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

Автор: azesmcar 5.4.2010, 11:12
Цитата(SABROG @  5.4.2010,  11:06 Найти цитируемый пост)
Все ошибки сыпятся в консоль во время выполнения.

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

Автор: boostcoder 5.4.2010, 11:20
Цитата(SABROG @  5.4.2010,  11:06 Найти цитируемый пост)
Покажите мне пример, где 2 объекта находящихся в разных потоках общаются между собой посредством boost::signals2 и boost::asio::io_service. Один объект посылает сигнал другому, не дожидаясь выполнения завершает свою работу, второй объект продолжает выполнять долгую задачу, например на секунд 10. Тогда я отстану. 

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

Автор: SABROG 5.4.2010, 11:28
Цитата(boostcoder @  5.4.2010,  11:20 Найти цитируемый пост)
легко.
это реализовано в проекте. сейчас состряпаю независимый код. по идее, класс-предок.
отпишусь в эту тему.

Ок.

Цитата(azesmcar @  5.4.2010,  11:12 Найти цитируемый пост)
Но если это спор - то бессмысленный, я нв думаю что вы не считаете сигналы Qt идеальными.

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

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

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

http://qt.nokia.com/doc/4.6/templates.html

Автор: W4FhLF 5.4.2010, 13:09
Мне кажется это проблема новичков в Qt. Я давно уже за собой таких ошибок не наблюдаю. smile

Автор: azesmcar 5.4.2010, 13:34
Цитата(SABROG @  5.4.2010,  11:28 Найти цитируемый пост)
Плюс вы забываете почему Qt не может использовать boost'овское подобие сигналов и слотов на основе шаблонов:

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

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

Even today, many widely used C++ compilers have problems with advanced templates. For example, you cannot safely rely on partial template specialisation

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

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

Автор: borisbn 5.4.2010, 14:23
Цитата(W4FhLF @  5.4.2010,  13:09 Найти цитируемый пост)
Мне кажется это проблема новичков в Qt. Я давно уже за собой таких ошибок не наблюдаю.

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

Цитата(boostcoder @  5.4.2010,  13:42 Найти цитируемый пост)
ощущение такое, что Qt-программисты, вообще не используют шаблоны.

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

Цитата(boostcoder @  5.4.2010,  13:42 Найти цитируемый пост)
в итоге, во имя своей сигнал/слотовой модели, они отрубили большую часть С++

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

Автор: boostcoder 5.4.2010, 14:34
Цитата(borisbn @  5.4.2010,  14:23 Найти цитируемый пост)
никто ничего не отрубал. я использовал boost в приложениях на Qt.

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

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

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

Автор: W4FhLF 5.4.2010, 15:22
Цитата(boostcoder @  5.4.2010,  13:42 Найти цитируемый пост)
вот вы попробуйте в качестве слота, указать функциональный объект созданный при помощи std::bind(), или лямбда выражение?!  а как без этого писать?! как же метапрограммирование, boost.mpl?!


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

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

Автор: SABROG 5.4.2010, 15:23
http://www.crossplatform.ru/node/50

Цитата

Наше решение предоставляет гораздо больше возможностей, чем шаблоны. Например, мы можем наделить объекты свойствами и перегрузить сигналы и слоты, что есть естественно для языка программирования, в котором перегрузка является ключевой особенностью. Наши сигналы не добавляют ни одного байта к размеру экземпляра класса, поэтому мы можем добавлять новые сигналы без потери бинарной совместимости. Механизм сигналов и слотов, в отличие от шаблонов, не приводит к чрезмерной генерации кода, благодаря чему его размер остается меньшим. Добавление новой связи приводит лишь к вызову простейшей функции, а не к генерации сложной шаблонной функции. Другим преимуществом является возможность манипулирования сигналами и слотами объекта во время выполнения. Используя вызов по имени, мы можем безопасно создавать связи без необходимости точного знания типов связываемых объектов, чего нельзя достичь с помощью шаблонов. Такой вид доступа к объектам во время выполнения открывает новые возможности, например, создание GUI-интерфейса и необходимых связей из XML UI-файлов. 



Автор: boostcoder 5.4.2010, 15:52
Цитата(djamshud @  5.4.2010,  15:18 Найти цитируемый пост)
boostcoder, а вы шутник. Функциональщина - да, это "настоящий с++". Очень смешно, спасибо.

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

Цитата(W4FhLF @  5.4.2010,  15:22 Найти цитируемый пост)
Но, естественно, не в качестве слотов.

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

Цитата(W4FhLF @  5.4.2010,  15:22 Найти цитируемый пост)
Потому что мешать boost::bind и qt::connect это просто неверно с т.з. архитектуры.

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

Цитата(djamshud @  5.4.2010,  15:23 Найти цитируемый пост)
В бусте же они статически прибиты гво^Wшаблонами. 

?

Автор: azesmcar 5.4.2010, 15:54
пора переносить в религиозные войны.

Автор: boostcoder 5.4.2010, 15:55
Цитата(SABROG @ 5.4.2010,  15:23)
http://www.crossplatform.ru/node/50

Цитата

Наше решение предоставляет гораздо больше возможностей, чем шаблоны. Например, мы можем наделить объекты свойствами и перегрузить сигналы и слоты, что есть естественно для языка программирования, в котором перегрузка является ключевой особенностью. Наши сигналы не добавляют ни одного байта к размеру экземпляра класса, поэтому мы можем добавлять новые сигналы без потери бинарной совместимости. Механизм сигналов и слотов, в отличие от шаблонов, не приводит к чрезмерной генерации кода, благодаря чему его размер остается меньшим. Добавление новой связи приводит лишь к вызову простейшей функции, а не к генерации сложной шаблонной функции. Другим преимуществом является возможность манипулирования сигналами и слотами объекта во время выполнения. Используя вызов по имени, мы можем безопасно создавать связи без необходимости точного знания типов связываемых объектов, чего нельзя достичь с помощью шаблонов. Такой вид доступа к объектам во время выполнения открывает новые возможности, например, создание GUI-интерфейса и необходимых связей из XML UI-файлов. 

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

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

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

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

Your suggestion makes sense, however this would degrade Qt performance and there already is a warning printed for wrong usage of the connect() function.

Автор: azesmcar 6.4.2010, 13:05
Цитата(borisbn @  6.4.2010,  12:54 Найти цитируемый пост)
there already is a warning printed for wrong usage of the connect() function.

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

Автор: Kipter 8.4.2010, 01:58
Омг опять развели флуда на вечную тему BOOST сигналы против QT =))))

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

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

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)