Qt 4.4

> Ты слил, так как сказал что я могу их не использовать, так как тот факт что я могу их не использовать не отменяет того что они _есть_ в языке.

С++ ушел из ниши непрофессионалов. На нём из начинающих практически никто не пишет. Поэтому довод о том, что что-то есть в языке, что якобы можно использовать неправильно - несостоятелен, просто потому, что некому это использовать неправильно. Есть, например, reinterpret_cast, указатели, и что? Это не значит, что все поголовно побежали сразу всё ломать. Или препроцессор и шаблоны. Можно сколько угодно говорить, что препроцессор - устаревшее наследие от языка Си, но тем не менее, в умелых руках и они превращаются в мощный и удобный инструмент. Естественно, в сочетании с другими, не сами по себе. Не нужно писать программы исключительно на reinterpret_cast-ах, указателях и макросах. Но иногда всё это бывает очень и очень полезно.

Чем отличаются (кроме размера) qt-all-opensource-src-4.4.0.tar.bz2 и qt-x11-opensource-src-4.4.0.tar.bz2, кто знает???

>Чем отличаются (кроме размера) qt-all-opensource-src-4.4.0.tar.bz2 и qt-x11-opensource-src-4.4.0.tar.bz2, кто знает??? all от X11 отличить не можешь?

Прочел всю ветку, потому как сам использую С++. Изучаю его около года и параллельно пишу на нем программу для трехмерной визуализации геологических дланных. Я не программист по профессии, скажу сразу. В качестве gui библиотеки использую Qt, ну и естественно openGL для рендеринга. Программа оперирует с большими объемами данных, поэтому важна скорость, высокоуровневые языки не подойдут. Посему хочется спросить, какая есть реальная альтернатива С++ для данной задачи. Язык меня конечно устраивает, многие подводные камни я уже изучил, но тем не менее - если есть лучше, то я открыт для этого

Собственно этого я и пытался добиться, но дискуссия ушла куда-то явно не туда. Согласно выкрикам отдельных товарищей лучше писать на чистом си, чем на си++ в котором негодный ООП. Ну а в качестве нормального ООП опять таки приводятся java и mono, что по потреблению памяти меня тоже не устраивает. Так что вывод следующий: продолжай писать на чём начал, тем более благодаря библиотеке Qt объём написанного кода резко сокращается при сохранении производетельности на должном уровне.

>а нафиг это вообще реализовывать? Кому оно мешает? Наиболее оптимальное решение - отключить

Сразу видно опытного гномера =)

В качестве замены С++ вырисовывается D. Пока его недостатком видится меньшее количество библиотек чем у С++. А язык очень и очень хороший.

А Vala?

а Vala -- не вырисовывается.

+1 за D -- жду-не дождусь, когда для D напишут аналогичную Qt платформу. Чтобы были в одном месте собраны GUI, XML, сеть, скриптинг. В D оно как-то более разбросано всё по отдельным библиотекам, как в С++ -- отдельно dwt, gtk, свои велосипеды (неплохие, но нет своего layout менеджера и в целом не дотягивают до того же Ultimate++, не то что Qt) . Хотя может быть, С++ и Qt пошли каким-то совсем не тем путём, и 100 Мб исходников -- это чересчур, и вместо одной толстой платформы надо делать несколько более модульных библиотек.

>Хотя может быть, С++ и Qt пошли каким-то совсем не тем путём, и 100 Мб исходников -- это чересчур, и вместо одной толстой платформы надо делать несколько более модульных библиотек.

Кстати, да. Это напрягает. Но там половину занимает справка, которая генерится из исходников. Непонятно, зачем тащить с собой то, что можно собрать на этапе сборки. А в остальном Qt вполне себе модульная библиотека. Проблема только в мантейнерах, которые частенько не удосуживаются разбить это дело на пакеты или прописывают иксы в зависимостях QtCore.

имхо высокое качество Qt обусловлено коммерческой с талантливой командой, плюс огромным испытательным полигоном имя которому КДЕ да и вообще весь опенсорс. с нуля тоже самое реализовать на D уйдут годы, и не известно кто этим решит начать заниматься. Было бы хорошо на начальном этапе реализовать биндинги Qt для D. Сам бы хотел этим занятся, но боюсь не хватит квалификации :)