LINUX.ORG.RU

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

О. Хоть один человек додумал мою мысль до состояния вхождения в противоречие со здравым смыслом ;-)

Теперь, надеюсь, желающих поклеймить moc будет меньше ;-)

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

Предвидится. Правда, в этом новом стандарте пришлось слегка изменить имя языка. И два креста заменить на двойной крест ;-)

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

Т.е. на этом языке, на котором за место 2-х маленьких крестов стоит один БОЛЬШОЙ крест (к тому же двойной), QT без всяких там moc-ов и прочего костелизма идет???

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

svyatogor - а ты много с wxWidgets работал? Какие там проблемы со стабильностью и документацией?

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

скачал, скомпилил, падает в сигфолт при XCreateCI :((, то есть в текстбокс хочу-чё-нить ввести, и сигфолт. Иксы X Window System Version 6.8.2 Release Date: 9 February 2005 X Protocol Version 11, Revision 0, Release 6.8.2

krum
()

Красотааа...

Народ, слабО вместо трёпа пойти написать бенчмарк производительности одного софта на разных тулкитах? А то вы как-то забываете, что аргументы без цифр называются трёпом.

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

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

> А что? Новый стандарт языка, в котором все означенные выше недостатки будут исправлены, не предвидится?

Это не недостатки. Компилятор языка конфигурировать файлы компоновки и генерировать код не должен. А те кто иронизируют на тему плюсов и шарпов наверняка незнают ни того, ни другого.

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

> Компилятор языка конфигурировать файлы компоновки и генерировать код не должен.

Не понял? А что он тогда должен делать если не генерировать код?????????

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

> Не понял? А что он тогда должен делать если не генерировать код?????????

Имеется ввиду код на С++, а не машинный.

mutronix ★★★★
()

Забавно. Многие анонимусы подхватили тему, но не поняли о чем она.. ;)

2AP: Следует оценивать в первую очередь не производительность самих тулкитов, а производительность труда программистов, использующих эти самые тулкиты. Потому и придумали все эти слоты и сигналы в Qt - чтобы удобно было. А так любой алгоритм можно запрограммировать и в алгорифмах Маркова. Утрирую, конечно, но основная мысль, думаю, понятна.

Тем - кто путает C++ и C#: см. новый старый язык программирования C++/CLI из .NET v2.0.

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

Да и я собственно про тоже... Если весь костылизм с moc-ами и т.д. и т.п. удобная вещь, то почему бы не сделать это частью стандарта C++???

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

Наверное, потому, что очень сложно и черевато многими опасностями - вносить изменения в язык программирования.

Обычно все идет по следующему сценарию. Сначала накапливается круг задач, которые не удается эффективно решать в рамках имеющихся средств. Потом меняются или усовершенствуются сами средства, т.е. усовершенствуются или меняются языки программирования. Вопрос весь в том, насколько это актуально сейчас. :)

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

> Человек сделал деревянную игрушку и продал ее - он нормальный. (MS)
> Человек сделал деревянную игрушку и отдал ее народу - он святой! (Linus)

а как же папа Карло?

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

А какие опасности то, если эти изменения в стандарте не вызовут НЕ совместимост с уже написанными программами???

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

> А какие опасности то, если эти изменения в стандарте не вызовут НЕ совместимост с уже написанными программами???

Дело не только в этом. moc-препроцессор хорошо работает и без всякого втраивания. А запихивать все в одно - это принцип сами знаете какой конторы. Миллион программистов на С++ никогда не слышало про Meta Object Compiler, зачем он им здался? Тем более в виде стандарта. С\С++ - языки общего назначения и все что не универсально из языка выкидывается. То что очень нужно, идет в виде стандартных библиотек. Остальное отдельно. Благодаря такому подходу С\С++ не превращается за несколько лет в хлев(наподобие всяких фреймворков) и не работает по принципу "this feature gonna be implemented in the next version".Кароче, читать Страуструпа.

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

> А какие опасности то, если эти изменения в стандарте не вызовут НЕ совместимост с уже написанными программами???

Скорее даже не опасности, а целый ворох грядущих проблем...

Если говорить конкретно о слотах и сигналах, то они могут быть очень полезны не только при написании GUI. Их область применения могла бы быть гораздо шире, но боюсь, что сам по себе этот механизм слот-сигнал лишь видимая макушка айсберга. У меня есть стойкое убеждение, что в Qt реализован в той или иной мере свой внутренний сборщик мусора. Пусть даже неявно, но жизненный цикл многих Qt-объектов управляются этим встроенным сборщиком. Иначе я просто не представляю себе, как можно реализовать те же слоты и сигналы, когда циклические ссылки являются скорее правилом, чем исключением... Если я не прав, то пусть AlexM поправит меня на этот счет, поскольку мои представления о Qt куда более, чем скромные. :)

Получается, что из желания поддерживать только слоты и сигналы вытекает необходимость поддерживать еще и сборщик мусора на уровне самого языка, пусть даже и опционально как это предлагается в C++/CLI. А это уже заявка на слишком серьезные изменения в стандарте языка. Кроме того, мы все знаем как к подобным инновациям относится сам Бьерн Страуступ :)

Между прочим, меня очень привлекает дуализм будущего C++/CLI. Мне кажется, что за таким подходом - будущее, когда одновременно можно смешивать Java- и С/C++- стили программирования [и управления памятью] в одном и том же коде.

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

> На самом деле лицензия должна быть одна. GPL и точка. всё остальное - от лукавого. Хотя...тролли очень удачно использовали в свое время неспособность девелоперов кде создать свой тулкит и незнание C

ах, как вас плющит и колбасит расписаться в собственной некомпетентности! такое бывает. ну давайте же, давайте, пишите, Шура..

// wbr

klalafuda ★☆☆
()

А это правда, что GPL версия QT4 будет доступна под windows? Именно этого я думаю сейчас не хватает QT.

Если будет QT под виндовс, то линуксовые проги портируют под винду. И программисты, которые пишут для windows смогут использовать QT в своих программах, естественно распространяя их под GPL, а потом эти программы портируют под linux. То есть от этого линукс круто выиграет.

А если люди допустим будут пользоваться QT или KDE прогами под винду, потом они задумаются, а зачем нафиг им винда и перейдут на линукс.

Также очень хотелось бы kde под виндовс, на работе поставить, имхо удобнее стандартной xp

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

> А это правда, что GPL версия QT4 будет доступна под windows? Именно этого я думаю сейчас не хватает QT.

а собссно новость почитать слабо? :)

---cut---
Availability

The Qt 4 Release Candidate is offered both under a special beta evaluation license on all desktop platforms to existing customers and under a GPL license for Mac OS X and Linux/X11 for the Open Source community. Qt/Windows will be available under the GPL license at Qt 4 launch. The Release Candidate is now available for download from the Trolltech website at http://www.trolltech.com/download/betas.html, with corresponding documentation available at http://doc.trolltech.com/4.0/qt4-intro.html.
---cut---

// wbr

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

>а собссно новость почитать слабо? :)

Кто же на ЛОРе новости читает? Я сюда прихожу исключительно почитать комментарии анонимусов :) А по ссылкам перехожу в половине случаев.

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

Может конечно всякие свистелки-перделки типа uic и не стоит включать в стандарт... Но я не считаю, что сигналы/слоты, свойства и т.д. такой уж экзотический и редко используемый инструмент, в этом я абсолютно согласен с D!!! А то что это потенциально может повлечь за собой появление сборки мусора, ну что... туда ему и дорога... :) Вообще я не понимаю из каких таких соображений Страуструп не хочет внедрять опционально эту самую сборку мусора в C++???!!!

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

Сборка мусора, как мне кажется, будет только тормозить. Сейчас и на C++ можно писать без мусора инкапсулируя создание и удаление обьектов в smartpointer-ах,proxy и тд. если проект большой (а если маленький - то фиг с ним, с мусором).

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

>>>Может конечно всякие свистелки-перделки типа uic

>lol. ты хоть знаешь, что это такое и для чего нужен ?

The uic reads an XML format user interface definition (.ui) file as generated by Qt Designer and creates a corresponding C++ header file.

А что??? Это... я так... Для примера...

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

Блаженное дитя, чтобы компилировать проги на Винде, нужен Visual C++ от Microsoft. QT4 под GPL для Виндов поможет Микрософт еще поднять продажи VS, и я за них рад.

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

> Вообще я не понимаю из каких таких соображений Страуструп не хочет внедрять опционально эту самую сборку мусора в C++???!!!

Страуструп заявляет буквально следующее [Дизайн и эволюция яызка C++, 10.7]:

"Общий вывод таков: сборка мусора желательна и возможна, но мы не можем позволить ..."

"В C++ надо включить необязательный сборщик мусора."

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

Что касается слотов и сигналов, то сейчас я думаю, что там не обязательно иметь супер-навороченную систему типа Java GC, но какое-то управление "жизнью" объектов все равно должно присутствовать, пусть и узко специализированное... Использование же глобального GC - это лишь один из вариантов решения, и, может быть, не самый лучший :)

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

>>А что??? Это... я так... Для примера...

Для какого ещё примера ? Ты во-первых не ту часть мануала показал, что означает, что ты его даже не читал. Во вторых, как может _утилита_ быть, как ты выражаешься, свистелкой-перделкой ? И причём тут стандарт С++ ?

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

Ну допустим не ту... А какую надо тогда??? А???

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

> На глаз быстрее работает чем Qt3?

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

кто скомпилячил, посмотрите что они вытворяют в demos/deform/deform - это якобы натуральные векторные деформации, а не тупое масштабирование пиксмапа

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

> У меня есть стойкое убеждение, что в Qt реализован в той или иной мере свой внутренний сборщик мусора

В той или иной мере - да :)

Все виджеты собираются в стеке виджетов своих "родителей" (переменная parent). При репаренте или удалении стандартные методы класса Qt (или QWidget) просто следят за этим делом и при необходимости обновляют стеки. Соответственно, при деструкции виджета или QApplication дергаются деструкторы всех его наследников, а родителям говорится что-то типа "я убит", чтобы родитель выбросил соответствующий виджет из своего стека.

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

> lol. ты хоть знаешь, что это такое и для чего нужен ?

Конечно он не знает. Он предпочитает переписывать кучу кода для того, чтобы подравнять виджеты на форме. Причем, судя по всему, в уже скомпиленой программе :)

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

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

Понятно. А вообще тролли обещали поддержку OpenGL при выводе графики. Типа как это делается в MacOS X.

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

> Все виджеты собираются в стеке виджетов своих "родителей" (переменная parent).

Интересно, а там возможны [циклические] зависимости между самими стеками виджетов? Если - да, то управлять такими стеками - совсем не простая задача. Если же - нет, то многие вопросы отпадают :)

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

> Интересно, а там возможны [циклические] зависимости между самими стеками виджетов?

А как ты себе представляешь быть биологическим отцом своего деда? Объект всегда в контексте своего родителя.

baka-kun ★★★★★
()

Ругающие moc недоучки меня радуют...

ДЕТИ! Вам для начала придется убить LALR генераторы (yacc|bison), и остаться без gcc. Затем убейте ASN.1, и останьтесь без большинства сетевого софта/железа. Затем убейте себя, поскольку устанете вычищать мир от прочих "компиляторов чего-то" в C|C++, ибо их наличие -- тот самый unix-way.

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

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

> А как ты себе представляешь быть биологическим отцом своего деда? Объект всегда в контексте своего родителя.

Все. Вопрос отпал.

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

>Компилятор Visual C++ (без IDE) самых последних версий - совершенно >бесплатный! :)

А также без PlatformSDK. Короче им ничего кроме cout<<"Hello world!"<<endl; не откомпилируеш.

Может кто портировал под него из mingw win32api?

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

кстати, наблюдается занятная вещь с QApplication. Если mainWidget был создан динамически, т.е. с помлщью new, он почему-то не удаляется при выходе программы (!). Т.е. если ваша программа выделела 100 Mb памяти, они так и остануться висеть, при следкющем вызове программы прибавиться ещё 100, и т.д. до исчерпания памяти. Нужно после QApplicaion::exec() самому удалять mainWidget. В KDE и KApplication такого нет.

P.S. QT 3.2, KDE 3.2

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

Если программа перед выходом не освободила занятые ресурсы (например память), то ОС сама вернет пямять, закроет файлы. Едиственное что остается в неизменном состоянии это средства семафоры IPC и сегметны shared memory. В некоторых command-line tools ради скорости даже деструкторы у объектов не вызывают не говоря уж об освобождении памяти. Единственной мне известной недо ОС которой не может убирать за процессами ресурсы является M$DOS и Win3.11

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

Нда. Похоже Xserver-side ресурсы сервером не вычищаются:

[nick@home nick]$ ps u 1103 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1103 1.9 4.6 27200 24220 ? RL 10:41 1:07 X [nick@home nick]$ evolution & [nick@home nick]$ killall -9 evolution [nick@home nick]$ ps u 1103 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1103 1.9 4.8 28092 25188 ? RL 10:41 1:07 X

Может он чистит не сразу, а попозже?

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

Нда. Похоже Xserver-side ресурсы сервером не вычищаются:

[nick@home nick]$ ps u 1103
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1103 1.9 4.6 27200 24220 ? RL 10:41 1:07 X
[nick@home nick]$ evolution &
[nick@home nick]$ killall -9 evolution
[nick@home nick]$ ps u 1103
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1103 1.9 4.8 28092 25188 ? RL 10:41 1:07 X

Может он чистит не сразу, а попозже?

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

> Блаженное дитя, чтобы компилировать проги на Винде, нужен Visual > C++ от Microsoft. QT4 под GPL для Виндов поможет Микрософт еще > поднять продажи VS, и я за них рад.

Виндовая Qt3 прекрасно собирается MinGW'ом, и с Qt4, думаю, тоже проблем не будет.

Кстати, недавно узнал, что существует GPLная версия Qt3 под винду. http://kde-cygwin.sourceforge.net. Пусть урл вас не смущает, она работает без всякого cygwin'а.

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