Ultimate++ 0.98.7

> Исходный код приложений, базирующихся на Ultimate++, часто значительно короче (часто больше 50%), в сравнении с такими же приложениями на других платформах.

Речь идет конечно о GUI-приложениях. Ultimate++ содержит в себе кроссплатформенную графическую библиотеку и Layout designer.

У меня вопрос к тем кто пишет на QT. На сайте Ultimate даны примеры программ на U++ и QT. Действительно, код U++ выглядит гораздо компактнее. Посему вопрос: возможно ли то же самое написать на QT компактно?

Можно. Нарисовать на Qt Designer.

PS. Какие-то нечистоплотные способы сравнения... В одном случае включается .lay, а в другом - всё это пишется в исходнике.

>Речь идет конечно о GUI-приложениях.

не только. это же кроссплатформенный _фреймворк_. на qt, кста, тоже можно консольные проги делать. другой вопрос - зачем.

а про сокращение кода... ну не знаю... ИМХО, это облегчит жизнь тем кто знает, что делает, но вконец испортит тех кто этого еще не осознал. сорри за оффтоп, но мну при фразе "Ultimate++ достигает значительного сокращения сложности кода" сразу вспомнилась борландовская вцл со всеми ее костылями и "мегакрутыми кулхацкирами, лабающими на делфе".

> но мну при фразе "Ultimate++ достигает значительного сокращения сложности кода" сразу вспомнилась борландовская вцл со всеми ее костылями и "мегакрутыми кулхацкирами, лабающими на делфе".

Хмм. Ну нельзя же всех под одну гребёнку. Например, я сейчас работаю на человека, который сколотил себе состояние на Delphi. Мало того что сколотил, так он ещё и целую команду разработчиков кормит.

Кстати, тут подумалось. Если нашлись умельцы, которые на QT написали Desktop Environment (KDE), то, теоретически, ничего не мешает появиться и умельцам которые напишут Desktop Environment на Ultimate++.

>Хмм. Ну нельзя же всех под одну гребёнку

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

>теоретически, ничего не мешает появиться и умельцам которые напишут Desktop Environment на Ultimate++.

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

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

Можно. Только я qt использую из-за его большого кол-ва отлаженных классов на все случаи жизни. Вот если бы они сравнили код реального приложения с поддержкой сетевых протоколов и xml ...

P.s. Вон на Дельфи писать тоже проще небольшие приложения, но при этом для серьезных проектов используют vc

Ждем когда эта ИДЕ для Linux и Windows будет предоставлять единый интерфейс, поддерживающий qt. Я имею в виду (различные компиляторы, отладчики, и.т.д.) А так пока мне приходится использовать MiniGW и KDevelop, что не очень удобно

И вроде бы все неплохо, но...

FileIn in(filename);
if(!in) {
Exclamation("Unable to open " + filename);
return;
}

Авторы библиотеки не подозревают о существовании try/catch?

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

Ну и разумеется стандартное изобретательство велосипеда - характерные имена классов String, Stream etc... про STL авторы видимо также не в курсе.

> Посему вопрос: возможно ли то же самое написать на QT компактно?

Можно! Запускаешь QT designer, создаёшь форму и используешь её в программе. Намного меньше кода! В примерах при сравнении виджеты создаются вручную, что уже никто не использует... :)

2 int19h: мда с try/catch они както не прально поступили... собсно как и в qt

такая перегрузка _удобна_ для некоторых целей... например сериализация (чуваки похоже подсмотрели в boost'e ;)

строки реально раздражают... ;( как и в qt (там еще и контейнеры свои... ;() -- пора бы уже библомэйкерам понять что существует STL и это стандарт...

По первым ощущениям - хуже Qt, но лучше wxWidgets

>строки реально раздражают... ;( как и в qt (там еще и контейнеры свои... ;() -- пора бы уже библомэйкерам понять что существует STL и это стандарт...

Когда STL'щики осознают, что есть Unicode, когда библомэйкеры перестанут плодить свои классы.

Про контейнеры в Qt уже кучу раз разжевали. Когда STL контейнеры шариться начнут - будет использоваться STL. У троллей всё это в ЧАВО есть

А можешь объяснить, что значит "когда STL контейнеры шариться начнут"? Или где об этом почитать можно?

adarovsky, чем Вам не понравились wxWidgets? Можно поподробнее, если есть возможность?

>А можешь объяснить, что значит "когда STL контейнеры шариться начнут"? Или где об этом почитать можно?

Шариться - это implicit sharing. То есть, оператор = получается легковесный, а копирование происходит только при изменении, и может быть, не полностью. У троллей в Qt доке. Explicit vs Implicit Sharing, дай бог памяти, называется...

>adarovsky, чем Вам не понравились wxWidgets? Можно поподробнее, если есть возможность?

1. Уродской (IMHO, ессно) системой евентов. Развращённому сигнал/слотами сложно перестраиваться. В последних версиях signal/slot вроде появились, но ими не рекомендовали пользоваться.

2. Дебильными падениями на GTK2 фронтенде. В век понтов и юникода иметь приложения в виде GTK+ 1 как-то некошерно :)

3. Саморисованными контролами. Tree Widget и в Qt, и в GTK+ (обеих) выглядит намного привлекательнее чем ужас wx.

4. В стабильном релизе (каюсь, год назад было) падали примеры. Единственный на моём опыте такой тулкит...

> 1. Уродской (IMHO, ессно) системой евентов. Развращённому > сигнал/слотами сложно перестраиваться. В последних версиях signal/slot > вроде появились, но ими не рекомендовали пользоваться.

IMHO, оно и есть IMHO, но довольно обоснованное. Т.е. дело именно в Вас, что не можете перестроится.

> 2. Дебильными падениями на GTK2 фронтенде. В век понтов и юникода иметь приложения в виде GTK+ 1 как-то некошерно :)

Возможно и некошерно (особенно, если руки перед ЭТИМ не мыть :-) ), зато кроссплатформенно :-) и бесплатно.

3. Саморисованными контролами. Tree Widget и в Qt, и в GTK+ (обеих) выглядит намного привлекательнее чем ужас wx.

Да ... а не пробовали создавать контролы свои под wx? Или это тяжело?

> 4. В стабильном релизе (каюсь, год назад было) падали примеры. Единственный на моём опыте такой тулкит...

Падали ... и не только год назад.

Ну а реально, без особых измнений, проект под QT под Linux и под Window сделать, чтобы одинаково было, возможно? Под wx - точно можно :-)

adarovsky ** (*) (08.08.2005 12:36:05)

> такая перегрузка _удобна_ для некоторых целей... например сериализация

Да, но какой умник догадался перегрузить <<= под биндинг обработчиков?? Или ~ для вытаскивания данных из виджета?

> Когда STL'щики осознают, что есть Unicode

Вообще STL перпендикулярна всяким там кодировкам (а с ее точки зрения, уникод - это та же кодировка). Для хранения строк имеется std::wstring. Обработка конкретно уникода - на откуп локали.

> Когда STL контейнеры шариться начнут - будет использоваться STL.

Зачем мне расшаренные контейнеры? Точнее так: зачем мне _неявно_ расшаренные контейнеры? Есть указатели (в т.ч. и smart), есть ссылки - что, мало?

>IMHO, оно и есть IMHO, но довольно обоснованное. Т.е. дело именно в Вас, что не можете перестроится

Говорю же, к хорошему быстро привыкаешь. У тут глянул, вспомнил MFC, прошибло холодным потом :)

>Возможно и некошерно (особенно, если руки перед ЭТИМ не мыть :-) ), зато кроссплатформенно :-) и бесплатно

Qt4 то жу самое :) А уж GTK2 давно было :)

>Да ... а не пробовали создавать контролы свои под wx? Или это тяжело?

Не пробовал. А зачем, оно же уже есть, только реализовано ужасно. В Qt и GTK - хорошо реализовано

>Ну а реально, без особых измнений, проект под QT под Linux и под Window сделать, чтобы одинаково было, возможно? Под wx - точно можно :-)

http://fsme.sf.net - собирался под Windows м помощью Visual Studio .NET, дай Бог памяти. Причём одной только версии. В остальных на вполне приличном месте орал дурную ошибку. То ли ключи сборки подбирать надо, то ли ещё что... Borland C++ Builder 6, кстати, жрал нормально этот код. Но дело было не в Qt, а в моём коде.

Сборка под Windows - вообще весёлое дело :)

> Саморисованными контролами. Tree Widget и в Qt, и в GTK+ (обеих) выглядит намного привлекательнее чем ужас wx.

В Qt вообще-то все виджеты саморисованные, как раз-таки в отличие от большей части wx. Проблема не в саморисовании, а в кривизне рук рисующих. Тот же Qt отрисовывает все виджеты так, что под вынью, например, их от нативных не отличишь - можно буквально попиксельно сравнивать.

>Вообще STL перпендикулярна всяким там кодировкам (а с ее точки зрения, уникод - это та же кодировка). Для хранения строк имеется std::wstring. Обработка конкретно уникода - на откуп локали.

Когда дело доходит до передачи по сети, и т.п. - начинаются грабли. wstring хранит текст в wchar_t, который никак не стандартизован :(

Я видел его реализации в виде unsigned short (понятно, где :) и unsigned int LE и BE вида.

Это есть очень плохо. Часто делают даже так: берут std::string, рождаются от неё, и говорят, что эта String : public std::string хранит строчки в UTF-8. (так сделано в Crazy Eddie's GUI)

>Зачем мне расшаренные контейнеры? Точнее так: зачем мне _неявно_ расшаренные контейнеры? Есть указатели (в т.ч. и smart), есть ссылки - что, мало?

Допустим, я храню эти контейнеры в каком-нибудь другом контейнере. Городить для этого всякие shared_ptr или копировать все элементы при перетасовке как-то не очень улыбается...

>В Qt вообще-то все виджеты саморисованные, как раз-таки в отличие от большей части wx. Проблема не в саморисовании, а в кривизне рук рисующих. Тот же Qt отрисовывает все виджеты так, что под вынью, например, их от нативных не отличишь - можно буквально попиксельно сравнивать

Об том и разговор - все, что в wx нативно рисуются - красивые. Те, что делаются своими руками - страшны, как смертный грех... Поэтому мне Qt больше нравится.

> Когда дело доходит до передачи по сети, и т.п. - начинаются грабли. wstring хранит текст в wchar_t, который никак не стандартизован

Это есть, и это правильно - строки должны работать шустро, а порядок байтов на разных платформах разный. Как уже сказано, оно отдается на откуп локали. В принципе, если в системе есть UTF-8 локаль, то можно перегнать из wstring в string, и это уже слать. Но стандарт не гарантирует присутствия UTF-8. Имхо, вместо того, чтоб городить огород с кучей строковых классов, лучше бы озаботились как раз прикручиванием UTF.

> Допустим, я храню эти контейнеры в каком-нибудь другом контейнере. Городить для этого всякие shared_ptr ... как-то не очень улыбается

А почему? shared_ptr сделан как раз для таких вот случаев.

>Это есть, и это правильно - строки должны работать шустро, а порядок байтов на разных платформах разный. Как уже сказано, оно отдается на откуп локали. В принципе, если в системе есть UTF-8 локаль, то можно перегнать из wstring в string, и это уже слать. Но стандарт не гарантирует присутствия UTF-8. Имхо, вместо того, чтоб городить огород с кучей строковых классов, лучше бы озаботились как раз прикручиванием UTF

QString::toUtf8 :)

>А почему? shared_ptr сделан как раз для таких вот случаев.

shared_ptr - аналог explicit sharing. Например, я положил несколько shared_ptr<std::set>' ов в std::list. А кто-то взял и вставил элемент в один из этих set'ов. В итоге я получу изменённые данные :( В случае implicit sharing, при вставке элемента я получу те же данные, что и сохранил. Плюс copy( list.begin(), ... ) выполнится быстро, поскольку копирования не будет, благодаря тому же implicit sharing...

>По первым ощущениям - хуже Qt, но лучше wxWidgets

сырая вешчь. еле до демок докопался а с ОпенЖЛ демкой- крантец.

..

#include <gl\gl.h>

..

#include <gl\glaux.h>

..

кросплатформенность? хм.... уж лучше fltk... здря время токмо убил на сборку ковыряние....

Интересно, почему нет сравнения с gtkmm?

> QString::toUtf8 :)

Прикрутить к локали, а не писать свой класс

> shared_ptr - аналог explicit sharing. Например, я положил несколько shared_ptr<std::set>' ов в std::list. А кто-то взял и вставил элемент в один из этих set'ов. В итоге я получу изменённые данные :( В случае implicit sharing, при вставке элемента я получу те же данные, что и сохранил.

А что, проблема написать generic класс-обертку, обеспечивающий семантику copy on write? Кстати, почти наверняка что-то такое в boost уже есть.

А всё равно на Tcl/Tk в разы короче.

Некрасиво. Что пришло в голову - это хранение shared_ptr'а на этот объект, и функции get() const и get() (или что-то в этом духе)...

>Прикрутить к локали, а не писать свой класс

А потом пробить в комитете стандартизации :) Какие-то строковые утилиты в boost, кстати, появились - может светлое будущее когда-нибудь и наступит...

кривоват он пока что ;)

>Шариться - это implicit sharing. То есть, оператор = получается легковесный, а копирование происходит только при изменении, и может быть, не полностью. У троллей в Qt доке. Explicit vs Implicit Sharing, дай бог памяти, называется...

Плохо это. Все implicit вообще плохо, и тут, эти контэйнеры не потокобезопасны, а зделать их потокобезопасными извне - непредставляется возможным - легче свой COV реализовать. Да ведь и у них, только вполне опрежеленные классы реализуют COV. В стл например отказались от COV - строк ... Именно поэтому стльные контейнеры никогда "шарится не начнут" и это есть гуд.

>вторы библиотеки не подозревают о существовании try/catch?

А зачем это в данном случае?

>про STL авторы видимо также не в курсе

An important feature of NTL are requirements for stored elements. Unlike STL, which has single copy-constructible and assignable requirement for whole library, NTL makes requirements on per container and even per method basis. This way NTL allows direct storing of any type of elements. NTL provides two or even three flavors for each basic ADT kind of container relative to requirements for elements.

А вот и важное преимущество перед стл. Попробуйте в стл

vector<ofstream> out_files(vector_size);

А в нтл так можно...

> А зачем это в данном случае?

Т.е. - зачем? Затем же, зачем вообще в плюсах исключения...

>Плохо это. Все implicit вообще плохо, и тут, эти контэйнеры не потокобезопасны, а зделать их потокобезопасными извне - непредставляется возможным - легче свой COV реализовать. Да ведь и у них, только вполне опрежеленные классы реализуют COV. В стл например отказались от COV - строк ... Именно поэтому стльные контейнеры никогда "шарится не начнут" и это есть гуд

А в Qt4 подружили implicit sharing и нитки :)

Очередное доказательства тому очевидному факту, что на C++ писать GUI нельзя. Многословная параша получается. Абсолютно нечитабельно.

Правильно! GUI надо рисовать :) Например, в Qt Designer :)

> Когда дело доходит до передачи по сети, и т.п. - начинаются грабли. wstring хранит текст в wchar_t, который никак не стандартизован :(

как это - wchar_t никак не стандартизован? в стандарте на C++ светится тут и там.

// wbr

>как это - wchar_t никак не стандартизован? в стандарте на C++ светится тут и там

а дальше пост не судьба прочитать?

Не надо GUI рисовать. Он должен быть динамическим, генериться во время работы приложения, а не статически нарисованной раз и навсегда картинкой. Так что быдловский QT Designer и все прочие рисовалки идут на хрен.

И код должен быть компактным и читабельным. Так что C++-ам тут не место. И Жабам тоже. И Питонам.

Ну вот - всем досталось :)

Динамический GUI - это как? Никто, кстати, не запрещает подгружать *.ui на лету :)

Не надо подгружать .ui на лету. Потому что их не надо рисовать. Их софтина сама должна генерить, например, из базы данных. По набору простых правил. А рисовать UI - это для дебилов.

Пожалуйста, приберегите свой тон для жены или тёщи. И сгенерируйте из базы GUI для текстового редактора или софтины типа KDevelop.

PS. К сожалению, если общение не может плавно перейти в рукопашный бой (С) гоблин - люди начинают хамить...

> An important feature of NTL are requirements for stored elements. Unlike STL, which has single copy-constructible and assignable requirement for whole library, NTL makes requirements on per container and even per method basis. This way NTL allows direct storing of any type of elements. NTL provides two or even three flavors for each basic ADT kind of container relative to requirements for elements.

Сапоги лучше бы тачал не пирожник, а сапожник. Когда в GUI-toolkit'е меня пытаются убедить что они лучше всех на свете разбираются в анализе сложности алгоритмов --- это подозрительно.

(ссылка на NTL, которую автор, видимо, имел ввиду: http://www.ntllib.org). На меня эта библиотека произвела впечатление .... ммм, напоминающее впечатление от речи нобля из "Сказки о тройке".

> а дальше пост не судьба прочитать?

если вы про:

> Я видел его реализации в виде unsigned short (понятно, где :) и unsigned int LE и BE вида.Это есть очень плохо. Часто делают даже так: берут std::string, рождаются от неё, и говорят, что эта String : public std::string хранит строчки в UTF-8. (так сделано в Crazy Eddie's GUI)

..то struct foo { int i }; то-же "болеет от нестандартности": попытка передать структуру по сети втупую может привести к массе неприятностей. но на то в писании даны htonx()/ntohx() и проблема be/le отпадает.

// wbr

>..то struct foo { int i }; то-же "болеет от нестандартности": попытка передать структуру по сети втупую может привести к массе неприятностей. но на то в писании даны htonx()/ntohx() и проблема be/le отпадает.

это всё понятно :) Другое дело, когда у строки есть метода для передачи "не втупую" - например, toUtf8() :) Однако, для реализации такого плана методов, (снаружи, например), надо надеяться на то, что строка внутри лежит, например, в UCS2BE, или ещё как-то. И на то, что другая библиотека, использующая, вроде бы, тот же класс, думает о нём так же, как и Вы :)

Подробнее об этих пробемах написано в исходниках упомянутого выше Crazy Eddie's GUI.

PS. В случае std::wstring надо, например, договориться о том, ucs4 там у нас или utf-32... И, понятно, о LE/BE...