В общем оппонент №1 - больше информации, все грабли заранее известны, полная обратная совместимость, стабильность, совместимость с Delphi, куча компонентов, бесплатность, возможно работать на уровне Win32 API.
№2 - кроссплатформенность, продуманная архитектура (VCL тож не на коленке писали), так-же радует поддержка свг и юникода. В остальном всё не так радужно, я сомневаюсь что там можно обрабатывать сообщения windows или получить хэндл окна, помимо этого для того чтобы программы выглядели одинаково на всех платформах, контролы рисуются программно, ну и конечно отладчик gdb не способный нормально работать (попробуйте поставить точку останова в конструкторе). 

Смешные какие-то аргументы против куте 


bool QCoreApplication::winEventFilter ( MSG * msg, long * result )   [virtual]


WId QWidget::winId () const


А в VCL аппаратно?  Или речь про QWindowsXPStyle и QWindowsVistaStyle? Юзающие Visual Styles и Aero.


О да, просто бесспорно   


В чём проблема?

Где? Какой? Ты о чём? 0_о



Не аргумент... Если они известны тебе - то это твой плюс... Если тебе не известны грабли Qt - то это твоя проблема... К оппоненту это никак не относится...


Гхм... А в Qt раз в неделю нужно рефакторить код, дабы совместимость поддерживать?  


Покажи мне нестабильный код на MinGW/Qt и я покажу тебе нестабильный код для билдера/VCL .


У Qt совместимость с туевой хучей языков.


Аналогичное можно сказать о Qt.


Аналогичное можно сказать о Qt.


Камушек в огород MinGW? Ты хочешь сказать что с MinGW нельзя работать на уровне W32API? 


Qt как раз таки славится нативной отрисовкой. Если ты явно не указываешь какой стиль использовать, то будет выбран стиль по умолчанию(т.е. нативный для данной платформы).


Мы этот вопрос уже вроде обсуждали . Всё с gdb хорошо(отдельное спасибо FF).


Ты не поверишь - пробовал и не раз .

Нуу, это ж разве война... Lazin, полней аргументировать надо, и многие детали реализаций знать... а то так не интересно  

Хотя какие там могут быть аргументы против Qt...  

Да это то изначально было понятно... Просто весело будет смотреть, как билдеристы будут потихонику о**евать от того как много кнопок они нажимают и как мало от этого получают .

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

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

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

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


Мне не нравится реализация поддержки локалей в Qt, т.е. класса QLocale & Co. Он выглядит слегка недоделаным, например я не нашел способа отформатировать вывод денег с денежной единицей, хотя отформатировать просто число можно. Это неудобно, приходится дополнительно использовать стандартные способы.

Это первое что прошло в голову, вспомню еще - напишу  

Попинаю VCL:
1. Есть ли там layout'ы?
2. А вы ими пользуетесь?
3. А почему ими не пользуется билдеровский дизайнер(сводя на нет преимущества лэйаутов, если они есть, конечно)?


nickless, да, поддержки currency к сожалению нет, хотя... Не такая уж это большая проблема .

Я же говорил, ерунда получится. Нужны люди, которые  делали приличные проекты и в том и в другом.
А так  кисло получается.

А Вы снизте уровень апломба и начните с недостатков  С++Builder и  предлагаемой им парадигмы визуального программирования, выполненной на основе принципов  PME ( properties, methods, events )  
Нижеследующие известные реально существующие недостатки можете сразу пропустить  
1. Наличие VCL-классов, поведенияе которых  в силу своего происходения  в отдельных случаях отличается от стандарта. Ради справедливости надо отметить, что эти отклонения  описаны в документации в соответствующем разделе хелпа.
2. Снижение попоулярности С++Builder вследствие идиотской политики топ-менеджеров фирмы Borland.
Можно также сразу пропустить  заблуждения о  вопиющей несовместимости С++Builder со стандартом.
Я правда с 2004 года на С++ Builder не пишу, но постаюсь ответить.

1. А нах они там, вообще ненавижу layoutы, они не интуитивны, в VCL для этого есть свойства Anchors и Align - это намного удобней чем гадать как твоя форма будет выглядеть в итоге.
2. Их нет в VCL, как ими пользоваться?


 буду рад если ктонибудь на этом форуме покажет как его нормально использовать.


Ну так если вы так напишите то кроссплатформенность коту под хвост.


Когда я начал изучать Qt, я обнаружил что примеры для Qt3 не работают с Qt4. 

Добавлено через 2 минуты и 9 секунд

Аты клавиатурой для написания программ совсем не пользуишся?   и результаты есть ?   

что конкретно показать?

а что, Builder позволяет кроссплатформенно обрабатывать сообщения Windows?   

имелась в виду, думаю, мышка

как использовать mingw + eclpse + gdb, чтобы это всё работало стабильно. К mingw претензий у меня нет, но вот gdb у меня работал нестабильно, версий 6.6 и более ранних.
Кстати ктонибудь сдесь кроме Vyacheslav использовал ВЦЛ в серьезном проекте? Это я о том что в принципе по организации, все эти библиотеки не сильно друг от друга отличаются. Если к примеру нужно что-нибудь рисовать на форме (виджете, окне) то последовательность действий везде одна и та-же:
VCL
ловим событие OnPaint, получаем Canvas компонента (формы), и рисуем..
Qt
ловим событие - аналог OnPaint? получаем QPainter рисуем...
wxWidgets
в обработчике OnPaint получаем wxDC...
вынь32 api
по событию WM_PAINT получаем HDC.........
единственное, что серьезно отличает Qt - это сигналы-слоты, в остальном тоже самое    

PME является основой и Qt в том числе...
Насчёт недостатков - что насчёт лэйаутов?


Pixel hunting по определению не может быть удобнее layout'ов. Пусть даже будут предоставлены костыли, дабы уменьшить количество почти ручных вычислений координат.
Попробуй динамически сконструировать очень сложную форму - поймёшь о чём я говорю.


Уважаемый, может быть мы обойдёмся без настолько смешных аргументов?


Знаешь сколько существовала Qt-3, пока не появилась Qt-4? За такой период любая система должна пересматриваться, рефайниться. Во-первых, есть целый ман по протированию qt3-qt4. Во-вторых - такова политика компании(улучшать дизайн, но оставлять лазейки для совместимости) и это, ИМХО, самая правильная политика.


http://forum.vingrad.ru/index.php?showtopi...t&p=1279508

Добавлено через 2 минуты и 42 секунды
Да уж... вынь32 api от Qt отличает только отсутствие сигнало-слотов... Тогда спорить, думаю, бессмысленно .

Ну вообще то я - лентяй. А лень как известно двигатель прогресса. Меня то и С++ в свое время привлек тем, что в нем можно лаконично писать код. С++Builder  продолжил эту славную традицию посредством визуального программированя. Умело пользуясь предоставленными компонентами можно создать относительно сложный  пользовательский интерфейс не написав ни строчки кода. С учетом того, что разработка интерфейса может в отдельных проекта занимать до 70% рабочего времени, С++Builder любезно берет этот тяжкий труд на себя, оставляя мне больше времени на бизнес логику.
Например программку, которая  обеспечивает манипулции со списками межуду двух листбоксов ( копирование или перемещение из одного в другой и обратно, удаление ) я могу создать вообще не   написав ни строчки кода ( вообще у меня мания на этот счет - писать как можно меньше)  Весь функционал будет создан только средствами дизайна.  При этом программа сможет перемещать, копировать выделенные данные из одного списка в другой или удалять их  по нажатию соответствующей кнопки, а также следить за состоянием этих кнопок и управлять их доступностью, исходя из конкретной ситуации. 
О layout'ах. Да есть такое упущения: разработчики не предусмотрели "стандартного" менеджера. Но кто мешает создать свой менеджер. Кстати , библиотеки с компонетами от сторонних разрабочиков очень часто предоставляют такие менеджеры для своих компонетов (DEV Express, например) 
Что касается форм, то я обычно выбирад другой путь. Разработка проекта начиналась обычно с создания своих компонентов и базовых форм со своими нужными мне проперятями и событиями,  шаблонов проектов модулей, которые интегрировались в IDE и использовались как стандарные формы. Например в одном из проектов , для создания нового плагина достаточно было открыть соответствующий шаблон проекта, заполнить в  соответствии с инструкцией  требуемые проперти, в заданном месте написать  реализацию функционала. Там же в IDE после тестирования и готовности модуля мог запустить его на инсталяцию ( пунктик был в меню): и соответствующий функционал, встроенный в IDE пересобирал заланный модуль, зачитывал номер версии и билда, регристрировал(обновлял) этот модуль и версию в БД и в нее же загружал исполняемый модуль. После этой процедуры обновленный модуль становился доступным пользователям. Программирование напоминало больше технологический процесс, нежели  творчество.
А как Вам например компонент-оболочка вокруг RASDial, написанный мною, который мог осуществлять дозвон и соединение прямо в дизайне или хотя бы те же стандпартные компоненты позволяющие подключаться к БД и выводить содержимое также в дизайне, еще до начала, собственно , самого программирования? 

Ну и пару слов о кроссплатформенности. С++Builder 6 предоставлял таку возможность. Наряду с узкозаточенной VCL,  в комплект входила и другая  визуальная библиотека CLX. Создав приложение на CLX, я мог перенести код на Linux и спомощью C++ Kylix 3 собрать его там.
Это достигалось тем, что CLX, которая  обеспечиавоа прицип RAD, являлась настройкой над ...  Qt  .
С одной стороны можносделать вывод, что без Qt никуда, а с другой - что возможности предоставляемые QT на уровень RAD не тянут и она по своей сути остается ресурсоориентированной библиотекой, так же как MFC, wxWIndows и пр.
Это был весьма многообещающий проект,  но к сожалению во-первых похоже не сошлись по цене с разработчиком, а во-вторых  для меня он потерял свою прелесть из-за идиотского подхода Borland : они вокруг QT соззали врапер из дельфийскизх CLX классов и эти классы предложили использовать в C++ Kylix/C++Builder. В результате на выходе получился бутерброд  C++(QT)->Delphi(CLX)->C++(приложения ). Соответсвенно получили итог: дельфийцам межплатформенность не нужна - у них уже есть воя ниша. Те, кто пишет на С++Builder - подход показался черезчур  экзотичным. CLX и Kylix канули в лету
 
  

 

Ну вообще в VCL используется тот-же принцип что и в winforms, у каждого компонента есть свойства Anchors и Allign, которые позволяют очень удобно группировать контролы на форме, и позволяет, в частности, избежать использования вложенных layout-ов.  Но если очень этого хочется, в BDS2006 добавили новые стандартные компоненты FlowPanel и GridPanel, делающие то-же что и Layout-ы.

Не знаю, есть ли аналог в Qt, но в VCL имеется оч. удобная весчь - TFrame, с помощью которой можно очень сложный динамический интерфейс сделать, частично, в дизайнере. Помимо этого можно как угодно переделать уже готовую форму, даже если ее написал не ты, и нет исходников. Можно, к примеру, добавить свои элементы управления на стандартный диалог выбора цвета, или удалить оттуда что-нибудь. Только жаль что для этого уже придется программировать   .

Я совсем не это имел ввиду, а то что удобный дизайн, это удел не только Qt.

на удивление конструктивненькая дискуссия...


чисто на интерес - а теперь на чём пишешь?