Qt доступна теперь и под LGPL

> Хм... реквестирую версию Qt 5.0 на D :)

Биндинг к Qt4 в активной разработке: http://code.google.com/p/qtd/

А на каком языке будет написан сам фреймворк лично я разницы не вижу.

> Тормоза при сборке кстати это не так страшно. Особенно с учетом того, что это заметно только на ПК пятилетней давности.

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

>int private_field; // с*ка, не смей изменять это поле на прямое: убью!

Можно описание структуры поместить в .c файл, а в .h оставить только предварительную декларацию.

> Диспатчинг GUI сообщений на шаблонах тоже будет сложной, хрупкой и медленно компилирующийся хренью. По сравнению с тупым, надежным, сердитым и компилирующимся за один хлоп flex/bison boost::spirit тоже очень конкретно посасывает.

Это очевидно любому, кто пробовал и то и другое. В чем здесь проблема С++? Он для этого не предназначен.

Что мешает использовать препроцессоры и IDL-компиляторы, дополняющие С/С++? Так сделан и flex/bison, и СORBA, и QT, и еще много чего. Да и стандартный препроцессор многое может.

С++ и не претендует на звание "единственно верного языка". Это просто набор расширений С. Одно - для написания ООП кода, другое - для generic кода, третье - набор алгоритмов и контейнеров, и т.д.

Чем плох С++ для своих задач? Т.е. написание "реально кроссплатформенного" кода в стиле ООП, максимально приближенного к "железу"? Все остальное может быть прикручено "поверх" с помощью других инструментов.

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

Не замечал. Если, конечно, реальный проект - это не один огромный "экзешник" или либа.

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

Я вообще-то еще и гентушник

Даешь гуглохром на qt 4.5 под линукс!

>Что мешает использовать препроцессоры и IDL-компиляторы, дополняющие С/С++?

Какбе Строуструп говорил что препроцессоры - это зло и вообще они являются следствием недостаточной выразительности языка.

>struct Base { > int data; >}; > >struct Derived { > struct Base parent; > int extra_data; > // инкапсуляция: > int private_field; // с*ка, не смей изменять это поле на прямое: убью! >}; > >// невиртуальный метод >void Base_do_something(Base *self) { > printf ("data = %d\n", self->data; >} > >int main() >{ > Derived d = {12,15}; > do_something((Base*)&d); > return 0; >}

14G$i)

Там скобка пропущена.

Ну драсти, сборку можно и потерпеть один раз, тем более в процессе разработки никто не заставляет её каждый раз с нуля запускать. Лично я не испытываю проблем со сборкой тяжёлых проектов. Впрочем мне в этом и кеширование помогает. Проверенно, при включенном кешировании софт в Генте процентов на 30 быстрее собирается, а то и на все 50

>struct Base {
> int data;
>};
>
>struct Derived {
> struct Base parent;
> int extra_data;
> // инкапсуляция:
> int private_field; // с*ка, не смей изменять это поле на прямое: убью!
>};
>
>// невиртуальный метод
>void Base_do_something(Base *self) {
> printf ("data = %d\n", self->data;
>}
>
>int main()
>{
> Derived d = {12,15};
> do_something((Base*)&d);
> return 0;
>}

14G$i)

Там скобка пропущена.

> Nokia таким образом рассчитывает

> статус как лучшей в классе

> Коммерческая лицензия

ОРОРО, кому они втирают?

> Можно описание структуры поместить в .c файл, а в .h оставить только предварительную декларацию.

Ну, можно как в GTK: public поля в *.h файле, private -- в *.c Но зачем? Меня, например, в свое время такое смутило и я всерьез было подумал, что g_array (или как его там) реаллокейтится каждый раз при добавлении нового элемента).

Я считаю, что культурные программисты обязаны соблюдать культуру программирования, и если написано: "не трожь, с*ка", то культурный программист и не тронет, а вот хакИры... Эти да, поломают всю инкапсуляцию.

> Коммерческая лицензия и лицензия GPL также останутся доступными.

Учитесь, как надо продвигать свой продукт!

GPL-лицензия для продвижения KDE осталась? Осталась!

Коммерческая лицензия для быдлокодеров стесняющихся показывать свои творения осталась? Осталась!

LGPL-вариант теперь аннонсировали? Вот и нету недовольных, все при деле.

Мне вот только интересно, сколько быдлокодеров прилезет на огонек. Пойдут клепать свои утилиты, не остановишь!

В декабре тут был в одной конторе. Так там начальник IT-отдела пожаловался. Взял говорит одного такого студента на практику! Теперь сидим и думаем, зачем он столько окон наваял? И как это все теперь переписать.

>> Покажите мне хотя бы одну реализацию на С основных принципов ООП без приведения типов рантайм.

> Наследование.

Жду продолжения. Реализованы не все принципы.

>Остается то, что он написан на Си

В данном случае это не плюс, т.к. C++ с его name mangling -- большая проблема для написания привязок к различным языкам (в т.ч. языков гораздо более высокого уровня, чем C++, который для GUI подходит не лучшим образом).

> Какбе Строуструп говорил что препроцессоры - это зло и вообще они являются следствием недостаточной выразительности языка.

Значит он ошибался. QT же не от хорошей жизни пользуется своим собственным препроцессором. И boost активно пользуется стандартным препроцессором, даже библиотека для него есть.

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

Я это и имел ввиду.

> C++ с его name mangling -- большая проблема для написания привязок к различным языкам

Сразу видно специалиста по написанию привязок.

хорошее известие.

сам не пользуюсь, но уважаю )))))

> Если без них так сложно, то чем всех ликующих не устраивает венда или макос?

всем и устраивают.

>> Какбе Строуструп говорил что препроцессоры - это зло и вообще они являются следствием недостаточной выразительности языка.

>Значит он ошибался. QT же не от хорошей жизни пользуется своим собственным препроцессором. И boost активно пользуется стандартным препроцессором, даже библиотека для него есть.

Мне в последнее время закрадывается подозрение, что для ООП вообще места нет нигде. Данные проще извлекать при помощи SQL, тексты парсить - регэкспами, для rpc - использовать разные midl'ы, итд. Для всего есть более простое и надежное решение чем написание иерархии классов. Единственная проблема - видимость символов, префиксами функций получается слишком топорно.

опять в магазин вещества завезли? :)

>опять в магазин вещества завезли? :)

А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

Какой у Вас стаж программирования на C++ и в какой области?

гуйня в виде Qt - просто сказка. Swing тут и рядом не стоял.

>> опять в магазин вещества завезли? :)

> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

На страх и ужас нас рать. Главное - что работает. Легко разрабатывается и есть методики рефакторинга.

> гуйня в виде Qt - просто сказка. Swing тут и рядом не стоял.

Страшная сказка народов севера? :) Qt красив, не спорю, но писать гуй без замыканий как-то уже неудобно.

> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

А по-твоему, ооп --- это только гуйня?

Я хоть сам люблю C++ обертки над GTK типа wxWidgets и GTK#, но за Qt очень рад. Теперь будет значительно больше кроссплатформенных программ, и это не может не радовать. Многие разработчики, которых останавливала лицензия, могут с чистой совестью клепать софт. Так что Ура++

>> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.
> На страх и ужас нас рать. Главное - что работает. Легко разрабатывается и есть методики рефакторинга.

Ну и пусть, что говно получается, зато писать легко :)

ну например

>> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

>Какой у Вас стаж программирования на C++ и в какой области?

Ну начинал с Watcom 11, обрабатывал слайды с барабанного сканера. Потом - все по мелочи.

Вот новость так новость! Праздник на неделю! Ура Нокии!

Круто! А чем будут отличаться свободные версии от коммерческих?

>>> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

>> На страх и ужас нас рать. Главное - что работает. Легко разрабатывается и есть методики рефакторинга.

> Ну и пусть, что говно получается, зато писать легко :)

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

Что-то я не понимаю вопля на пять страниц типа "выкусите гткшники, гтккапец". Для всех школьников объясняю: gtk отродясь был gpl/lgpl. Так что гтк капец не грозит. А вот у куте агония, раз начинают множить лицензии.

>> А что, по твоему С++ хорошо подходит для гуйни чтоли? Что фреймворки С++, что Жава со свингом - страх и ужас.

>На страх и ужас нас рать. Главное - что работает. Легко разрабатывается и есть методики рефакторинга.

Ну гуевое окошко это походу машина состояний которая реагирует на события. Чето средств для хорошего, добротного описания машин состояний в С++&Co я не нашел. Лесенки switch-ей и if-ов это несерьезно. State Design Pattern - это еще более сомнительно: мне что, по классу на кждое возможное состояние окна писать?

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

Аргумент корректный. Но не применим к куте из-за тормознутости и ресурсоёмкости последней.

Отлично! Лицензия - единственное, что меня крайне разочаровывало в QT. Так что если нужно будет написать маленькую простенькую программульку с гуём на С - сделаю это с использованием GTK. Если на С++ - QT. Ибо нативно

GTK.-капец не будет. Кто так думает тот просто хочет так думать. А не кто не подумал что с такой политикой лицензий qt рухнет на несколько частей? Жаль. Мне очень жаль.

Вообще-то в заголовке новости никто не заметил явного 4.2. На данный момент сабж еще не случился. Ожидается только применительно к Qt4.5 в марте.

УРА! теперь кеды получат еще большее распространение, а следовательно станут еще лучше! Ура! Нокия, спасибо!

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

> Аргумент корректный. Но не применим к куте из-за тормознутости и ресурсоёмкости последней.

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

Куплю резину Нокиан Хаккапелита =)

>GTK.-капец не будет. Кто так думает тот просто хочет так думать. А не кто не подумал что с такой политикой лицензий qt рухнет на несколько частей? Жаль. Мне очень жаль.

Переведите кто-нибудь на русский

>Куча мелких шароварных поделок создаёт головную боль и внушает ненависть к человечеству.

fixed

> qt рухнет на несколько частей? Жаль. Мне очень жаль.

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

btw много лет назада уже был один форк Qt по портированию GPL-версии на Windows. Однако заглох сам по себе.

> Аргумент корректный. Но не применим к куте из-за тормознутости и ресурсоёмкости последней.

Qt в разы быстрее Gtk. См. тесты.

> btw много лет назада уже был один форк Qt по портированию GPL-версии на Windows. Однако заглох сам по себе.

А сейчас под винду Qt будет под LGPL?