Интегратор Yet another catА на Qt проще программировать. Это тоже сторона эффективности. И она мультиплатформенная.

На НЕТе ещё проще программировать - и что ? :)

PS Кроссплатформенность нужна длеко не каждому ;)

На НЕТе? Не знаю. В смысле сомневаюсь. Мне кажется, что концепция слот-сигнал в Qt попроще для понимания, чем делегаты.

Не совсем точно выразился. И у делегатов, и у слотов с сигналами суть одна - как вызвать метод известной сигнатуры у объекта, класс которого при разработке вызывающей части кода неизвестен. А вот синтакс для Qt попроще ИМХО.
=====
Cat и его покойный друг Chicago

Интегратор alex_k
Yet another cat wrote:
> Не совсем точно выразился. И у делегатов, и у слотов с сигналами суть
> одна - как вызвать метод известной сигнатуры у объекта, класс которого
> при разработке вызывающей части кода неизвестен. А вот синтакс для Qt
> попроще ИМХО.
блин, сделали бы специальный тип в с++
указатель на метод класса.
чтобы он хранил не только указатель на метод но и указатель на класс.

то-то былоб здорово, то-то хорошо.
можно было бы вызывать по такому указателю класс, о котором совершенно
ничего не знаешь....
Posted via ActualForum NNTP Server 1.2

Функторы прекрасно решают эту проблему - инкапсулируешь указатель на класс в функторе и вперёт с песней. Через шаблоны всё великолепно рулится - не вижу никаких проблем.

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

Интегратор Yet another cat[quot Интегратор][quot alex_k]


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

Приведи пожалуйста реалистичный пример кода в котором по твоему мнению не разрулишь без самодостаточных указателей на методы класса.

Так кода или "не разрулишь"? ИМХО противоречие здесь. Если код есть, то все уже разрулено. А пример приводится легко. Это любое event-driven GUI API. Именно любое. Совершенно тривиальное действие. Пользователь кликнул мышкой по кнопке. Откуда разработчик кнопочки узнает, где и как разработчик приложения обработает нажатие? А откуда он узнает, какие данные надо передать вместе с сообщением о клике? Вот и начинается всякая фигня. Виртуальные методы? Не подходит, на каждый чих подкласс что ли делать? А если я хочу событие в родительской форме обработать? Карты событий как в MFC? Уже ближе. Жизнеспособное решение, но со своей ценой: статическая типизация теряется. Все, что ты хочешь из нестандартного вместе с кликом передать придется передавать как void* Все ошибки на твоей совести. Шаблоны? Тоже подходит, но та же проблема, что из картами событий. Попробуй что-нибудь нестандартное передать обработчику. Тут либо на каждую такую фигню шаблон писать (тебе не надоест ли?), либо, как это в libsig сделано, определить стандартные функторы, в которых все сопутствующее опять же как void* идет. Естественно, в последнем случае никакой статической типизации нет. То что в Qt представляется оптимальным решением. И слот и сигнал объявляются как методы класса, соответственно, большинство ошибок с типами ловятся компилятором. Ну ты можешь, конечно, приведением типов себе жизнь испортить, но это только твои проблемы. Выбор сигнатуры для слотов и сигналов - на твое усмотрение, соответственно, никаких проблем с динамической памятью для дополнительных параметров. Требование только одно: сигнатуры сигнала и подключаемого к нему слота должны совпадать. Если попытаешься подключить слот несовместимой сигнатуры, то получишь exception. Разумеется, это не статический контроль, но зато вполне единообразный, об этом механизме при разработке думать не придется.

ЗЫ. Прошу понять, я не пытаюсь сказать, что это единственный подход, но лично для меня, это самый удобный подход. Вам не нравится? Great, у нас демократия

Интегратор Yet another cat[quot Интегратор][quot Yet another cat][quot Интегратор][quot alex_k]

ЗЫ. Прошу понять, я не пытаюсь сказать, что это единственный подход, но лично для меня, это самый удобный подход. Вам не нравится? Great, у нас демократия

boost::signal :)

Не канает. Вот у меня диалоговое окно с полями ввода и кнопка на нем. Где мне логичне всего обработать ввод нажатие этой кнопки? Как правило, в методе подкласса соответствующему этому диалогу. хотя варианты возможны. И как мне вызвать этот метод? Лепить функтор, который знает о существовании моего класса окна и метода в нем? Это хорошо только для OK и Cancel. Там вообще можно сделать стандартный функтор, вызывающий виртуальный метод в базовом классе диалога, а в подклассах его перекрывать. Но ведь встречаются кнопки другого назначения, правильно? И на каждую по функтору, так что ли получается. А соединить напрямую сигнал кнопки и слот окна boost::signal уже не позволит. Вот и остается только захламлять проект сущностями, совершенно не нужными для понимания сути кода.

Обрати также также внимание, на предыдущий пост (через один). Ты можешь инстанциировать шаблон только статически, на стадии компиляции. Если твое приложение при модульной структуре получило ссылку на объект и ты знаешь, что класс объекта определяет слот с неким именем, которое также тебе передано. Классичесская ситуация Service Discovery. И что мне тут могут предложить шаблоны вообще и boost::signal в частности? А ничего. Хоть из штанов выпрыгни, а если указателя на метод нет и есть только имя, ты его не вызовешь. Можно, конечно, написать надстройку для организации позднего связывания. И получится у тебя как раз QObject из Qt.

Конечно не понимаешь. Породил две лишних с точки зрения проекта сущности - функтор и биндинг и рад по уши. Аналог на Qt выглядит лучше, работает не хуже.


ЗЫ. Специально для любителя мелких подковырок: delete для button я не забыл, он мне нафиг не нужен, диалог свои подчиненные виджеты сам прибьет, когда нужно.

Что касается вызовов по имени, то сразу видно, что ты скриптуемых приложений никогда не писал. Может, не нужно было, не вопрос. Просто Qt хорошо подходит не только для написания собственно скриптуемых приложений, но и является библиотекой, которую можно использовать в скриптовых языках. В отличие от той же WTL, которая не только библиотека для одной платформы, но и для одного языка программирования.

2 alex_k:

Это компилируется любым компилятором. Все лишние слова (например, slots) - макросы-пустышки. Они имеют значение только для moc (Meta-object compiler), который поставляется вместе с Qt. Все, что тебе нужно, так только пройтись moc'ом по хидерам и включить сгенерированные им файлы в проект. И то только, если являешься любителем make-файлов, для основных IDE поставляются плагины, делающие процесс прозрачным для тебя. В этом и суть, что само по себе ничего не бывает, но работая с Qt думать об этом не нужно.
=====
Cat и его покойный друг Chicago