Russian Qt Forum

Уже неоднократно кутэшники упрекали .НЕТ в тормознутости, потому что код на виртуальной машине исполняется.
Но хотелось бы большей объективности!
Была на РСДН статейка "Кто сегодня самый шустрый". Хоть она и старая, то исходники прилагаются и всегда можно получить обновлённый результат.
(ссылка на статью http://www.rsdn.ru/article/devtools/perftest.xml)

C# там показал неплохие результаты в сравнении с C++.
Может кто-то из qt-шников уже портировал примеры в свой любимый фреймворк? Если нет, то давайте сделаем это!
Например меня Qt, несмотря на все свои преимущества, отталкивает излишним геморроем (может быть это только на первый взгляд выглядит гемором...): начиная с установки и заканчивая распространением программ.

Пусть будет ещё аргумент в пользу Qt. Тут ещё дело в том, что смотря примеры в Qt и пробуя сделать свои первые шаги в нём  a-la Hello world, особо высокой производительности я не заметил.


п.с. Только не надо развивать holy war и отклоняться от темы в сторону Borland или MFC (ну, и прочего стаффа). Только Qt и Net. Только производительность.

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

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

а Вы вообще дату этой статьи смотрели?
Там в комментах - 2001 г.
Уже не раз все изменилось. и Qt 4.2.2(3) на дворе.
И там битва компиляторов. А Qt - это библиотека. На чем скомпилите - так и работать будет.

Да смотрели мы дату статьи не раз!
Изменилось всё не раз, но примеры-то остались. Под NET 2.0 особо переделывать ничего не нужно. Под Qt всё равно никто не портировал этот тест.

"И там битва компиляторов. На чем скомпилите - так и работать будет."
Не надо заводить разговор на посторонние темы. Компилятор-шмампилятор... Возьмите любимый компилятор и им компильте.

"А Qt - это библиотека."
Так NET Framework и C# тоже не компиляторы.


Попробуй сам сделать, раз кутешники бояться...

Данная статья сравникает компиляторы, а не языки. Ну да ладно...

Насчёт статьи.... С чего ты взял, что в данной татье копилятор С# превзошёл комиляторы С++??? В 6 тестах из 9 Компиляторы С++ (VS и\или Intel) обошли С#! К томуже, в некоторых тестах (например в первом) убрана оптимизация.

Советую прочитать http://www.rsdn.ru/article/devtools/perftest3.xml. Это статья будут посвежее первой.

ЗЫ: В чём спор? В том что NET Framework шустрее Qt?

"С чего ты взял, что в данной татье копилятор С# превзошёл комиляторы С++???"
pastor, а где я говорил, что превзошёл?

"В чём спор? В том что NET Framework шустрее Qt?"
В том-то и дело, что не известно! Тебя доказать просят, а не голословничать!

Я сделал вывод с этой фразы: "C# там показал неплохие результаты в сравнении с C++." Сорри, ошибся

Mr. Пронька
Я тоже задавался таким вопросам. Судя по тестам нифига особого преимущества нет, а ведь это были старые тесты, с тех пор над C# наверняка много работали. Так что все чаще закрадывается сомнение по поводу вкто же лучше.

evilguard, я тебе могу сказать точно, что результаты тестов и сейчас действительны (сам проверял). Но второй .NET оказывается немного медленнее первого.

Как минимум все эти тесты не учитываю время запуска и JIT компиляции во время работы...
Попробуйте в жабе пооткрывать JOptionPane... сразу видно тормоза... :)
За с++ не стоят корпорации :)...
А за java и .net понятно кто и сколько вливают...
WebSphere от IBM Enterprise доходит (вроде видел в инете) до 40 000$ на процессор...
прикинь какие бабки? и какое нужно железо...
Если они будут быстро пахать никто не будет покупать новое железо...
и само главное  не путайте рынок энтерпрайз где комп расчитан на запуск 1й программы, и десктоп!
Qt предназначена для декстопа!
Я допустим комп мощнее покупаю не для того чтобы индусские (которые не асилили :) работу с указателями) поделки быстрее пахали, а чтобы выжать из компа всё...

добавлено спустя 2 минуты:

 

на вот тут ссылки от перцев из яндекса, проскакиваю там и тесты в комментах...
http://users.livejournal.com/_denplusplus_/79638.html

Sergey B, это всё хорошо, но зачем тут Java? Просил же не отклоняться от темы.

Если уж по тестам java не сильно медленнее c++, то чего говорить о c#?
Эх, если бы я знал хоть немного c#, провел бы небольшой тест :)

Я привёл пример с java, C# такая же херня...

Sergey B, с чего ты взял, что Java и C# - одно и то же?

evilguard, я его знаю. Давай, ты на Qt сделаешь, а я аналогичное на C# попробую. Будет что сравнить.

это не одно и тоже...
просто скорости у них сопоставимы...

И кажется кто то хочет где-то пофлеймить  :wink: , а пример накатать не может... :)

"просто скорости у них сопоставимы..."
Проверял?

Флейм в стиле ЛОР'а :) присоединяюсь :)
Зачем сравнивать хуй с пальцем? Тем более по скорости :) Qt - удобный кроссплатформенный тулкит с отличной документацией, в отличии от .NET, по всем пунктам. Если на каких-то задачах .NET и быстрее это не покрывает указанных преимуществ.

Sergeich, а если мне кроссплатформенность не нужна?

п.с. Удивительно! Ни одного толкового ответа по существу. Сплошные увиливания и флейм.

В принципе с C++ и QT перейти на C# и WindowsForms не думаю, что будет шибко сложно :) Если будет необходимость, конечно. Но QT знать не помешает.

"Но QT знать не помешает"
До 5 утра познавал :) Пока ниасилил. Ща опять сырцы компилю.

Вообще-то в мире свободы существует одно простое правило: "Кому надо, тот и делает".

f_evgeny, в мире взаимоподдержки все друг другу помогают.

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

ИМХО

ЗЫ: для сравнения производительности, бери любое демо (QTDIR\demos), портируй на .NET Framework и сравнивай. Не забудь тока результатами поделиться ;)

.Net 2.0 - это зверь!!! Простая форма 20Mb памяти отжирает!!! Кстати, есть один маленький нюанс. Сколько бы мелкософт свои библиотеки не расхваливал, сам он почему-то проги на них не пишет (то, что в Office 2003, 2007 есть тузла для интерграции не в счет, это просто надстройка)!!! Единственное полностью .Net приложение от мелкософта - это примеры от библиотеки (если не прав дайте ссылку).

добавлено спустя 4 минуты:

 

Вот в этом ты прав, на .Net здесь большинству явно по х... по барабану.

Оказывается про Qt даже у самого Microsoft'а спросить можно:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=214100

Все правильно. Он в память закидывает все фреймворк. а еще классная ситуевина ощущается. Одна приклада написана под .нет 1.1 и при запуске тащит в память свой фреймворк, вторая - под .нет 2.0 и тоже тащит свое за собой. А супер новая прога - под .нет 3.0 и его туда же - в память. И все это на офисном компе с 256 метрами мозгов. Поэтому MSWord .NET будем ждать долго. все мое ИМХО

Второй обеденный перерыв - не так уж плохо, главное чтобы на винте пару 10-20 гигов под файл подкадчки было!!!

На работе приходиться поддерживать прогу на .нете писаную для работы с БД. так клиенты жалуются на очень медленную отрисовку контролов. а если через терминал работают - вообще тормозилово.

Раньше писал на MFC. Там тоже отрисовка страшно тормозила. Видимо у MS - это врожденный дефект.

Сама сборка из исходников - один большой геморрой.


Вот ведь удивительно! Не помню ни одного костыля, поставленного в своей работе.
Такое ощущение, что с NET ты не работал или же видел одним глазком и брезгуешь только из-за слова M$.


Брал. Не впечатлили.


Разворачивай Qt-шную форму на весь экран и получай сопоставимый результат. Я про это спрашивал на форуме с месяц назад, но так никто и не ответил, с чем это связано.


Ребят, вы не думайте, что я тут отстаивать NET собираюсь :) Мне и самому Qt нравится, но только дайте нормальные средства разработки, чтобы получать удовольствие от кодинга, а не ковыряния в настройках и разгадывании загадок среды разработки. В VS 200x я с Qt работать не хочу. Про другие почитал: все тащаться от того, как они разруливали проблемы сред и с 15-го раза собирали примочки к ним.

Far + MinGW - никаких проблем! :)

Вудруф, где можно посмотреть на твой проект, написанный в этой "среде"?

Вот не хотел ввязываться во флейм ... и не буду  8) , однако пару ссылок дам  :D . Как вы думаете что является основой GUI библиотеки ... что для нее самое важное ... в смысле скорости. Праааааавильно, система отрисовки (рендеринга). Представленные далее ссылки не покажут непосредственного сравнения рендринга Qt vs .NET, в первой происходит сравнение между Qt и Cairo (от весьма уважаемого человека - Zack Rusin, одного из разработчиков графической подсистемы Qt) -> hhttp://ttp://zrusin.blogspot.com/2006/10/benchmarks.html , а вторая сравнивает CDraw (от Xara), GDI+ (найтивная система рендеринга виндов) и Cairo -> http://www.xaraxtreme.org/about/performance.html, однако из этих статей путем не хитрых математических расчетов и некоторых не сложных допущений можно извлечь весьма занимательные факты и информацию для размышления.  8)

SLiDER, тормознутость GDI+ меня самого в шок вводит :(

А ещё... кто знает, как сделать, чтобы docking в Qt пошустрее был? А то вроде и красиво, то как-то медленно.

добавлено спустя 5 минут:

 Ещё вопрос есть. В примерах на рисование есть возможность выставлять рендеринг OpenGL (кроме тех, которые именно по OGL). При этом программа грузит сильнее, чем при обычной отрисовке. Это с чем связано? Может в таком случае OGL софтварно обрабатывается, на на OGL-примерах аппаратно?

Mr. Пронька
Такс, а почему с VS Работать не хочешь? Можно подробнее? Я вот тащусь допустим:) VS+интегратор рулят, как будто QT это родной компонент Студии. Да и minGW вроде как далеко не самый быстрый компайлер для c++, по сравнению с интеловским и мелкомягких.

evilguard, а как там сделать, чтобы в отладчике можно было смотреть значения переменных? У меня только их адреса отображаются.

добавлено спустя 55 секунд:

 По сравнению с отладкой "родных" проектов это просто-таки suxx!

Mr. Пронька
Не понял тебя, ты про что? Значения переменных нормально показываются в студии, отладчик клевый и удобный. Что не нравится-то?

evilguard, слушай, а вот у меня есть два вроде как интегратора:
qt-vsintegration-1.2.1
qt-vsaddin-collection-2.1.4

Первый, понятно, интегратор и есть. А со вторым чего делать?

добавлено спустя 4 минуты:

 Последний вопрос отменяется. Новый возникает.

Поставил, попробовал. Тоже интегратор. Но какой из них лучше? Кто побольше, чем пол часа использовал, подскажите.

...ходил в отдел к программистам - задал вопрос какие они знают продукты( Microsoft'а, а не свои),  написанные на C#/Net... долго думал...

fanat9, жжошь!

Про мелкософт не знаю, а, например, тот же SoundForge 8 уже без фреймфорка жить не может.

Mr. Пронька,

Я перепробовал много (несколько) IDE для Qt.
В итоге остановился именно на Visual Studio + Visual AssistX + QTVSIntegration. Самая удобная среда.

Но это может быть потому, что я не знаю хорошо такие можщные и гибкие вещи, как vim. Потому что нет времени изучать, да и VS удовлетворяет.

Среди простых сред - QDevelop (+gcc) хорошая (win/mac/linux) . Есть еще SlickEdit и много других.

Можно еще юзать среду Eclipse+CDT. Но тормозов больше.

Любой редактор/среда + MiniGW (gcc) — этот вариант мне не прокатил, потому что нету 64-битного GNU дебаггера.

[q]Сама сборка из исходников - один большой геморрой.[/q]

Никакой не геморрой. Наоборот позволяет собрать именно в том конфиге, кот. тебе нужен. Не ленись, а разберись. Благо, только один раз это надо сделать.

Ладно, хватит оффтопика.

Чтобы говорить о Qt vs. .Net надо определить задачу или круг задач. А сравнивать вобщем — это совсем некорректно.

"надо определить задачу или круг задач"
В самом начале уже были определены ;)

Ещё вспомнил, чем меня VS не устроила. Нужно тащить ещё и её файлы при распространении программы, а это уже совсем не круто.

Вчера попробовал Code::Blocks. Довольно не плохо. Можно и компилеры разные испльзовать. Только запнулся, когда mingw затребовал QtAssist и не нашёл его, хотя папки для линкера выставил какие надо.

QDevelop действительно сыроват.

"Наоборот позволяет собрать именно в том конфиге, кот. тебе нужен"
А понадобится что-то ещё - вперёд перекомпилировать.
Да и как ты можешь говорить, что я ленюсь, когда уже раз 10 пытался собрать. Через 20-30 минут какой-то косяк высплывает обязательно.

Какие еще файлы???



Можно иметь разные (по конфигу) собранные версии в разных папках.

Ну, вот видишь. Значит не один раз ;)


Сейчас по форуму поищу. У тебя разве просто так на другом компе программа запускается? Мне не удавалось пускать её там, где ещё и VS не стоит.

добавлено спустя 3 минуты:

 Вот про эту тему говорю. Да и сам как раз с этим столкнулся.

http://prog.org.ru/forum/topic_3014_0.html

добавлено спустя 5 минут:

 В общем, это совсем не true-стиль, а те самые костыли!

Уже прогресс - что вспомнил!!

Оху***ть, вот это я понимаю-- мнение квалифицированного специалиста!
А Qt когда попробывал? за два дня до Code::Blocks??

Краткое резюме:
1. Предлагаю прилепить тему "Для новичков".
2. Пора ввести систему банов за пустой треп.

P.S: Пословица: "Купи петуха, отруби ему голову и тра**й мозги ему, а не нам."

Предже чем рассуждать о пустом трёпе, лучше бы доделали толковый FAQ, где хотя бы был описан досконально процесс установки/сбоки со всеми нюансами.
Глядишь, и не было бы свыше 2000 тем в разделе QT.

Mr. Пронька
Я в Windows работаю очень редко, но мне не составило труда за 10 минут разобраться, как устанавливать Mingw+Qt_win32... В интернете куча документации, достаточно спросить у гугля.

Mr. Пронька

Вместо требования ко всем: А скажите что у меня не получается
лучше бы почитать файл INSTALL. Там все очень доходчиво описано.
Единственное что еще надо добавить, так это переменную среды QTDIR.
QTDIT=c:/qt
если каталог  QT - c:/qt. Если каталог отличается измени соответственно.

Mikhail, усё по инструкции сделано.
Ладно, можно, пожалуй, тему закрывать.

я создавал аналогичный топик пару месяцев назад, хорошие люди все объяснили. посмотри сюда что лле:
http://prog.org.ru/forum/lhtopic_4049_0_0_asc_.html
http://prog.org.ru/forum/lhtopic_3656_0_0_asc_.html
http://prog.org.ru/forum/ltopic_4059_0_asc_0.html

Mr. Пронька,



Мне-то как раз одной конфигурации достаточно. И подавляющему большинству, думаю, тоже.

Другое дело, что у меня в двух разных папках 2 собранные Qt - одна x86, другая x64.



Наверное там дело в динамической линковке.



Никаких проблем нету вообще.

А можно поинтересоваться, чем именно тебе они не подошли? Чем конкретно они тебя не впечатлили? Экзамплы от дяди Билли на .НЕТе круче? Или как?

добавлено спустя 21 минуту:

 

Выполнить confgiure с нужными тебе параметрами и запустить nmake (или mingw32-make) это сложно??? Для этого не нужно быть супер программером или каким-нить кулхацкером. Проще не бывает, имхо.

Прежде чем подымать ор "у меня не получаеться и это гимор", нужно было выполнить поиск по форуму. На форуме дохрена тем по сборке Qt, как под мастдай так и под линукс.

ЗЫ: Нужно обладать хоть малейшим терпением и иметь хоть малеёшее желание сделать это!

Вот он флеймер всё и рассказал...
Qt собирается волшебной коммандой...

:)
Если собираешь MingW
нужно путь прописать в переменную PATH, чтобы нашёлся mingw-make32 :)...
Если VS то запусти её комманд промт (в меню Пуск будет, в папке с ярлыками от VS), перейди в каталог с Qt и ту же волшебную комманду...



Если не можешь её хотя бы собрать или ещё хуже, не  понимаешь работу указателей пиши на .NET  и не отвлекай нас...
:)

Про память, я сейчас пишу проект, классы QTableView, QItemSelectionModel, QSqlQueryModel активнейше юзаются, однако форма полноэкранная с отображаемыми данными - отжирает порядка 13 метров, если открыть диалог с параметрами выбранной записи - 15...
Что я делаю не так? :(

Т.к. я имею некторый опыт программирования на .NET и недавно начал использовать Qt могу сделать небольшое сравнение. Предлагаю обсудить кому интересно.

.NET:
+ Язык C# в разы эффективней в разработке и в отладке чем C++, имеет Visual Studio заточенный именно под нее.
+ WPF в .NET 3.0  достаточно быстр, очень удобен и напоминает Widgets/GraphicWidgets в Qt4
+ Высокоуровневая система WCF для сетевого взаимодействия приложений
- требуется очень большой по размеру предустановленный runtime, но в большинетве случаев он уже стоит на Windows у всех
- сама .NET не мультиплатформна, многоплатформная реализация Mono не поддерживает WPF.
- очень тяжело расширяются стандартные классы .NET, если нужно нестандартный компонент приходится писать почти с нуля

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

Итого, при разработки только под Windows я считаю что .NET предочтительнее как для одиночек так и для больших проектов/компаний, т.к. разработка на нем позволяет сэкономить время и деньги.
Qt я начал использовать исключительно ради портируемости приложения на Win/Linux/MacOSX, хотя уже вижу некоторые серьезные проблемы которые отсутствуют в Qt и которые придется реализовывать с нуля самостоятельно.

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

Не вижу ничего смешного в этой фразе. или вы все программы пишете с нуля? Я просто переношу программу с WIndows и меня очень огорчило что некоторых вещей в Qt нет, напрмер асинхронных операций через connection port, которые есть в Windows API, активно и прозрачно используются в .NET, но неизвестно есть ли вообще их аналог в линуксе (с системным программированием под линуксом/макос я пока не знаком совершенно).

Эммм, Вы все таки прочитайте свою фразу внимательнее, и если вы серьезно собираетесь отсутствующие в Qt проблемы реализовывать самостоятельно, то кто вы если не комсомолец из не безызвестного анекдота :)

Не придирайтесь к словам, имелось в виду "уже вижу проблемы в реализации некторых вещей отсутствующих в готовом виде в Qt". Хотя возможно что некоторые изменения которые я планирую в Qt и и приведут к некоторым пока неизвестным проблемам. Например хочу сделать у скриптового движка систему транзакций, к примеру если выполнение какой-то функции привело к ошибке то чтобы можно было вернуть полное состояние всех объектов на последнее стабильное состояние скрипта, а так же сохранить/загрузить это состояние и redo/undo. Для .NET у меня такое было реализовано, для QtScript по предварительным исследованиям тоже возможно.

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

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

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

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

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


Неправда, с каждой версией 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).

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Ну а насчёт высоконагруженных сетевых приложений - посмотри например ACE (http://www.cs.wustl.edu/~schmidt/ACE-overview.html) вроде как раз для него задачка.

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

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

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

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


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

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

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


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

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

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

Насчёт проблем с производительностью не всё так радужно...
Как раз недавно на rsdn-е большой флейм (http://gzip.rsdn.ru/forum/message/3047193.aspx) был.
Основная  идея что JIT-у действительно доступна информация о выполнении не доступная статическим оптимизаторам.
Но, у него гораздо меньше времени, и памяти для маневра.
Поэтому даже лучшие сегодняшние JIT-ы серьёзно проигрывают статическим оптимизаторам.
Простейший пример: сложный цикл долгих вычислений результаты которого не используются - статические оптимизаторы выбрасывают весь цикл, а JIT-ы честно его оптимизируют. :)

Так что ежели действительно делается система с тяжёлыми вычислениями, в которых играет рояль оптимизация под конкретное железо, сегодня выгоднее поставить систему в исходниках или собрать поз конкретное железо, чем полагаться на JIT.

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

Ну дык, вывеописанные вами проблемы это проблемы ИДЕ - Visual Studio. Причем тут С++? ТО что M$ забили на С++ часть Visual Studio никак неделает С++ хуже. Извените, но мне кажеться у вас мало опыта в С++, в том числе и в отладке.
По поводу сборщика мусора: он ненужен. В Qt прекрасно работает child\parent.

Да, в отладке на C++ без IDE у меня опыта нет вообще, даже во времена Dos уже были нормальные IDE для C/C++. Так что извиняйте, могу сравнивать .NET с Qt только в связке .NET/C#/VisualStudio vs  Qt/C++/VisualStudio. Если вы знаете более удобное средство для отладки под Windows, напишите.

Если скорость действительно важна, то оптимизировать будут вручную. А в общем случае скорость вряд ли будет сильно отличаться. Т.е. ни о каких страшилках вроде в разы более тормозных программах на .net речи нет уже давно, это было еще во времена .NET 1.0
Если пренебречь разницей в скорости между нативным и управляемым приложением сделать второе гораздо дешевле и быстрее.

У меня есть знакомая машинка: ноут Asus проц AMD Sempron 3100+ 1.8ггц и озу 736мб.
Вполне средненькая машинёшка 3-5 летней давности.
Так вот, запускать на ней что то .Net-овское или Java-вское - вешалки и тормоза.
Так что страшилки конечно забудутся, то ещё лет через 5, когда это будет раритет. :)

А по скорости разработки - в принципе согласен, но опять же сейчас есть более другие языки, для которых скорость разработки ещё выше. :)

Так что единственное, на мой взгляд, реальное преимущество платформы .Net - это количество низко и средне квалифицированных разработчиков.
Тут MS на высоте, и догнать по этому показателю её очень трудно. :)

Это слышно с выходом каждой новой версии Net или Java, а воз и ныне там.

Ну сказки все это, или программа у тебя была такая.
У меня специально для тестирования стоит комп Celeron 1.2GHz / 1Gb Ram / Windows XP / Visual Studio 2008 / .NET 3.5
Так я на нем тестирую и оптимизирую свои приложения на .NET, конечно после того как я переношу его туда со своего основного рабочего компа тормоза заметные, но несколько часов с профайлером делают с ним чудо. Обычно 80% всего времени работы программы укладывается в десяток функций которые нужно подправить для оптимизации. Например замена свойства в особо узком месте на простое публичое поле или списка/итератора на обычный массив делают это место быстрее в разы.

Я все это про WPF имею в виду, с Windows Forms ситуация другая, там тормозит отрисовка самих контролей и форм.

Никто Вас не заставляет писать на Qt. Пишите на .NET.  ;D
Нам доказывать ничего не надо, или Вы хотите что-то доказать самому себе?

Не хочешь обсуждать не пиши, может другим интересно. Ведь как я понимаю тут мало у кого вообще есть опыт с .NET, потому и попвтался их сравнить. Если бы я промолчал вам стало бы заметно лучше?
Я выбрал Qt только из-за многоплатформности. А С++ или C# мне в принципе пофиг на чем писать, важен результат.

Пытаются сравнивать приводя замеры тестов. а не субъективные ощущения, пока что я вижу пустопоржний флейм, основанный на впечатлениях.
Беда всех программ, работающих в "песочнице" - медленный GUI. Поэтому для толстых приложений выбирают С++.

P.S.
На ты, вас называть я себе не позволял.

Ну давай пообсуждаем :)
Для начала пожалуйста сюда пару ссылок на софт, написанный на .Net, что-бы оценить его производительность.
На счет распространения фраймверка, это точно, что у 99% процентов его нет на компах. По личному опыту...
Ты тут привел одногигагерцевый комп с одним гигабайтом памяти. Сам то как думаешь, не жирно для тестирования памяти гиг?

По Qt могу добавить, что просматривая сайт тролей я обратил внимание на то, кто использует Qt в своих разработках (только из известных мне фирм/брендов):
 Epson; AMD; Google; Фольксваген, Вольво, Ксерокс, Филипс, Сони, Сименс, Адобе, Motorola, Panasonic, Sharp и т.п.
Это из известных мне...
Даже Уолт Дисней затесался :) Не говоря уже про KDE и саму Нокию...
Может ты им мозги попаришь и предложишь .Net?

эммм...
panAlexey, не стоит грубить. мы же здесь не фашистов бъём :)

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

зы. к теме про производительность при отрисовке графики - http://www.prog.org.ru/index.php?topic=7280.msg39679#msg39679

сори, похмелье... злюся :(

Я в программировании любитель, т.е. самоучка и попрофилю не работаю, пишу для себя. Путь прошел такой
Dephi, pascal, Builder, c++ (консоль), WinApi/MFC (трашно даже вспоминать), .NET (только познакомился), уже больше года Qt.
Так вот .NET хотел в свое время заняться, но... За неделю я так нихрена и не понял, для меня было очень тяжело смотреть на код c# после c++. А вот кутю я понял через несколько дней знакомства. Потом было много грабель, но тут хорошо помогали. Сейчас я свой уровень оцениваю не ниже среднего.
К чему я это все написал? Просто есть понятия: скорость разработки, скорость выполнения,... Но и не на последнем месте, ИМХО, скорость изучения.
Не ради оффтопа, мне кажется, что интерпретирование в виртуальной машине (или как это называется) никогда не сможет быть быстрее нормально проги на c++ или паскале. Хотя это ИМХО, так что камнями сильно не кидайте. :)

> На счет распространения фраймверка, это точно, что у 99% процентов его нет на компах. По личному опыту...

По личному опыту могу сказать что на 99% компов нет ни MacOS ни Linux'а
Потому что статистика посещений на моем сайте это подтверждает, за этот год 1.3% Linux, 0.8% MacOS
Статистики по фреймворку я не собираю, но в инетренете можно найти:
51% have .NET 2.0 and only 13% have .NET 3.0 - т.е далеко от вашей цифры в 99% не имеют

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

Не, не сказки.
Как раз VS 2008 и тормозит. :)
Все управляемые среды очень критичны к недостатку памяти.
На той машинке сначало было 512мб. - совсем бесполезно было что-то такое запускать.
При 736мб оно в принципе шевелиться, но туго...
Думаю, если догнать до 1гб - будет вполне приемлемо.
На нативных приложениях подобного падения обычно не наблюдается.

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

Ужжос! Чем же занимается JIT?
На С++ переход с вектора + итератор на массив + указатель вообще смысла не имеет, т.к. с оптимизацией компилятор выдаст просто идентичный код для обоих случаев.
Ну а насчёт полей - если есть места где реально тормозят геттеры имеет смысл подумать над тем, чтобы внести всё это место в класс отдельным методом.

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

Угу, это типа:
"В интернете было произведено исследование о том кто пользуется интернетом.
оказалось что пользуются интернетом 100% интернет-пользователей" О_о.

>> Т.е. время выигранное на скорость разработки тратится на оптимизацию.

Это занимает полдня-день раз в месяц-два.

>> На той машинке сначало было 512мб. - совсем бесполезно было что-то такое запускать.

Под студией для отладки - 1 гиг минимум, без студии под WInXP нормально будет и 512.

>> Ужжос! Чем же занимается JIT?

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


>> В интернете было произведено исследование о том кто пользуется интернетом.
>> оказалось что пользуются интернетом 100% интернет-пользователей" О_о.

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

+своп-файл в гиг-два :)

7 страниц ниочем )))


2 Detonator: Так в чем всеже преимущество .Net перед Qt (без привязки к IDE, компилятору, отладчику, etc)? Личные ощущения невсчет )))

О_о. А нафига собственно в программе функции антивируса?
Ие.... написал вьювер-редактор для SQLite-бд, получил 90% оверхеда....

>> Личные ощущения невсчет

Что тогда спрашивать?

>> О_о. А нафига собственно в программе функции антивируса?

У майкрсофта спроси, это важная часть .NET.

Имеется ввиду другое, компиляторы в нативный код делают лишь базовую проверку доступа к полям, но зная структуру класса и настройки упаковки полей можно получить доступ к private/protected полям экземпляра класса, если есть указатель на него.
С другой стороны существуют методики позволяющие предотвратить данный поворот событий (например использование handle'ов вместо указателей как сделано в Win32API)

венде это не помогло :)

Меня интересует объективный анализ достоинств\недостатков. То что вам нравиться NET и поетому он лучше - это не показатель того, что Qt хуже. Если бы вы расписали бы, например, так:

1) В NETе лучше сетевой модуль, чем в Qt, тем что...
2) В NETе лучше xml модуль, чем в Qt, тем что...
3) В NETе лучше модуль по работе сБД, чем в Qt, тем что...

ТО что вы рассказывали выше, касаеться торлько IDE, Qt тут уж непричем. Вы выплеснули личные имоции и восхищения NETом. Анализа и сравнения - 0. Ничего личного...

>> 1) В NETе лучше сетевой модуль, чем в Qt, тем что...

С этим в Qt еще особо не разбирался, но насколько понял в нем и нет какого-то там сетевой модуля, только простейшие сокеты и http/ftp
Они и в .NET есть почти такие же. Ничего подобного WCF в Qt нет, но и не всем оно нужно.

>> 2) В NETе лучше xml модуль, чем в Qt, тем что...

Одинаковы.

>> 3) В NETе лучше модуль по работе сБД, чем в Qt, тем что...

С базами данных стараюсь не связываться вообще, личное неприятие.

а что вы подразумеваете под сетевым модулем?
к тому же кьютишный сетевой модуль насчитывает 21 класс


не такой он уж и убогий.

Предлагаю закончить этот флейм. О каком сравнении может идти речь если Qtшникки невладеют NET, NETовцы невладеют Qt?

закрывай, мне тоже надоело.

ясное дело->close();
Рекламы и восторгов я и по телеку насмотрюсь...
http://www.rsdn.ru/res/book/net/nagel3.0.xml
Чесно говоря мне этот .Net напоминает попытку мелкософта убежать от собственноручно разведенного невообразимого зоопарка и бардака в своих инструментах..
Смотреть там же, начиная с "Для чего подходит C#".

Неужели есть критичная разница по скорости что проверять на безопасность свойство или поле?
И мне казалось что JIT должен работать уже после всех проверок по безопасности.
Иначе он будет может сработать впустую - оптимизировать код, который не имеет права на выполнение. :)

Про сравнение функциональности:
XML .Net-а всего лишь обёртка к MS XML (http://msdn.microsoft.com/en-us/library/ms763742(VS.85).aspx) если я не ошибаюсь.
А MS XML - одна из самых продвинутых библиотек работы с XML - например с её обработчиком xslt я игрался ещё примерно лет 7-8 назад.
А в Qt xslt  только обещают.

Базы данных:
ADO.Net (http://en.wikipedia.org/wiki/ADO.NET) - развитие идей MS ADO.
Работа ведётся с Dataset который хранит в себе множество выборок и их связей.
Прозрачное сохранение/восстановление в/их xml,
После загрузки из базы может быть "отсоединён", передан по сети, изменён/дополнен, передан обратно и синхронизирован с базой. :)
При этом удалённая программа доже не знает о том, что работает не напрямую с сервером.

Ну и вообще, из .Net доступны и имеют свои обёртки все основные подсистемы винды.
Например .Net встроен в MS SQL, и можно писать сохранёнки и триггера на любом из его языков используя все доступные в .Net сервисы.

Короче, если не нужна кросплатформа и железо б.м. новое - то .Net довольно привлекательный выбор.

> Неужели есть критичная разница по скорости что проверять на безопасность свойство или поле?
> И мне казалось что JIT должен работать уже после всех проверок по безопасности.

public поле это просто public, а public свойство это уже private метод, т.е. дополнительная проверка а имеет ли вызывающий код доступ к этому private.
При пересечении стеком вызова границ сборок происходит еще одна проверка,  напрмер используя в программе в цикле список List реализованный в основной библиотеке Framework'а будет постоянная проверка при каждом обращении к его методам, если предварительно скопировать все во временный массив, то проверок в цикле можно избежать.
Ктому же JIT к этому отношение не имеет, т.к. компилит в каждый момент только одну функцию не зная ничего о других. Ведь FIle.Open() может вызывать как код из интернета которому это запрещено, так и опосредством IsolatedStorage, через который это разрешено.

> XML .Net-а всего лишь обёртка к MS XML если я не ошибаюсь.

в .Net она полностью заново написана на C# и стала даже еще быстрее чем MS XML, быстрее я пока не встречал
Впрочем в Qt тоже появился аналогчиный нетовскому QXmlStreamReader

В С++ проверки public и private доступов имеют место только на этапе компиляции.
На этапе выполнения никаких дополнительных проверок не происходит.
Ты уверен, что спецификаторы доступа как-то влияют на время выполнения?
Т.е. вызов public метода отличается от вызова private по скорости?
Или доступ к private полям из метода класса от доступа к public полям?

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

Пусть я что-то загрузил извне, проверил его доступы/разрешения.
Они что, могут поменяться после подгрузки динамически?
Какой смысл в таких постоянных проверках?

Ещё раз приведу ссылку на флейм: http://gzip.rsdn.ru/forum/message/3047193.aspx
Вроде защитники JIT-а утверждали что он может инлайнить и потом оптимизировать через границы сборок.
Врут?

Ну, это можно реализовать опять же глобальным для потока уровнем доступа.
Когда поток выполнения пересекает границы сборки меняется глобальный уровень доступа.
Который и проверяется в FIle.Open().
Т.е. опять же на скорость выполнения это не сильно влияет - проверки производятся в любом случае.
И уж всяко такие проверки гораздо быстрее чем сами операции с файлами. :)

Дествительно: http://support.microsoft.com/kb/815112
Вот: http://www.sql.ru/docs/AccessingData/index.shtml довольно интересная обзорная статья о базах и XML в .NET-е.
И QXmlStreamReader и .NET-овский XmlTextReader используют наиболее быструю на сегодня pull модель.
Но XmlTextReader - валидирующий а QXmlStreamReader нет. Т.е. если у тебя есть схема или DTD-шка для загружаемого XML-я, то XmlTextReader сообщит об её нарушении, а для QXmlStreamReader такую проверку нужно организовывать самостоятельно. :(

> Ты уверен, что спецификаторы доступа как-то влияют на время выполнения?

Я не знаю насколько именно влияют, но то что проверки идут в рантайме это точно. Ведь на .NET используются и языки которые не проверяют типы/моификаторы доступа, да и хитрый IL-асемблерный код сгенерить на лету всегда можно - так вот вызов таким способом извне приватного метода объекта выдаст Exception. Этим он и отличается от C++, Delphi и прочих обычных языков где код имеет доступ куда только пожелает.

> А если ты таки имеешь в виду, что доступ к полю это просто чтение памяти а доступ к свойству - вызов метода, то как бы, подобные тривиальные методы
> доступа инлайнить умели даже престарелые Delphi ещё до появления .Net.

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

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

Я не знаю почему проектировщики .NET выбрали другой метод проверок доступа, наверняка были причины.

> Пусть я что-то загрузил извне, проверил его доступы/разрешения.
> Они что, могут поменяться после подгрузки динамически?

Как ты можешь это проверить в момент загрузки? Как ты можешь быть уверен что код не поменяется по ходу выполнения, ведь код может подгружать новый код, даже на лету в памяти компилить и выполнять C# код можно, не гворя уже о простой прямой генерации нового IL кода.

> Вроде защитники JIT-а утверждали что он может инлайнить и потом оптимизировать через границы сборок.
> Врут?

Между границ обычных сборок да, но когда какая-то сборка устанавливается в GAC (как например самая основная сборка mscorlib), она системой обрабатываются ngen'ом для ускорения их выполнения, при этом они компилятся в нормальный нативный код и сохраняются в кеше. Код такой сборки уже не может быть так просто заинлайнен JIT'ом.

В общем я делал тест, большой список объектов точка Point { double X,Y; }, в цикле значения координат точки увеличиваются на какое-то значение и точка пишется обратно в список,
- в первом случае X,Y свойства вида { get { return x; } set { x = value } } и точки хранятся в List<Point>,
- во втором случае X,Y просто публичные поля и точки хранятся в Point[].
В режиме Release со всеми включенными оптимизациями первый код дольше второго в 3-4 раза (из них в 1.5 раза медленнее это доступ к свойствам X,Y, в 2.5 раза медленнее доступ к индексатору List[]), в режиме Debug и отключенной оптимизации первый код дольше второго в 12 раз! С тех пор у меня все алгоритмы геометрии работают только с подобным типом точек и массивами.

В таком случае, это просто разные механизмы решающие разные задачи.
В C++, Delphi спецификаторы доступа - это просто помощь забывчивому кодеру, чтобы по нечайности не изменил чего не нужно и вообще не создавал дополнительной связанности.
Ежели полностью в себе уверен - можно всё на структурах писать - разницы не будет.
Понятно, что когда код работает этого всего уже не нужно. :)
А в .Net - это похоже один из механизм аутентификации - стало быть и применять его нужно не так и не для того.

Код создаётся/подгружается 1 раз. Его же нельзя после этого модифицировать.
Доступы ему назначаются 1 раз - зачем каждый то раз проверять?

Я довольно долго и плотно работал в проекте с векторной графикой.
Серьёзно бороться с производительность пришлось 3 раза:
1) Ещё для 486 пришлось написать перевод координат из мировой в оконную, т.к. багланд совсем не умеет оптимизировать плавающую точку и тупая реализация на асме его обгоняет.
2) Т.к. для багланда не было профилятора пришлось руками логировать код, чтобы доказать что тормозит не отрисовка а доступ к базе :)
3) Пришлось повозится с надписями - там пришлось кешировать каждый чих, правда до глифов таки не опустился. :)
Сейчас оно конечно вряд ли взлетит на 486, но везде, где Win95se ещё шевелиться работать вроде должно не зависимо от объёма данных :)
А ты говоришь, 1,5ггц, 512мб...

> Доступы ему назначаются 1 раз

Доступы ты можешь запрашивать и изменять динамически из программы.

http://www.prog.org.ru/topic_7959_0.html
продолжим флэйм с учётом обновлённых фактов? :)

А какие там факты появились, что то не пойму. Своя IDE появилась? Так сначала бы integration для VS до ума довели бы, а потом о своей IDE думали. Хотя возможно для MacOS/Linux эта IDE и важна.

Integration для VS ненужен

Кому ненужен, линксоидам?

Is Qt Creator a replacement for Visual Studio?
Qt Creator is not a Visual Studio replacement, but instead a lightweight IDE designed specifically for cross-platform Qt development. We developed Qt Creator to provide our users with options. If a developer is comfortable with Visual Studio, we highly encourage them to continue using it. We will certainly continue to develop and improve our Visual Studio integration.

мне он и под вендой не нужен - я сейчас под мингвом пишу :)
а по удобству и возможностям Qt Creator уже постепенно приближается к студии...

Это не есть обходимая вещь. Я пишу под вендой в студии, интегратор неюзал ниразу. А зачем он? ;)

не исключено что я на него перейду если понравится, так что скачаю посмотрю.


А низачем, глюкавый он. Но т.к. установил все таки пытаюсь изучить и приспособиться к нему. Чтобы потом тут не спрашивать "А зачем он?"

Я вот думаю, что при своей ИДЕ смысла в интеграторе никакого.
работаю в кодеблоке, он хоть для wx предназначен, но отлично с Qt справляется без всяких интеграторов.
Думаю они нужны для "мышиных детей", которым "западло разбираться в сути явлений, легче кнопку нажать"...

Я здесь прочитал про удобство и изысканность С# ???
Я начинающий программист нам преподавали С++ и  С#!!!
Куча классов  в С# кстати половина c которых по моему мнению не нужны!
Коду нужно в С# в два рази больше писать
В Net единствиное преимущество это сама студия!
МСДН штука хороша но уступает QT Assistant  по простоте и примерам по моему мнению!
-------------------------------------------------------------------------------
Вы сравните размер исходников С++ и  С#!!!!
И попробуйте написать прогу в notepad!!!


  

Хорошо написано про кучу классов которая по его мнению не нужна. Непонятно про какие исходники C++ и C# идет речь.

а кто заставляет писать в notepad??... Qt прекрасно интегрируется в студию, эклипс, да и с kdevelop я долгое время работал.... да и в конце концов есть же и QtCreator.... а по поводу классов которые не нужны.... дык это сугубо субъективно.... вы не думали что кому то они очень даже нужны??

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

Насчет кода в C# 2 раза писать - не согласен полностью. :o
В .NET все классы весьма продуманы в отличной объектно-ориентированной манере.
Многое сделано за вас. А хорошее продумывание дизайна поможет избежать неприятностей.
А их количество - ну надо понимать, что .NET можно разделить на 2 части:
1) Клиентскую (WinForms, WPF и т.д.)
2) Серверную (ASP.NET, WCF и все к ним относящееся)
Некоторые библотеки необходимы и тут, и там (сеть, ADO.NET и т.п)

Кстати, в .NET начиная с версии 3.5 SP1 есть вариант установки только клиентской функциональности: Client Profile.

Ну, а если про удобство C# - то все просто идеально. В языке есть все что нужно.
Разве что отсутствует множественное наследование как в C++, однако это может и к лучшему.
Во всяком случае данный вопрос решается использование дополнительных интерфейсов или более правильным продумыванием дизайна проекта.

А вот, что насчет Qt - то это действительно прекрасная библиотека для программистов на C++.
Все четко и гладко. Многие архитектурные моменты может почерпнуть оттуда.
Не сравнить с MFC и другими
Документация MSDN - все нормально и понятно (особенно для раздела .NET Base Classes)

Сам пишу на C# и очень этим доволен. ;D

дико извиняюсь, но *что* можно писать в сочи?

да, и кстати, как вам эти-самые "WinForms, WPF и т.д."? удобство - просто идеально, не так ли?

Ну, что ж ответим по порядку.


Как Вы уже заметили пишу я в Сочи - "отдаленной провинции" :)
Здесь можно создавать программы или дополнения к уже существующим для предприятий, гос- и учебных (ВУЗы) учреждений: для учета, управления или тестирования. Также пользуются успехом сайты - в основном визитные.


WinForms - отличная обертка над Win32 API. Много удобств в сфере быстрого создания GUI. Торможений особых не наблюдается, если не перебарщивать с Layout Panels.
Также к достоинствам можно отнести достаточное количество методов, свойств и событий самих контролов. Идеально для офисных приложений.
Если покопаться поглубже, то можно создавать свои управляющие элементы (наподобие outlook bar). Но, хочу заметить, что это не касается перегруженных графикой UI.

WPF - удобно создавать приложения именно с богатой графикой, анимацией и т.п. Также технология привязки данных позволяет делать визуализацию данных весьма и весьма легко.
Также изучив WPF, можно запросто переходить на Silverlight. Правда не устраивает рендеринг текста на мелких шрифтах и не настраиваемый подбор текста (в 4 все нормально)
Если же не устраивает дизайнер Visual Studio, то используйте Blend (особенно версии 3).

И к слову: обе технологии можно использовать совместно - никто не отменял ElementHost и WindowsFormsHost.

Вот я писал на C# .Net раньше, щас снова заставляют... Я так не хочу!!!  :'(   ХАЧУ КУ ТЭ  :'( :'( :'(
.Nete все такое кривое, глючное и
Извините ребят за офтоп, может кто подскажет ссылку на пример с рекомендациями, как Qt шный модуль засунуть в .Net овский проект?  :)