Qt vs .NET

[Rcus]

Интересное получается сравнение, но все же хотелось бы упомянуть что разработка на C++/QT не ограничивает выбор разработчика исключительно библиотеками написанными на QT, для C++ написано огромное количество кода. А поскольку контейнеры QT совместимы с STL по интерфейсу и позволяют преобразование в обе стороны, то и с интеграцией не должно возникнуть проблем.

А еще хотелось бы послушать чем отладка в C# отличается от отладки в C++

[Detonator]

я бы добавил ещё пунктики про документацию и фидбек.

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

.нет рантайм у конечного юзверя отсутствует в 99% случаях - из личного опыта...

Неправда, с каждой версией windows XP SP2 ставится .NET 2.0, с каждой Vista .NET 3.0, рантаймы обновляются автоматически через Windows Update, так что вы скорее всего имеете в виду что его нет у 99% пользователей пиратской Windows XP потому что на пиратскую винду приходят только автообновления безопасности а не все подряд, или же автообновление у них отключено. В версии 3.5 SP1 добавили возможность при инсталлации автоматически скачать только необходимые библиотеки (около 20Мб) вместо полного пакета инсталяции .NET Framework 3.5 SP1 который около 200 Мб (т.к. включает в себя не только runtime но и SDK + все предыдыщие версии .NET 2.0, 3.0).

[Detonator]

Интересное получается сравнение, но все же хотелось бы упомянуть что разработка на C++/QT не ограничивает выбор разработчика исключительно библиотеками написанными на QT, для C++ написано огромное количество кода. А поскольку контейнеры QT совместимы с STL по интерфейсу и позволяют преобразование в обе стороны, то и с интеграцией не должно возникнуть проблем.

.NET меня тоже не ограничивала, т.к. .NET это не только C#, но и C++/CLI который в одном коде позволяет смешивать и обычный C++ и управляемый код.
(операторы * и new/delete для обычных объектов и ^ , gcnew и сборщик мустора для объектов из .NET)

А еще хотелось бы послушать чем отладка в C# отличается от отладки в C++

Это нужно пробовать, словами не объяснишь. Сборщик мусора и отказ от свободного использования указателей убирает большинство ошибок которые бывают в C++ коде. В самой Visual Studio в любой момент можно подвести курсор к переменной и увидеть все поля и свойства объекта в виде открывающегося списка, если свойства являются массивом или объектом - то можно открыть и их в виде дерева. Всегда можно на ходу вручную изменить неправильные данные и переставить точку выполнения назад чтобы заново пройти какой-то участок.
Кроме того даже стандартный IntelliSense для .NET работает на порядок лучше чем для C++. А аддон ReSharper для C# поднимает его еще выше, указывая цветом ошибки и несоответсвия параметров или типов мгновенно прямо в момент написания. Рядом с ним аддон VisualAssistX для C++ просто первобытный топор.
После привыкания к таким вещам использование той же паривычной Visual Studio но для отладки с++ кода просто шокирует беспомощностью. Я давно не писал на C++, уже успел привыкнуть к .NET и теперь приходится заново приспосабливаться.

[Rcus]

А C++ код вы, извините, голым gdb отлаживаете? Я не поклонник IDE(предпочитаю vim, чтение перед компиляцией, защитные методики и т.д.), но практически все что вы описали есть как минимум в Eclipse/CDT. (да, кроме обратного хода, его поддержки пока нет в самом gdb)

По поводу указателей и сборщика мусора: C++!=C, прямое управление памятью используется только в самых простых случаях, если нужно больше, то используют умные указатели и т.п.

[Detonator]

Rcus, я написал что в обеих случаях использую Visual Studio. Спорить об эффективности отладки с любителями покодить из командной строки не намерен - ни мне вас ни вам меня не понять.
Об Eclipse могу сказать что программил на ней пару недель на Java, обплевался пока не перешел на IDEA, вот уж действительно вещь. Кстати ее выпускает та же фирма что и аддон ReSharper о котором я писал выше.

[Admin]

ну а как у .NET с памятью? насколько жручи программки на ней?

PS: ставил дрова от ATI, у них инсталятор написан на .NET. Что-то долго и нудно ставил. Nvidia драйвера быстрее встают.

[ритт]

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

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

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

[ритт]

кстати, да - о производительности ни слова ещё не было.
как с производительностью у 3.5 сейчас?

год-два назад нам ставили систему управления на дотнете. смотреть на это было страшно - даже при небольших объёмах данных клиент с трудом шевелился на среднестатистической офисной машине. сервер в связке с мсскл выжирал 2-4Г оперативы и не мог поддерживать больше 12-15 одновременно подключенных клиента.
конечно, проблема может крыться и не в платформе, а в прямоте рук разработчиков, но они утверждали, что это шикарная производительность и лучше уже не будет...

[Tonal]

Ежели уж говорить про "вся Qt" то он не ограничивается только С++.
Я, например сижу на связке Python + Qt.
Скорость разработки на python-е в разы выше чем на C#, библиотек полно, переносимость гарантирована, интероп с С/С++ выбирай на вкус. :-)

Кроме того есть Qt Jambi поддерживаемый и развиваемый самими тролями.
А в войне java vs .net пока нет победителей.

Ну а насчёт высоконагруженных сетевых приложений - посмотри например ACE вроде как раз для него задачка.

Зачем пытаться решать все задачи исключительно на Qt, когда для этого есть много других удобных средств?

[constvipn]

Ежели уж говорить про "вся Qt" то он не ограничивается только С++.

Qt можно к C# (и к любому .Net языку, в том числе, к VB, IronPython, IronRuby, C++, J#) прикрутить: http://qyoto.org/. Пока, к сожалению, только на Линуксе. Авторы обещают мультиплатформенную поддержку в будущем.

[crossly]

звиняюсь за оффтоп...
к теме о генераторах отчетов.... http://www.kde-apps.org/content/show.php/eXaro?content=78869

[Detonator]

кстати, да - о производительности ни слова ещё не было.
как с производительностью у 3.5 сейчас?

Проблема с производительностью уже давно решена, собственно сама .NET на чисто вычислительных операциях может поспорить по скорости с нативными приложениями, т.к. пседокод компилируется при выполнении и при этом делает оптимизацию именно под текущий процессор учитывая и его разрядность, и к-во ядер, и размер кеша, и т.д. Для обычных приложений на C++ с оптимизацией под универсальный усредненный процессор это нереально если только кучу спецбилдов не делать.
С интерфейсом хуже. Windows Forms тормозной, т.к. тормоза в самой прорисовке GDI+ которую они используют.
WPF гораздо шустрее, особенно на двухядерных машинах. Но при больших объемах контролей в окне и он тормозит (да и Qt будет тормозить если в один Layout засунуть несколько тысяч виджетов), но это впрочем решается прямыми руками, просто нужно знать и поменьше использовать удобные но тормозные вещи типа шаблонов, автоматические привязки данных и т.д. а стараться задавать все напрямую. В целом WPF это большой шаг вперед в графическом интерфейсе. Смущает только что координаты в графике там не в пикселах а в логических юнитах (1/96 дюйма), что очень неудобно при работе с растровыми изображениями.

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

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

[ритт]

звиняюсь за оффтоп...
к теме о генераторах отчетов.... http://www.kde-apps.org/content/show.php/eXaro?content=78869

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

[ритт]

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

вполне реально
можно собрать ядро с чёткими указаниями типа процессора, макс-го кол-ва ядер и т.п....и получить прирост производительности для системы в целом. для обычного десктопа специальных билдов на софтину нужно ровно два: х86 и х86_64.

да и Qt будет тормозить если в один Layout засунуть несколько тысяч виджетов

теперь меня клинит и я просто не могу не спросить
что это за приложение с несколькими тысячами виджетов в компоновщике и зачем оно такое нужно? )

[Detonator]

теперь меня клинит и я просто не могу не спросить
что это за приложение с несколькими тысячами виджетов в компоновщике и зачем оно такое нужно? )

В WPF так реализовано древовидное отображение TreeView, он создает отдельный элемент для каждой строчки корневого списка, включая и те которые не видны из за скроллинга, и помещает их в один вертикальный lаyout - плата за то что каждый элемент в дереве может быть любого размера и полная свобода в его содержимом. Соответсвенно когда один из элементов раскрывается, это элемент строчки увеличивается по высоте и компановщик заново пересчитывает _все_ элементы, что соответсвенно тормозит при большом количестве.

Для простых TableView и ListView для скорости используется виртуализация, а в TreeView нет (надеюсь что только пока)
Когда мне пришлось сделать на WPF отображение базы данных неких элементов в виде дерева (окололо 7000 корневых элементов, у каждого от 1 до 10 подэлементов) то по сути пришлось писать свой элемент управления для отображения дерева, зато он получился очень быстрым.
Вот кстати скриншот последней эксперементальной версии моей программы на WPF/.NET, теперь пытатаюсь сделать то же смое на Qt
http://mwsmobile.com/other/vptscreen2.png