RegExp'ы и в 2.x были. А вообще очень хорошая новость.

> RegExp'ы и в 2.x были.

А в 3.x они полноценные.

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

Вот чего я действительно не могу понять, так это что там за поддержка 2 мониторов может быть в библиотеке виджетов (пусть даже очень навороченной со всякими прибамбасами и пр. пр.)

Наверное это может означать следующее: если какое-то qt-шное окно при перетаскивании оставил на границе двух мониторов, она может сама перебросить его на тот, с каким площадь перекрытия больше и т.д.

Жалко, что троллтеху приходится писать Qt пользуясь очень ограниченным подмножеством C++. Ничего лучше Qt под X11 сейчас имхо нету, но если бы Qt писали на нормальном C++ - было б намного рульнее. У Qt3 есть сдвиги в положительном направлении (совместимость QTL с STL), но всё-таки этого мало. А виноват во всём, разумеется, биллгейтс. Троллям очень важна совместимость с MSVC++, как наиболее распространённой средой разработки под Windows, а что такое MSVC++ - думаю, многие себе хорошо представляют. Templates поддерживаются едва-едва (нет специализации, неправильное инстанцирование etc.), и вообще эта отрыжка фирмы M$ со стандартом C++ ничего общего не имеет :( Вобщем, троллям остаётся посочувствовать.

По поводу нескольких мониторов - из Qt'шных мануалов:

Multihead support Many professional applications, such as DTP and CAD software, are able to display data on two or more monitors. In Qt 3.0 the QDesktopWidget class provides the application with runtime information about the number and geometry of the desktops on the different monitors and such allows applications to efficiently use a multi-monitor setup.

STL в MSVC вполне сбе нормально работает. Я что-то проблем с шаблонами не заметил. В gcc их, кстати, попозже нормально стали поддерживать.

то, что у MSVC проблемы со стандартом: давно известно
и говорят, в новой версии их тоже полно

2 Havoc

Посмотри в сырцы/доки SGI STL или BOOST (есть такая рульная коллекция либов для C++ - http://www.boost.org) на тему MSVC specific problems. Маленький (очень) пример: нет возможности поддерживать operator-> для итераторов. Но это ещё так, мелочи. Есть куда более серьёзные проблемы. А сравнивать MSVC++ и g++ (3.x)... как бы это помягче сказать, нелогично. С точки зрения эффективности - примерно как каменный топор и межконтинентальную ракету, соответственно* :)

---------

* я имею ввиду поддержку языка. Что касается скорости компиляции - тут у g++ проблемы. Надеюсь, в 3.1 появится наконец поддержка precompiled headers. Хотя до тех пор я, наверное, уже разорюсь на Palomino... Блин, достало :(

Havoc, если тебя устраивает MSVC в плане поддержки С++ - то ты C++ просто не знаешь. Он не поддерживает частичную спецаилизацию и шалобы-члены, template template arguments (ну и operator-> как сказал ivan4th). gcc поддерживает *ВСЕ* и номинально поддерживал это года 2 назад! В VC проблемы с много чем еще (не помню - давно с этим отстоем не парился). И в планах пофиксить это у MS нет (вроде есть бета VC, так вот в ней ничего не изменилось).
А gcc был первым компилером (как минимум первым доступным на x86), который нормально поддерживал шаблоны (и поддерживал частичную специализацию аж в 98 году - наверно ее больше никто тогда не поддерживал).

Привет!
Как я понял из постов msvc гадость еще та.
А как all относится к bcc??

в BC++, вроде, все достаточно хорошо

bcc - на порядки лучше по поддержке C++ чем VC (всегда таким был, и есть как я понимаю), но по-моему из того что он не поддерживает - шаблоны-члены и template template arguments (то есть вроде он поддерживает частичную специализацию - не уверен точно). Но хоть его разработчики стараются что-то исправить. Хотя все-равно gcc поддерживает стандарт С++ на порядки лучше - наверно поддерживает процентов на 99.9%.

Дык gcc 3.x свежий относительно. А пока я сидел на фре 3.3 с 2.7.2.3 вроде, были с шаблонами большие проблемы. С STL проблем нету, мне для VC не приходилось делать что либо специфичное. А чем итераторы такие особенные, что у них -> нельзя сделать? В auto_ptr например прекрасно работает.

А Борланд... Из поделок MS и Borland я выберу все же MS. Ибо BCB глюкав неимоверно, и на его глюки я натыкаюсь гораздо чаще, чем в MSVC. Причем глюки, которые логически объяснить невозможно.
А то, что какие-то фишки нельзя использовать, это не так страшно, имхо, чем глюки на ровном месте.

>Havoc, если тебя устраивает MSVC в плане поддержки С++ - то ты C++ просто не знаешь

Если использовать все фичи C++ сразу, то можно застрелиться. :)
Да и о какой версии VC речь идет.
А еще дайте, плиз, пример програмки. Я протестю на BCB, VC и GCC.

>А сравнивать MSVC++ и g++ (3.x)... как бы это помягче сказать, нелогично

Еще бы. Когда появился первый и второй.

int main()
{
int S = 0;
for(int i = 0; i< 20; i++)
S += 2;
for(int i =0;i<40;i++)
S *=3;
return 0;
}

вроде, на MSVC это не компилится
даже на последнем (который .NET)

Доки читать надо.
cl /Za test.cpp (VS6 SP3)

Я имел в виду навороченный примерчик с шаблонами и прочими C++ фичами.

2Havoc: gcc.gnu.org/pub/gcc/gcc-3.0.1/testsuite-3.0.1.tar.bz2 :)

ну и чтоб с make и прочими file/find/text/sh-utils не париться мона cygwin без gcc поставить :)

О примерах: во-первых в стандарте на С++ на каждую фичу есть коротенький пример ее иллюстрации.
Ну и более интересная вещь: в сырцах STLPort (www.stlport.org) есть каталог stlport/config/new_compliler где лежит configure который поверхностно детектит все возможности компилера. Было бы очень интересно увидеть что он говорит о последнем VC и BCB. Про gcc он говорит что все поддерживается.
Ну и gcc-2.7.2.3 все-таки был на порядки лучше тогдашних компилеров - он уже тогда поддерживал частичную специализацию и шаблоны-члены.

msvc делает всех, а особенно любимый многими watcom, по части скорости получающихся программ. Заявляю это ответственно. Скажем так, процессор ppro и дальше. Интеловский его делает на некоторых вычисленных задачах, особенно если включена векторизация, но в целом похуже (ненамного). Borland - вообще отстой, в пятой версии опасно было оптимизацию включать, хотя для менюшек и так сойдет - здесь borland вне конкуренции среди c++ сред. gcc 3.0 я не видел в действии, gcc 2.95 был слабее. К тому же у visual с++ есть одна приятная особенность, особенно по сравнению с g++ - скорость и небольшой объем c++ программ. Если c код у многих компиляторов довольно приличный, то из c++ получаются немаленькие и небыстрые программы, непонятно почему.

2 Havoc - как заставить MSVC родить ежа

LL - The Lambda Library (http://lambda.cs.utu.fi/) -- LOL, LOL, LOL и еще раз ROTFL :)))

P.S. gcc-3.0.1 - всё путем :)

проблема с итераторами в MSVC

Трабла, видимо, состоит в том, что если у итератора определен operator->, то для struct/class/union все будет ok, но при инстанцировании скажем list<int>::iterator MSVC скажет, что operator-> для int неопределен и все тут. Это действительно так, но если бы все было сделано по стандарту, то компилеру бы не стоило и думать об operator-> пока он не потребуется. Вообще, может, конечно, эту проблему можно было бы решить через специализацию шаблонов, но этой фичи в MSVC тоже нет :(

Ok, MSVC чего-то не поддерживает, спорить не буду. Но не только ж по этому оценивается компилятор. Также для меня имеет значение качество кода, кол-во глюков, требовательность к ресурсам, скорость и т.д. и т.п.

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

> LL - The Lambda Library (http://lambda.cs.utu.fi/) -- LOL, LOL, LOL и еще раз ROTFL :)))

Ага, тестирован только на GCC 2.95. Неудивительно. Хотя щас поглядим.

По поводу lambda_library:

На gcc 2.95.3 собралось без вопросов.
После убирания gcc - специфичных опций из Makefile попробовал VC6 и BCB5.

Ни тому ни другому собрать не удалось. Матерятся на их hpp файлы.

Борланд тоже сел в лужу?

На ваткоме или симантеке попробовать у меня нет возможности. Если есть желание, скачайте. Она всего 55к весит.

lambda library

subj не компилится под MSVC не потому, что авторы его заточили только под gcc. С сайта LL:

Contributions

...

Jeremy Siek made a serious attempt to accommodate the library to cope with MS Visual C++ 6.0 sp3 compiler and Peter Higley tried to port LL to Intel 4.5 compiler. Both tasks were impossible, but thanks for trying.

Вобщем, проблемы с MSVC носят фундаментальный характер.

А вообще, кто знает, есть ли какой-нибудь компилер под Linux/Intel или хотябы Windows, который ближе к (или по крайней мере не дальше от) C++ standard, чем gcc-3.0.1, и при этом работает побыстрее ? Мне это в части Linux/Intel с практической точки зрения интересно, т.к. ищу альтернативы апгрейду с PIII-450, чтобы одна моя прога побыстрее компилилась (11 min полный билд - в принципе немного, а если не всё перекомпилится, то меньше, но всёравно за@@ывает). gcc-2.95.x на этой софтяре садится в лужу, генерит неправильный код (проверял assembly output) для одних модулей, для некоторых других, насколько я помню, даёт ICE (Internal Compiler Error).

Борланд ее тоже не компилит. И интел, судя по твоей цитате.
Так что MS VC тут крайним не является :)

To ivan4th:
>А вообще, кто знает, есть ли какой-нибудь компилер под Linux/Intel или >хотябы Windows, который ближе к (или по крайней мере не дальше от) C++ >standard, чем gcc-3.0.1, и при этом работает побыстрее ?

KAI. Не поддерживает только:
two-phase name binding, export templates, нельзя добавлять частичную специализацию шаблона-члена класса вне определения объемлющего класса.
Мне кажется, это разумная плата за значительно меньшее время компиляции (по сравнению с gcc 2.95.x-3.01) и _намного_ лучшее качество кода. По крайней мере, на моем коде, доверху набитом шаблонами, и так далее., интенсивно использующем stl, boost (особенно по част Boost.graph) и blitz все компилируется как часы. И. По-моему, без тех фичей, которые не поддерживаются kai, в 99 случаях из 100 можно обоитись.
А, по большому счёту, ближе gcc 3.0.1 стандарт сейчас никто не подерживает.

To ivan4th:
>LL - The Lambda Library (http://lambda.cs.utu.fi/)

А зачем вам, если не секрет, LL? По-моему, возможность наловить с ней геморроев намного превышает выгоды от её использования...
И кстати говоры, примеры в свежескачанной LL не компилируются даже gcc-3.0.1 Что неудивительно -- видимо, авторы и не пытались это сделать, раз пишут:
#include <iostream>
bla-bla-bla....
cout << ... << endl;

sorry for LL

да, я, тут, по ходу, наглючил, и lambda скомпилил не тем компилером (gcc-2.95.3 вместо gcc-3.0.1, забыл PATH поменять или Makefiles подправить). Sorry. С gcc-3.0.1 у LL действительно есть проблемы. Это, конечно, понятно, т.к. когда LL последний раз обновляли gcc-3.0.1 ещё не было, и ничего лучше gcc-2.95 авторы видимо добыть не смогли. Так что LL заточен под глюки 2.95.

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

2 Havoc: sorry за глюку, но только не надо утверждать, что MSVC все что нужно поддерживает. Если надо, я могу поискать еще доказательств, получше чем Lambda. Вроде http://www.boost.org/status/compiler_status.html

2 AC

за инфу насчет KAI - thanks, попробую.

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

Там конструкции, imho, ещё сложнее и неочевиднее, кроме того, компилятору от них пло-о-охо, долго он думает, хоть у меня и не PII-450. Кстати, KAI эту LL тоже не жрет, по крайней мере, примеры.

To Havoc & ivant4th:
По поводу MSVC, я тут как-то постил своими рабочими ручками проверенный 'попунктный' список несовместимостей MSVC со стандартом по части шаблонов.
http://www.linux.org.ru:8100/view-message.jsp?msgid=84061
Soobschenie ot AC (menya:) ot (2001-05-21 23:08:14.0)

LL, KAI

Мне, честно говоря, не вполне понятно, чего неочевидного в вещах вроде

iter = find_if(a.begin(),a.end(), free1 > 10 && free1 < 20 );

кроме того, samples от LL gcc-2.95.3 быстро скомпилил, за исключением кажись stl_algorithms_test.cpp. Так что не все так плохо. Может быть хотя бы в след. году найду время перетащить LL под g++ 3.x.

А KAI я скачал, запросил на сайте evaluation license, мне прислали мессагу - мол погоди пару дней. Я подозреваю что до тех пор я maybe уже и без лицензии с ним разберусь, благо же с flexlm дело уже имел, и успешно (правда, под дигитал унихом ныне aka Tru64 - ассемблер у альфы беспонтовый, пришлось перехватчик системных вызовов на основе alpha-trace сделать...) Если вещь хорошая, я бы за нее, конечно, $400 заплатил, будь у меня лишние $400. Хотя в этом случае я бы пожалуй лучше до Athlon XP грейданулся и оставил бы g++.

>Мне, честно говоря, не вполне понятно, чего неочевидного в вещах вроде
>iter = find_if(a.begin(),a.end(), free1 > 10 && free1 < 20 )

То, что в переменных вида freeХ, var, etc. можно оченно легко запутаться (особенно если их несколько в выражении). А читабельность? А сопровождаемость? Кроме того, imho, это хорошо годится для простых конструкций (для которых можно и адаптеры подогнать, особенно если есть своя библиотечка), а для более-менее сложных все равно придется писать свои функторы. Но ни класс по месту объявить, ни свободные переменные подогнать. Так что, так удобно, как в фунциональных языках, по любому не будет. Поэтому я считаю, что лучше и не извращаться....

>Если вещь хорошая, я бы за нее, конечно, $400 заплатил

В этом смысле, мы её уже давно купили...

>Хотя в этом случае я бы пожалуй лучше до Athlon XP грейданулся и >оставил бы g++.

КАЙ генерит гораздо лучший код, и по объему (у меня разница доходила до двухкратной по сравнению с gcc2.95.x), и по скорости (процентов 30 у меня бывает), особенно в случае интенсивного использования, так сказать, современного стиля с++. Вы же свои приложения не только у себя дома запускать собираетесь?

Кстати, хотел спросить как отлаживать С++ код при использовании KAI - он же полностью убирает ассоциацию сырцов и С-кода который он генерит.. Под линухом и вынью.
Ну и второе - можно ли (нелегально конечно) использовать KAI для генерации С-кода для разных аппаратных платформ (главное - с разной разрядностью - 32 и 64 бита) и разных ОС (например использовать KAI под линух чтобы генерить С-код чтобы потом собирать только этот код под виндой, скажем HP и Tru64)? Не заложена ли ширина машинного слова где-то в алгоритмы оптимизации?

2 AC

По поводу функторов и в чем проще запутаться. Многие вещи в STL представляют собой не очень тонкий намек на то, что не хотелось бы для каждой мелочи делать функтор, т.к. сие геморно. К примеру, binder1st, binder2nd, mem_fun, greater, less, logical_and, multiplies, divides, ... Но, скажем, в терминах SGI STL LL'евый фрагмент

iter = find_if(a.begin(),a.end(), free1 > 10 && free1 < 20 );

будет выглядеть так (SGI - тк в стандарте нет compose2, как впрочем, и compose1; тип значения - предполагается, что int): iter = find_if(a.begin(), a.end(), compose2(logical_and<bool>(), bind2nd(greater<int>(), 10), bind2nd(less<int>(), 20)));

по-моему, если LL юзать, получается красивше и понятнее.

не знаю, может я не въезжаю, но имхо функтор тут писать - натуральный overkill. уж проще написать что-то вроде

iter = a.end(); for (vector<int>::iterator it = a.begin(); it != a.end(); ++it) if (*it > 10 && * it < 20) { iter = it; break; }

Получаем рейтинг подходов: 1. LL 2. обычный for вместо стандартного алгоритма 3. STL adaptors 4. отдельный функтор

я неправ? все-таки в free1 и free2 (free3 в крайнем случае, а больше нету) запутаться не так просто.

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

По поводу KAI vs Athlon XP: суть проги, над которой я сейчас тружусь, такова, что, во-первых, ее запускают только на одной машине* (т.к. эта прога - верхний уровень системы управления электронного ускорителя, изврат на тему SCADA :), а во-вторых, этой самой машины (хоть она и послабее моей) вполне хватает (интенсивных вычислений нет). Так что хорошая оптимизация тут пока что некритична.

------

* я имею ввиду тех, кто пользуется программой, а не разработчика (тоесть меня)

>Кстати, хотел спросить как отлаживать С++ код при использовании KAI - >он же полностью убирает ассоциацию сырцов и С-кода который он генерит..

Стоп-стоп... В каком смысле отлаживать? Отлаживать промежуточнуй С-код? Не знаю. Отлаживать 'конечную' программу -- они поставляют модифицированный gdb.

>Под линухом и вынью.

Под линуксом -- с помощью их gdb. Под вынь -- никак, последний KAI для выни был 3.2. Теперь они его не делают и не будут делать никогда, поскольку как оптимизирующий компилятор под вынь теперь позиционируётся Интел С++.

>например использовать KAI под линух чтобы генерить С-код чтобы потом >собирать только этот код под виндой, скажем HP и Tru64)? Не заложена ли >ширина машинного слова где-то в алгоритмы оптимизации?

Думаю, что заложена... Скорее всего, в light-weight objects optimization, при использовании restrict, может быть, в инлининге... Кроме того, я полагаю, что так вообще не покатит, поскольку, во-первых, промежуточный С-код совместим только с backend-компилятором на данной платформе, а во вторых, не пройдёт линковка, поскольку линкер на целевой платформе ничего не будет знать про ti-files, обработка которых на стадии линковки необходима для правильного инстанцирования шаблонов. Так что, не думаю...

>будет выглядеть так (SGI - тк в стандарте нет compose2, как впрочем, и >compose1; тип значения - предполагается, что int): iter = >find_if(a.begin(), a.end(), compose2(logical_and<bool>(), >bind2nd(greater<int>(), 10), bind2nd(less<int>(), 20)));
>по-моему, если LL юзать, получается красивше и понятнее.

А если _один_раз_ написать свою библиотечку простых функторов, то будет:
find_if(a.begin(),a.end(),in_interval(10,20));

В любом случае, при использовании того же KAI функтор ничего не стоит. И совместимо со всем -- достаточно включить нужный заголовок.

>Получаем рейтинг подходов: 1. LL 2.

В любом случае, LL совместима только с одной версией одного компилятора -- поэтому для серьезных проектов никак не годится. Да и, была бы действительно ценная вещь, её бы давно включили в boost.

> Стоп-стоп...  В  каком  смысле  отлаживать?  Отлаживать  промежуточнуй
> С-код?  Не  знаю.  Отлаживать  'конечную'  программу -- они поставляют
> модифицированный gdb.
Да, конечно я про то, что транслируется в С, а не С который компилится.
> Под линуксом -- с помощью их gdb. Под вынь -- никак, последний KAI для
> выни  был  3.2.  Теперь  они  его не делают и не будут делать никогда,
> поскольку    как    оптимизирующий    компилятор   под   вынь   теперь
> позиционируётся Интел С++.
Хм, то есть получается раньше под вынью при использовании KCC отлаживать
код невозможно было вообще? Оригинально.. И странно что они сдались
перед intel C++ (или им заплатили за уход с рынка?). Любопытно, а как у
intel C++ с поддержкой стандарта С++, не в курсе?
 Спасибо за ответ.

> 2 Havoc: sorry за глюку, но только не надо утверждать, что MSVC все что нужно поддерживает

Я не утверждал :) Я говорил об STL. Да и потребности бывают разные. Далеко не всегда нужны все инструменты из коробки. Просто для меня VC имеет другие приятности, благодаря которым я под виндами предпочитаю именно его, а не, например, Багланд.

2 AC
> http://www.linux.org.ru:8100/view-message.jsp?msgid=84061

Спасибо.

>Хм, то есть получается раньше под вынью при использовании KCC >отлаживать код невозможно было вообще? Оригинально..

Когда был KAI для выни, с ним поставлялся отладчик. Его нельзя использовать с четвертой версией, поскольку внутри она принципиально изменилась. В любом случае, использовать промежуточный код для компиляции на другую платформу нельзя. Если желаете более строгую информацию, я могу спросить в KAI, у нас хорошие отношения с их support.

> И странно что они сдались перед intel C++ (или им заплатили за уход с рынка?

Все гораздо проще. Intel просто купила KAI...

>Любопытно, а как у intel C++ с поддержкой стандарта С++, не в курсе?

В курсе. Получше, чем у MSVC, но все равно хреново... Хотя у них с KAI один фронтенд, у Intel C++ он более старый.

>Для того, чтобы они были полноценные, всего то и надо что подключить pcre. Надеюсь, они это и сделали - не реализовывать же этого монстра самим заново.

Во-во. Именно это они и сделали :( Из анонса:

Qt 3.0 also features a new and powerful Regular Expression Engine, which greatly simplifies complex text-manipulation operations. The syntax is compatible to, and as powerful as, Perl regular expressions, while at the same time including full support for Unicode.

Ради Unicode? Trolltech'у наплевать на уже существующие либы. Им они не нужны. Точно так же, как и Юникс. Их рынок - Win, потому как там за Qt платят деньги, а проблемы КДЕ'шников их не интересуют (это я о том, что скоро им предстоит переписывать весь KDE на использование QCOM.). Что там еще?

- Rich text engine that also supports richtext input/editing in addition to rendering - А место ли этому движку в библиотеке виджетов? Может, лучше было вынести его в отдельную библиотеку, чтоб было раз и навсегда?

- Qt Assistant eases browsing and finding information in the Qt Documentation - Мимо. У КДЕ'шников для этих целей всегда был Konqueror.

Мне так кажется, что дороги Qt и KDE все больше расходятся. Если на начальном этапе КДЕ'шникам нужна была всего лишь библиотека виджетов (каковой Qt тогда и была), то сейчас этот монстрик создает им больше проблем (вспомните переписывание KWord).

ради UNICODE следовало бы переписать стандартную либу, а раз гора не идет к Магомету...
Достал уже зоопарк 8-ми битных кодировок.

http://www.pcre.org/readme.txt:

If you want to make use of the experimential, incomplete support for UTF-8 character strings in PCRE, you must add --enable-utf8 to the "configure" command.

Так что насчет UTF-8 - это "пыль в глаза". Trolltech'у вообще наплевать на эту либу. IMHO, UNIX'у с Trolltech'ом явно не по-пути.

2 ANDI

Размеры реализаций (source): QRegExp - 106 Кб, QTextEdit - 120 кб. Если учесть то, что там заметная часть исходника - документация в комментариях (которую потом оттуда тролли qdoc'ом выдергивают), а так же размер остальной части библиотеки - не так много. Кроме того, если бы они вместо своего кода использовали другую библиотеку, ориентированную на 8-bit кодировки (в т.ч. UTF-8), то вышли бы дополнительные тормоза при обработке текста (в Qt все - QString, который Unicode, и пришлось бы постоянно конвертить текст туда-обратно).

QCom в 3.0 не включен, его "отложили" (т.е. исключили из документации, переименовали заголовочные файлы в *_p.h (qcom_p.h и т.д.) и посоветовали не использовать - но сами его юзают для designer'а, SQL драйверов etc.) - так что пока что KDE никто переписывать под QCom не будет.

Qt Assistant - это не браузер, это help viewer, который позволяет удобно просматривать доки Qt (с индексом etc.). Удобная штука. Konqueror сам по себе так не может.

KWord КДЕшников никто не заставлял переписывать, просто им так понравился QTextEdit, что они его backport'нули из Qt3 beta в 2.2.

Вообще, если какой-то из модулей Qt не нравится, то никто его не заставляет юзать. Модули даже можно отключать при компиляции Qt. Так что, из-за того что в Qt есть такие-то и такие фичи, которые к тому же можно отключить, мы на него забьем и будем юзать сишную кривость вроде Gtk+, OSF/Motif etc. ? Не логично.

2 ivan4th

Принимается.

>Кроме того, если бы они вместо своего кода использовали другую
>библиотеку, ориентированную на 8-bit кодировки (в т.ч. UTF-8),

UTF-8 не совсем 8 бит :) Скорее от 8 до 24.

>то вышли бы дополнительные тормоза при обработке текста (в Qt все - QString,
>который Unicode, и пришлось бы постоянно конвертить текст туда-обратно).

Фонтов надо юникодных наделать, и не надо ничего конвертить. В жабе строки все юникодные, и ничего. Я тут с J2EE потихоньку ковыряюсь, и для себя решил, что я не буду возиться с кодировками, а html буду отдавать в UTF-8. Его даже lynx понимает.

> изменилась.   В  любом  случае,  использовать  промежуточный  код  для
> компиляции  на  другую  платформу  нельзя.  Если желаете более строгую
> информацию,  я  могу спросить в KAI, у нас хорошие отношения с их sup-
> port.
Большое спасибо, не стоит - у меня было просто праздное любопытство.
Спасибо за остальные ответы.
> строки  все  юникодные, и ничего. Я тут с J2EE потихоньку ковыряюсь, и
> для  себя  решил,  что  я  не буду возиться с кодировками, а html буду
> отдавать в UTF-8. Его даже lynx понимает.
А что, lynx самый тупой браузер будет, что-ли? Он *очень* интеллектуальный,
возможно по-продвинутее konq и opera (самый тупой браузер это links в плане
http & encodings). А в utf8 отдавать не надо сайты - во-первых об[ем больше
становится, во вторых NN дурными фонтами русский в utf8 показывает.

Имхо, объем - не слишком большая плата за удобство. Английские буковки все равно в байт помещаются. Плюс картинки. Так что относительный объем увеличится ненамного.
Не встречался с приколами, когда сайт вроде в win1251 Или koi8, а внутри руские буковки выглядят в виде &#xxx; ? :)

Ты о каком NN говоришь? NN6 и Мозиллы вроде нормально работают.
Да и пора бы. А то юникод пока остается костылем. В WinNT хоть большинство ф-ий юникод хавают.

> Имхо, объем - не слишком большая плата за удобство. Английские буковки
> все  равно  в  байт  помещаются.  Плюс картинки. Так что относительный
> объем увеличится ненамного.
Ну а для русского символ - 2 байта. Так что разница есть.
> Не  встречался  с  приколами,  когда  сайт вроде в win1251 Или koi8, а
> внутри руские буковки выглядят в виде &#xxx; ? :)
Ну в NN4 не реализованы hexadecimial numeric character references.
Вот они и вылезают.
> Ты о каком NN говоришь? NN6 и Мозиллы вроде нормально работают.
Я про NN4 естественно. На старых машинакх только он юзабелен.. В NN6
и Мозилле все ОК c utf8.

>Ну в NN4 не реализованы hexadecimial numeric character references.
>Вот они и вылезают.

Реализованы. По крайней мере два года назад он &#xxxx; понимал правильно.

>Ну а для русского символ - 2 байта. Так что разница есть.

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