LINUX.ORG.RU

Ответ на: комментарий от anonymous

а на сайте кде новость что выходит новый смартфон самсунг с embedded qt на борту =)) и чего это они гтк бесплатную и суперскую такую взять не захотели ...

anonymous
()
Ответ на: комментарий от anonymous


>А я разве говорил, что C++ нельзя расширять? Расширяйте - библиотеками.
А вот всякие там "slots:" и "signals:" - это что за выкрутасы?

Это расширение языка на уровне мета-объектного компилятора.
Я не спец в языках программирования, но разработчики Qt утверждают, что за счет него С++ получает гибкость Objective C.
(то есть, они считают, что для разработки GUI Objective C подходит куда лучше, чем С++.)
Я не первый год использую Qt и "всякие там slots: и signals:" - хорошо зарекомендовавший себя механизм для связывания объектов.

ANDI ★★
()
Ответ на: комментарий от Skull

> Ошибаетесь, в таком случае приложения будут делаться быстро и
> качественно. Для примера - назовите подобный apps.kde.com
> репозиторий для приложений GTK+

Справедливости стоит отметить, что apps.kde.com, похоже, накрылся
медным тазом

anonymous
()
Ответ на: комментарий от ANDI

>С++ получает гибкость Objective C

Так зачем им (разработчикам QT, а равно и QT пользователям) C++? Если им кажется, что стандартный C++ ужасно неуклюж, то, может быть, не стоило его выбирать в качестве языка для своих проектов. Что касается хорошо зарекомендовавшего себя механизма, существует превеликое множество оных, и если каждый из них _встраивать_ в язык, последний перестанет быть понимаемым доселе его знатоками.

Это лишь мое мнение, и я отнюдь не являюсь "блюстителем чистоты", вполне могу простить что-то типа QObject::className(). Просто причина, по которой QT разработчики не стали использовать шаблоны меня, мягко говоря, удивляет: дескать еще не все компиляторы хорошо справляются с шаблонами и поэтому они изменили язык так, что без moc его не поймет вообще ни один компилятор!

anonymous
()
Ответ на: комментарий от anonymous

А вот и QT Assistant:

5. No limits
Because we had the moc for signals and slots, we could add other useful things to it that could not not be done with templates. Among these are scoped translations via a generated tr() function, and an advanced property system with introspection and extended runtime type information.

Видимо, ребята решительно настроены добить несчастный C++. :)

anonymous
()
Ответ на: комментарий от anonymous

А вот и QT Assistant:

5. No limits Because we had the moc for signals and slots, we could add other useful things to it that could not not be done with templates. Among these are scoped translations via a generated tr() function, and an advanced property system with introspection and extended runtime type information.

Видимо, ребята решительно настроены добить несчастный C++. :)

anonymous
()
Ответ на: комментарий от anonymous

Вот, решил зарегистрироваться. Тот анонимус, которому не особо по душе QT - это я. Просто как-то нехорошо получается: ANDI один, а anonymous - не поймешь, сколько их, споришь то ли с одним, то ли с несколькими.

kaa17
()
Ответ на: комментарий от anonymous

>Так зачем им (разработчикам QT, а равно и QT пользователям) C++? Если им кажется, что стандартный C++ ужасно неуклюж, то, может быть, не стоило его выбирать в качестве языка для своих проектов.

Я полагаю, из-за распространенности С++. Будь ObjectiveC более удачным (распространенным), все могло оказаться по другому.
Но это вопрос не ко мне уже.

>Что касается хорошо зарекомендовавшего себя механизма, существует превеликое множество оных, и если каждый из них _встраивать_ в язык, последний перестанет быть понимаемым доселе его знатоками.

Сигналы и слоты - это действительно простой механизм, поэтому говорить, что он может оказаться непонимаемым для знатоков C++...
Конечно, ход со стороны Trolltech был рискованный - расширять язык. Но он полностью себя оправдал (я так считаю).

>Это лишь мое мнение, и я отнюдь не являюсь "блюстителем чистоты", вполне могу простить что-то типа QObject::className(). Просто причина, по которой QT разработчики не стали использовать шаблоны меня, мягко говоря, удивляет: дескать еще не все компиляторы хорошо справляются с шаблонами и поэтому они изменили язык так, что без moc его не поймет вообще ни один компилятор!

Это не единственная причина, по которой стал использоваться moc. И еще спорный вопрос - что лучше: шаблоны или moc. Представляете, сколько было бы сгенерировано кода при использовании шаблонов внутри Qt? А KDE?

ANDI ★★
()
Ответ на: комментарий от anonymous

>Видимо, ребята решительно настроены добить несчастный C++. :)

Да, обратного пути уже нет) Столько софта уже написано...

Представьте, что вы хотите добавить какую-то новую возможность в язык.
При этом на создание своего у вас нет ресурсов (а ведь надо еще компиляторы и под разные платформы).
Что делать? Самое простое решение - сделать препроцессор, который будет генерировать стандартный С++.
Да, код Qt-программы не является чистым С++, таковым его делает moc, но здесь уже начинается религиозный вопрос о языках программирования. Меня синтаксис Qt вполне устраивает, и я не являюсь апологетом С++.

ANDI ★★
()
Ответ на: комментарий от anonymous

Re:

На самом деле, добивают "несчастный C++" все, кому не лень. Темплейты - это самое безобидно, чем можно не пользоваться при программировании на C++ :-))

У меня дружок (заядлый C++'ник, хорошо знакомый со всеми этими новыми плюсовыми приемами и методами) начинал писать GUI на wxWindows (еще для винды), все неплохо, в общем, ему нравилось.

Но когда он попытался пропихнуть какую-то разработанную им фишку обратно в wx, ему сказали: "спасибо, дорогой, клевый патч, но тут вот ты эксепшны используешь, а у нас-де в таджет-платформах есть компиляторы, которые с эксепшнами не дружат. А не мог бы ты этот патчик переписать так, чтобы не было эксепшнов?" Ну, переписал он, сильно искорявив код, патчик вставили (дополнительно изуродовав, как ему кажется). Только после этой истории его энтузиазм в отношении wx сильно угас. А когда он обнаружил (уже на Linux/wxGTK), что у wx есть и визуальные глюки, и (разумно) править код не представляется возможным, он просто забил на него, благо, в тот момент еще можно было сменить GUI.

И, от себя добавлю: если кому-то хочется посмотреть на УЖАС при программировании на C++ - взгляните на ACE/TAO. Тамошняя система макросов "совместимости" вызывает не то, что оторопь, а самый настоящий ступор.

AlexM ★★★★★
()
Ответ на: комментарий от ANDI

2ANDI:

Все, я иссяк ;). Да и положение наше с Вами разное: Вы защищаете то, чем не один год пользуетесь (дело правое!), в то время как я ругаю то, с чем сталкивался раз или два (возмутительно!). И время поджимает: за памперсами надо бежать! Приятно было общаться.

kaa17
()
Ответ на: комментарий от anonymous

>Просто причина, по которой QT разработчики не стали использовать шаблоны меня, мягко говоря, удивляет: дескать еще не все компиляторы хорошо справляются с шаблонами и поэтому они изменили язык так, что без moc его не поймет вообще ни один компилятор!

Ну почему доку до конца не прочитать? Лень? Шаблоны не используют не только потому, что не все компиляторы "ОДИНАКОВО" их понимают (покажите мне другую библиотеку, которая собиралась бы на таком количестве платформ и любым компилятором), но moc гораздо гибче и добавляет функциональность, которую шаблоны обеспечить ну никак не могут, как то, например, обращение к объекту или методу (slot/signal) по его символьному имени const char* (gtk так умеет?), программа получает сумасшедшую гибкость: можно переназначать связи сигнал<=>обработчик налету (runtime or disign time) по ходу исполнения, можно также производить любые вообразимые типы связывания один к одному или многие ко многим; эти технологии позволяют также загружать формы (ui файлы в формате XML) на лету во время исполнения программы, автоматически создавать файлы перевода для многоязыковых приложений (просто сообщения в программе пишешь, на на том языке на котором нравится, а linguist автоматом создает файлы соответствий сообщений на разных языках и их нужно просто заполнить), и потом moc вызывается автоматом при сборке и тебе не нужно что-либо по этому поводу делать.

А если с библиотекой не слишком хорошо знаком, то зайди на их сайт и прочитай статейку Qt vs. gtk (на kde.ru есть на русском), отзывы, примеры успешных приложений и т.д. и т.п.

GladAlex.

P.S. И не надо лохматить бабушку. ;-)

anonymous
()
Ответ на: комментарий от anonymous

>Ну почему доку до конца не прочитать? Лень?

К сожалению, я не могу себе позволить читать _все_ доки до конца. Если упустил что-то - виноват. Да и что-то вчера я был излишне эмоционален, мог, не подумав, ляпнуть ляпу :). Приношу извинения.

>(gtk так умеет?)

Я ни разу не упоминал про GTK+ (да и не мог: скорее, сравнивать надо было бы с gtkmm, а еще точнее - с libSigC++).

>А если с библиотекой не слишком хорошо знаком, то зайди на их сайт и прочитай статейку Qt vs. gtk (на kde.ru есть на русском), отзывы, примеры успешных приложений и т.д. и т.п.

Ну прям поперек горла у Вас застрял этот GTK+ - так Вы его и норовите vs. QT поставить :). И, потом, (по-моему, конечно) плюсы и минусы программного продукта по-настоящему проявляются в процессе его эксплуатации, а не после прочтения разного рода статеек, отзывов, примеров успешных приложений и т.д. и т.п. Именно по этой причине я прекратил (Вы не заметили?) этот спор (который вовсе не заключался в сравнении QT с чем-либо, мне просто не нравится появление новых "ключевых" слов, о которых никто, кроме QT, не знает).

Кстати, на KDE.ru среди тем этих самых статеек встречаются довольно интересные: например "Сравнение QT и Java". Не удивлюсь, если увижу где-нибудь результаты состязаний QT и холодильников (не принимайте всерьез: пытаюсь пошутить).

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

kaa17
()
Ответ на: Re: от AlexM

> И, от себя добавлю: если кому-то хочется посмотреть на УЖАС при
> программировании на C++ - взгляните на ACE/TAO. Тамошняя система
> макросов "совместимости" вызывает не то, что оторопь, а самый
> настоящий ступор.

Но надо признать, что ACE замечательная вещь.
Где-то два года назад меня на работе перевели
в группу разработки и поддержки софтины, которая
работает на Win32, Solaris и AIX (серверная софтина,
middleware, практически без GUI, на C++).
Вначале я решил, что это жопа - для Win32 я никогда
за более, чем 15 лет своей работы не программировал.
Однако как оказалось, вся софтина написана именно
с использованием ACE. Так вот мне и не пришлось
этому ничему Win32-specific учиться. Все, что я
пишу с использованием ACE-классов на Solaris/AIX
работает в Win32 автоматически... даже у себя на
desktop не пришлось ее ставить.
Конечно надо держать себя в руках и не использовать
явно Unix-specific вещи, некоторые различия также
имеются - но они сравнимы с различиями между
разными Unix-системами.
Да, и никто же не заставляет использовать high-level
ACE абстракции - если хочешь, можно обойтись просто
ACE_OS::* и ACE::* обертками.



anonymous
()
Ответ на: комментарий от kaa17

>Ну прям поперек горла у Вас застрял этот GTK+ - так Вы его и норовите vs. QT поставить :)

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

GladAlex.

P.S. Я только наполовину анонимус ;-)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.