ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана.
Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
08.08.06 18:31: Перенесено из 'Философия программирования'
08.08.06 23:24: Перенесено модератором из 'Священные войны' — Kupaev
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана.
Я рад, что интернет доступен даже в детских садах! Моя родина всё же стремится не отставать от загнивающего запада, и это хорошо, это прекрасно!
Читай, деточка, интернет, развивайся, учись. Ты же блин наша смена! Только вот пиши поменьше, читай побольше, а то тебя оскорблять матерными словами будут, а тебе ещё рано их учить, надо годика четыре погодить исчо.
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана. _>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу
А если так:
Ненавижу все, что связано с unmanagment C++, программы на них ужасно глючные, постоянно приводят к утечкам памяти, с которыми никто не знает, как бороться, такие глюки держаться до полугода даже в проектах, где работают до 100 программистов, они постоянно правят баги в чужом коде, притом часто когда этого кода даже нет. Язык в "кривых" руках превращается в мешанину, а если программист еще приверженец экспресс поделок, то прочесть код становиться невозможным. Про время, затраченное на написание интерфейса промолчу — всякие рюшечки мигают и тормозят. А время, потраченное на написание стандартных вещей в 5-6 раз больше чем даже в Delphi. Аффторы, застрелитесь, делайте все правильно, делайте качественное ПО, которое не приводит к синему экрану и не падает при попытки выполнить ряд вполне стандартных действий.
А если честно, то считаю, что каждый язык достоин той ниши, где он расположен. Быстрые разработки — delphi, надежность — Framework, монументальность — Java, быстрота работы — C++. И на каждой платформе нужен свой тип людей, нацеленных на работу именно с ней и с правильно заточенными руками.
Вот не хотелось ведь флеймить, но видимо придется!
Это анализ компиляторов?
Хотелось бы понять, а что собственно он анализировал?
Провести тестирование некоторых конструкций (например, обращение к полю объекта) не удастся из-за оптимизации на уровне компилятора: строки типа for (unsigned i=0;i<10000000;i++) dummy = obj->dummyField; все компиляторы просто выбросили из конечного бинарного кода.
Какая досада! Двумерное преобразование фурье изображения врядли бы кто нибудь выбросил.
Наличие такой нетривиальной низкоуровневой оптимизации наводит на мысль о необходимости анализа сгенерированного кода на уровне ассемблера.
Навело на мысль во время написания статьи, ибо именно в это время автор об этом узнал!
Кроме того, для Borland Builder была добавлена опция --fast-call — передача параметров через регистры (Intel Compiler, MSVC++ и gcc автоматически используют передачу параметров через регистры при использовании оптимизации по скорости).
Бред.
fastcall использует только ecx и edx, остальное через стек.
MSVC++ не использует fastcall ни при каких настройках, только если указать явно.
Тестирование было разделено на несколько независимых частей. Первая — тестирование скорости работы основных конструкций языка (виртуальные вызовы, прямые вызовы и т.д.). Вторая — тестирование скорости работы STL. Третья — тестирование менеджера памяти, поставляемого вместе с компилятором. Четвертая — разбор ассемблерного кода таких базовых операций, как вызов функции и построения цикла. Пятая — сравнение времени компиляции и размера выполняемого файла.
Особенно интересно тестирование прямых вызовов!
И как же это разные компиляторы умудряются делать их по разному
Разные компиляторы поставляются с разными версиями STL. Поэтому глупо их сравнивать.
Менеджер памяти в итоге у всех один: Win32 heap manager.
При выделении блоков размер которых варьируется в диапазоне от 16b до 16mb все работают одинаково.
А если по байтику выделять и освобождать, то результаты действительно будут разными, однако на практике это не выполняется.
И еще, здесь компиляторы сравниваются или эвристики malloc()?
Как видно, MSVC++ инвертировал цикл и for (unsigned i=0;i<16;i++) у него превратился в unsigned i=16;while (i--);, что очень правильно с точки зрения оптимизации — мы экономим на одной операции сравнения (см. следующий листинг)
Современным процессорам плевать на эту операцию сравнения, поскольку она спаривается,
а вот проход по памяти в обратном порядке может привести к большим задержкам.
VC7 и 8 по возможности разворачивают как раз наоборот в прямой порядок, даже если написать в обратном.
И еще некоторые вопросы:
Где исходные коды всех примеров?
Где тестирование на десятке различных алгоритмов (элиминатор Жордана, сортировки, поиск и тп)?
Где тестирование свертки подвыражений?
Где анализ предсказаний переходов?
Где оптимизация ветвлений?
Где рассмотрение специфических инструкций современных процессоров (SSE,SSE2)? Ах да! в билдере их нет.
Где разбор каждого примера и кода полученного каждым компилятором?
В общем автор разбирается в оптимизации и процессорах, как свинья в апельсинах.
Прочитал пару книжек (типа Юрова), и относится к тем кто с пеной у рта спорят
что быстрее работает rep stosd или rep stosw.
Казалось бы, вывод о самом эффективном компиляторе напрашивается сам собой — это Borland Builder C++.
Интересно, а ты читал с пониманием, или сразу перешел на эту строчку?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, ShibaON, Вы писали:
SON>>Вот, как и обещал: Сравнительный анализ компиляторов С++ >>> Intel C++ Compiler 4.5 CC>Он еще древнее найти не мог? CC>Я к тому времени на 7-м сидел.
А что у Intel C++ Compiler так координально изменилось? Разве его от версии к версии переписывали с нуля?
Ну вот и поговорить можно нормально, я всегда за здоровый спор а не за "голое" отрицание.
_>Посмотрел сайт, не стал качать. Судя по скрину, там не особо будет глючит. Вот смотри, глюки проявляются при наслоении элементов и в местах, где важна скорость, например сплиттер какой-нить поставить, сразу всё портится, работу уже продолжать не хочется. Автоматический алигн + частое обновл. + горы vcl кода = глюки_глюки_глюки = )
Если знать технику, то все нормально получается, ты зря, кстати софт не скачал, там ничего не моргает, над интерфесом очень долго бились там у нас даже диалоги все точь в точь по стандарту. Про моргание, мне что нравится в VCL, там у каждого контрола, который представляет собой окно, есть свойство DoubleBuffered, если его поставить в тру, то моргать он уже никогда не будет, а еще инетерсней его реализация, я когда посмотрел в исходниках, у себя в проге на MFC такое же замутил, переписал большинство контролов, чтобы у них тоже было свойство DoubleBuffered. А по поводу гор кода, это было бы страшно, если бы этот код был не ООП, а если следовать ООП, то по идее глюков должно быть меньше. Очень часто, у начинающих кодеров на Delphi есть одна глобальная (так сказать extern) проблема: не понимание ООП, из за этого, часто случаются косяки, потому что VCL рассчитана прежде всего на ООП,
пример ламаковского кода:
...
ShowInformationBoxInCenter(Form1, 'Message');
...
пример правильного кода:
...
ShowInformationBoxInCenter(self, 'Message');
...
Вот из-за таких, казалось бы мелочей (сами по себе они не приводят, естественно к ошибкам) начинает складываться неправильный код, бэги в котором не просто живут, а сами по себе плодятся, появляются все новые и новые, и никто не способен их уже победить. Отсюда и VCL ругаться начинает, чуть что не так. А кстати, про Акцесс Волюшены: когда на WinAPI пишешь, тоже очень часто ошибки возникают, просто там нет какого-то встроенного механизма проверки, приходится самому возвращаемые значения проверять и сакмому эти Акцесс Волюшены выводить.
_>Это сложно выразить, это надо почувствовать... растягиваешь окно, а оно всё мерцает, глючит (если на Vcl).
Я тебя понимаю, на MFC тоже кстати гемор такой есть, бывает день сидишь у нужных контролов ON_WM_ERASEBKGND лочишь.
Говорю: DoubleBuffered и все ништяк!
Мелкософтовцы, кстати кое-что в своем НЕТе позаимствовали у Borland'a, например property.
За что я не люблю Delphi: я не люблю Delphi за то, что каждый ламак может сесть за него и написать что-то более-менее похожее на GUI-шную прогу, с никакой объектной моделью внутри (хотя юзера это вообще не парит) . Этаких ламаков очень много и прог у них очень много, из-за этого у всех складывается ощущение, что Delphi — это ламаковская фигня, и те кто пишут на Delphi тоже ламаки. Из-за этого я не люблю уже не Delphi, а этих ламаков
Теперь, что я думаю про Delphi: Delphi это результат многолетних трудов Borland, которая работает всю свою жизнь над компиляторами (в отличие от Майкрософт, которая написала компилатор, только для поддержания своего престижа). И компилатор, например С, думаю меня тут поддержат все профессионалы, у Borland гораздо лучше чем у Microsoft. Про Delphi не говорим (не с чем сравнивать , но думаю и у Delphi компилятор тоже произведение искусства. Сама VCL образована от OWL, которая в свою очередь входила ещё в Borland C++ 4. Так что по поводу правильности и безглючности самого кода VCL у меня сомнений никогда не было — она писалась долго и писалась профессионалами. Все глюки — это результат неправильных действий псевдо-ламо-кодеров.
Теперь сравним VCL с .NET Framework: VCL лет-то уже порядочно, он давно утвердился, а фреймворк — вещь молодая, кто ещё знает что с ней будет. C VCL — плюс 300-800 кб. к вашей проге. Фреймворк — 48 метров к вашему дистрибутиву (притензии типа: "раз установил и все" не принимаются, в VCL тоже так можно: максимум 16 метров в сжатом виде).
Про моргание, мне что нравится в VCL, там у каждого контрола, который представляет собой окно, есть свойство DoubleBuffered, если его поставить в тру, то моргать он уже никогда не будет, а еще инетерсней его реализация, я когда посмотрел в исходниках, у себя в проге на MFC такое же замутил, переписал большинство контролов, чтобы у них тоже было свойство DoubleBuffered.
...
На API нет такого свойства, ничего не надо переписывать и лочить, и ничего не моргает.
За что я не люблю Delphi: я не люблю Delphi за то, что каждый ламак может сесть за него и написать что-то более-менее похожее на GUI-шную прогу, с никакой объектной моделью внутри (хотя юзера это вообще не парит) . Этаких ламаков очень много и прог у них очень много, из-за этого у всех складывается ощущение, что Delphi — это ламаковская фигня, и те кто пишут на Delphi тоже ламаки. Из-за этого я не люблю уже не Delphi, а этих ламаков
Согласен. На это обречен любой продукт на котором легко работать.
Borland, которая работает всю свою жизнь над компиляторами (в отличие от Майкрософт, которая написала компилатор, только для поддержания своего престижа). И компилатор, например С, думаю меня тут поддержат все профессионалы, у Borland гораздо лучше чем у Microsoft. Про Delphi не говорим (не с чем сравнивать
И тут появилась профессиональная группа поддержки с ящиком гнилых томатов
Есть один такой компилятор от борланд (шел в комплекте с IDE) Borland C++ 3.0 (ето исчо под ДОС).
Качество его кодогенератора просто ошеломляло своей паршивостью. В принципе в те времена и на тех машинах
оптимизатору особо негде было разбегаться, но этот был из ряда вон! (в т.ч. и по глючности)
И самое интересное, что с тех пор ничего в компиляторостроении от борланда не изменилось!
У всех новых поделок борланда все тоже раритетное ядро.
Даже Builder6 генерит все тот же поганый код, разве что регистры сменили на 32-х разрядные.
Набери в любой версии билдера:
int main() {
{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{
}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
return 0;
}
И он свалится, также как валились все его предшественники.
И MS и Borland начали заниматься компиляторами в одно и тоже время (Turbo-C vs Quick-C).
Я не утверждаю что компилер от Visual C++ идеален и безглючен, но MS его по крайней мере постоянно переписывает.
Про сравнение оптимизаторов не буду флеймить. Если знаешь asm то сам сравнишь, а не знаешь, никто тебе ничего не докажет.
А компилятор Delphi есть с чем сравнивать, например с билдером
Их кодогенераторы идентичны.
Так что по поводу правильности и безглючности самого кода VCL у меня сомнений никогда не было — она писалась долго и писалась профессионалами. Все глюки — это результат неправильных действий псевдо-ламо-кодеров.
А в MS сидят ламеры
И все проблемы в мире из-за действий мега-тупо-гопников
Теперь сравним VCL с .NET Framework: VCL лет-то уже порядочно, он давно утвердился, а фреймворк — вещь молодая, кто ещё знает что с ней будет.
Что стало с билдером мы с вами уже знаем. Скорее то же будет и с Delphi. Не потому что лучше или хуже.
А потому что у когото гигабаксов больше, а у когото меньше. Есть у меня одно опасение, что все псевдо-ламо-кодеры со временем
пересядут на """мегабезопасный удобный и безглючный фреймворк""". Точнее не пересядут а новые народятся,
поскольку псевдо-ламо-кодеры не любят пересаживаться и совершать какие либо телодвижения.
C VCL — плюс 300-800 кб. к вашей проге. Фреймворк — 48 метров к вашему дистрибутиву (притензии типа: "раз установил и все" не принимаются, в VCL тоже так можно: максимум 16 метров в сжатом виде).
C API — плюс 0 кб к вашей проге. А размер фрамеворка енто не проблема. В висте он будет запаян, хотя
если проанализировать скорость с которой MS клепает новые версии, и учитывая их несовместимость то к
выходу висты появится куча незапаянных новых версий которые нужно будет качать.
ЗЫ Я тут собрался COM изучать, а MS сказала дескать COM атстой юзай .NET
поэтому теперь ни COM ни .NET я изучать не тороплюсь. Вдруг завтра .NET будет атстой.
SON>Теперь, что я думаю про Delphi: Delphi это результат многолетних трудов Borland, которая работает всю свою жизнь над компиляторами (в отличие от Майкрософт, которая написала компилатор, только для поддержания своего престижа). И компилатор, например С, думаю меня тут поддержат все профессионалы, у Borland гораздо лучше чем у Microsoft.
Я не специалист в области компиляторов, но где как ни наткнусь на тесты производительности и сравнение результирующего кода, так все время ориентируются на Интел-С, который обычно считают лучшим или MS-C++ 7.1 и 8.0, которые "где-то рядом".
Gcc обычно приводят — распростанненый очень товарищ...
А про Борланд зачастую и не вспоминают...
Здравствуйте, ArhAngelVezel, Вы писали:
_>>и вообще, я бы в контексте данного разговора не стал бы разделять .NET и Java. считаю. что их тут нужно вместе рассматривать.
AAV>А может не надо?. .Net более прогрессивние Java, ибо стандартных компонент в нем больше и не надо часами выбирать из GNU компонентов сторонних разработчиков (imho+Windows).
Скаких пор прогресс начали мерять в количестве стандартных компонент? Да и каких конкретно компонент? Визуальных что ли? И причем тут GNU? В java полно сторонних фреймворков (Spring, Hibernate) и библиотек (от Apache.org), которые используются в промышленном коде и по BSD-like лицензиям. Я уж не говорю, о том, что многие из них портированы на .Net с приставкой N Где вы тут прогрессивность .Net?
Whistler wrote: > а) Visual C++ — 2 месяца работы двух программистов, лабающих на MFC + > WinAPI и требующих зарплаты $1.6к (только потому, что они нефиговые > C++-программеры, а не какие-то делфисты тупые). Бюджет: 1.6 * 2 мес * 2 > чел = $6400 > б) Delphi 7 — 2 недели одного Delphi-программиста (просто потому, что в > делфи уже на базе VCL сужествует огромная куча функциональности привязки > к данным, формирования отчетов и т.д.) с окладом $800 (потому, что > квалификации программистов для данной задачи достаточно, чтобы знать > только VCL + на базовом уровне SQL). Бюджет: $400.
Развиваем идею. Приложение понравилось, в него решили добавить новые
функции. Но в дельфяном приложении все построено на прямом биндинге
полей к результатам запроса (а как же — надо чтобы все было быстро
разработано), а в MFCшном приложении сделана объектная модель и выделен
слой работы с БД.
Поэтому MFCшники очень быстро прикручивают новую фичу, а дельфинисты
каждый раз перекурочивают половину форм. Причем получают в итоге
глючащее приложение из-за того, что постоянно забывают поправить
какой-то запрос.
Я лично такую ситуацию наблюдал не один раз. С помощью Дельфи/VB можно
очень быстро сделать начальное приложение, но вот потом поддерживать его
очень сложно.
Естественно, можно сразу писать на Дельфи красиво и нормально. Вот
только все магические улучшения производительности программиста куда-то
пропадут.
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана. _>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу
AAV>А если честно, то считаю, что каждый язык достоин той ниши, где он расположен. Быстрые разработки — delphi,
не-а, VS2005 и IDEA — самые скоростные сейчас.
>надежность — Framework,
да. .NET и Java
>монументальность — Java,
добавь и дотнет
>быстрота работы — C++.
где? на какой аппаратной платформе?
подробную спецификацию плз...
и вообще, я бы в контексте данного разговора не стал бы разделять .NET и Java. считаю. что их тут нужно вместе рассматривать.
П.С, делфи для своего времени была классная технология. Но, в нынешних реалиях — ей совершенно нечего противопоставить .NET + Java. Развитие некогда очень хорошей технологии, к сожалению, полностью остановилось.
Здравствуйте, unreg_flex, Вы писали:
_>Много раз сайзил на WM_SIZE (однажды даже около 20 штук) и все равно ничего не моргает! _>А что такое Anchors?
А я раз разместил в окне GroupBox, над ним (сам он не может быть парентом) разместил несколько эдитов и чекбокс, всем поставил WS_CLIPSIBLING, и пипец что было .
Ценители Фреймворка знают, что такое Anchors,тоже что и Anchors в VCL.
_>Примерно такой ответ я и ожидал увидеть. _>Знаешь, гдето здесь обитает любитель оберона, так вот у него он тоже всех натягивает. _>Но он по крайней мере прекрасно осознает, что именно он защищает и на все смотрит со своей позиции. _>Самое страшное когда у человека нет собственного мнения потому что он не в состоянии сам сравнить _>и вынужден приводить доводы типа: "Мне Васька сказал, что Петька круче всех во дворе."
Я и пытаюсь сам сказать, что Delphi — это не отстой, что с помощье него можно неплохо зарабатывать, но мне наслово , почему-то никто не верит, а самому брать дизассамблер и делать тесты — у меня времени нет, да и зачем мне это нужно, меня-то ведь все устраивает. Здесь я не собираюсь навязывать свое мнение, здесь я просто им делюсь с остальными, внимательно выслушивая других. А что касается моего, конкретно, мнения про все это дело, то я за тот небольшой промежуток времени, с которого здесь зарегился, уже несколько раз высказал свое мнение "обо всем об этом": Для каждой задачи свой инструмент. Гаму, например на D3D на Delphi только пароноик писать начнет, зато небольшую офисную прогу на Delphi я сделаю гораздо быстрее, чем на MFC, но такого удовольствия, как от C++ я не получу никокда ни от какого языка программирования. И споры между кодерами на Delphi и С++ напоминают мне студенческие годы. Давайте просто говорить о достоинствах и недостатках, а не о том, что Delphi — это шит (если это шит, почему его тогда покупают, кучу книг о нем пишут?). Нет ничего идеального, правда нет, тут-то я точно сам все проверил и сравнил и идеального не нашел!
Я ни разу не сталкивался с багами компилеров Borland's. Ни разу! Где они? Покажите мне их? Некорректная работа на всяких там {{{{{{{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}}}}}}} — это не довод!
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Ubivetz, Вы писали:
ZS>>>В Assемблер вам дорога!! Быстрее не придумаешь. U>>Неправда! Машинный код чуть быстрее
L>Это еще почему?
Потому что машинный видимо
Хотя конечто если взять например MASM версии хотя бы 5 и от души попользоваться всякими нехарактерными для нормального ассмеблера наворотами тогда то, что скомпилится, может оказаться не совсем тем, что хотелось
Здравствуйте, Ubivetz, Вы писали:
U>Здравствуйте, ZevS, Вы писали:
ZS>>В Assемблер вам дорога!! Быстрее не придумаешь. U>Неправда! Машинный код чуть быстрее
Это ваша неправда — быстрее фортрана ничего не предумано, потому что "он выполняет программы минуя процессор" (c) народ. 1997 год.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, siberia2, Вы писали:
_>>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов.
S>Вы полагаете, что прога на буилдере от борланд будет работать лучше?
Создание прог на "буилдере от борланда" ничем не отличается от создания прог в других средах.
В чем-то лучше, в чем-то хуже.
Я, к примеру, использую компилятор от BCB5 для контроля компилятора VC8. В итоге получаю дополнительную уверенность что все нормально
Насчет багов BCB ... а где их сейчас нет?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, apple-v-otpuske, Вы писали:
AVO>PPS sorry, nabolelo :/
Слуш, найди транслитератор а... А то мне например твою писанину читать тоже "наболело"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Не хочу повторятся, но: А что у Intel C++ Compiler так координально изменилось? Разве его от версии к версии переписывали с нуля?. Это не риторический вопрос, это просто вопрос.
Очень хочется влезть!
Генерация машинного кода на основе потоковых команд (векторизация циклов)
Поддержка новых расширений Intel-овских процессоров SSE2 SSE3.
Оптимизация под несколько процессоров, с возможностью динамического выбора на стадии выполнения.
Оптимизация под конкретные модели процессоров Up to P4
Отложенная кодогенерация на стадии сборки.
Эмулятор компилируемого кода, для расчета вероятностей выполнения переходов и узких мест на стадии компиляции. (мегафича)
Упрощение выражений, такого не видел нигде! Например sin(x)/cos(x) заменяются на tan(x)
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана. _>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу
Ты просто дурак! (не как оскорбление, а как оценка твоего интелекта на основе содержания твоего поста)
А когда осознаешь что ты дурак, будет очень поздно!
Я писал это на RSDN сто раз, однако для некоторых придется повторить:
1) Delphi — это инструмент быстрой разработки приложений.
Задача: написать приложение, автоматизирующее определенный бизнес процесс предприятия
Реализация:
а) Visual C++ — 2 месяца работы двух программистов, лабающих на MFC + WinAPI и требующих зарплаты $1.6к (только потому, что они нефиговые C++-программеры, а не какие-то делфисты тупые). Бюджет: 1.6 * 2 мес * 2 чел = $6400
б) Delphi 7 — 2 недели одного Delphi-программиста (просто потому, что в делфи уже на базе VCL сужествует огромная куча функциональности привязки к данным, формирования отчетов и т.д.) с окладом $800 (потому, что квалификации программистов для данной задачи достаточно, чтобы знать только VCL + на базовом уровне SQL). Бюджет: $400.
Результат:
В обоих случаях одно и тоже приложение. Теже самые поля ввода, те же самые формы, те же самые отчеты на принтер и т.д.
В приложении на Delphi время отклика на действия пользователя, допустим, 1,3 сек (из-за того, что все написано на громозтком VCL).
В приложении на C++ вреся отклика на действия пользователя, допустим, 0,8 сек (из-за того, что писали более грамотные программеры, на более низком уровне).
При составлении требований к разработки того или иного ПО отдельными пунктами указываются требования к производительности. И, допустим, если в реквайментах закащик указал — отклик не более 2 секунд, то значит оба варианта решают задачу.
Фактические различия:
Никаких, девка на рецепшене особой разницы не заметит в скорости обоих приложений.
Итог:
Нафига переплачивать больше? У IT-подразделения лишние $6000 баксов?
Задумайся над этим. И пойми — кроме того, что знать C++-реализацию алгоритма сортировки методом пузырька, надо еще быть немного экономистом. Иначе тебе ничего выше рядового программиста не светит в сфере IT.
P.S. Я каким либо образом унизил хотя бы одну из технологий? Я просто привел факты — пищу для размышлений.
P.P.S. C++ хорош, и Delphi хорош и все остальные технологии хороши. — просто надо знать где уместнее применять ту или иную технологию (естественно, для разработки приложения высокоточного вычисления магнитных полей изотопов расчепления атомов метана в абсолютно низких температурах, Delphi не совсем пойдет — там VCL особо не понадобится, а программа на трехэтажной математике банально будет работать в десятки раз медленнее).
P.P.P.S .NET Framework является некоторым заменителем концепций Delphi в быстрой и дешевой разработки приложений.
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО.
Все это ложь, батенька! Я сам на работе на Delphi пишу, вот глянь, что получается: www.visualcertexam.com. Если ты считаешь, что она тормозная, то что ты тогда скажешь про C++ Builder? Да и Visual C++ — не верх производительности. Что касается больших проектов, вышеуказанный проект маленьким никак не назовешь (более 40 юнитов), а время полной компиляции (если удалить все .dcu), обычно, не превышает и половины минуты, а так — секунды четыре. Я бы застрелился, конечно, но платят неплохо, знаешь ли. Дома на С++ и чистом WinAPI пишу — для души, ещё MFC люблю , ну вот так.
_>Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана.
А ты купил купил себе бровзер, в котором мою писанину читаешь?
_>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу
Согласен, при всей моей искренней любви к Майкрософт , VCL по многим показателям гораздо лучше .NET Framework
Здравствуйте, ShibaON, Вы писали:
SON>Все это ложь, батенька! Я сам на работе на Delphi пишу, вот глянь, что получается: www.visualcertexam.com. Если ты считаешь, что она тормозная, то что ты тогда скажешь про C++ Builder? Да и Visual C++ — не верх производительности. Что касается больших проектов, вышеуказанный проект маленьким никак не назовешь (более 40 юнитов), а время полной компиляции (если удалить все .dcu), обычно, не превышает и половины минуты, а так — секунды четыре. Я бы застрелился, конечно, но платят неплохо, знаешь ли. Дома на С++ и чистом WinAPI пишу — для души, ещё MFC люблю , ну вот так.
Посмотрел сайт, не стал качать. Судя по скрину, там не особо будет глючит. Вот смотри, глюки проявляются при наслоении элементов и в местах, где важна скорость, например сплиттер какой-нить поставить, сразу всё портится, работу уже продолжать не хочется. Автоматический алигн + частое обновл. + горы vcl кода = глюки_глюки_глюки = )
Это сложно выразить, это надо почувствовать... растягиваешь окно, а оно всё мерцает, глючит (если на Vcl). Билдер особо не юзал. Смотря какой проект, если платят — конечно на дельфе можно сделать, кушать тоже хочется, но качество проги ужас будет. Вобщем я за качественный код, а не просто тупое отвращение к дельфи. Даже на дельфе можно сделать качественный, если без vcl, а на Апи, но все делают этот vcl.
SON>А ты купил купил себе бровзер, в котором мою писанину читаешь?
не-а, не купил бы. Она бесплатная. Ну конечно я юзаю разные и шареваре и фривейр проги, и всякие остальные тоже, но не покупаю их.
_>>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу SON>Согласен, при всей моей искренней любви к Майкрософт , VCL по многим показателям гораздо лучше .NET Framework
rsdn@home на delphi+vcl переписать == море глюков. Еще хуже чем есть сейчас на фремворке.
Здравствуйте, cod3r_200, Вы писали:
_>Выражаю свою точку зрения — надеюсь очень объективно. То что на с++ это понятно, только там такая прослойка кода, что это превращается в vcl
И к тому же на "классическом" С++ под нее ни строчки не напишешь
Здравствуйте, ShibaON, Вы писали:
SON>Вот, как и обещал: Сравнительный анализ компиляторов С++ >> Intel C++ Compiler 4.5
Он еще древнее найти не мог?
Я к тому времени на 7-м сидел.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
SON>Теперь, что я думаю про Delphi: Delphi это результат многолетних трудов Borland, которая работает всю свою жизнь над компиляторами (в отличие от Майкрософт, которая написала компилатор, только для поддержания своего престижа).
Причем не один компилятор . Наверное что бы престижа больше было .
SON>И компилатор, например С, думаю меня тут поддержат все профессионалы, у Borland гораздо лучше чем у Microsoft.
Уж тут тебя врятли кто-то поддержит.
SON>Теперь сравним VCL с .NET Framework: VCL лет-то уже порядочно, он давно утвердился, а фреймворк — вещь молодая, кто ещё знает что с ней будет. C VCL — плюс 300-800 кб. к вашей проге. Фреймворк — 48 метров к вашему дистрибутиву (притензии типа: "раз установил и все" не принимаются, в VCL тоже так можно: максимум 16 метров в сжатом виде).
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана. _>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу
Среды разработки Delphi и C++ Builder, насколько известно автору, не "доверяют" стандартным функциям управления кучей и реализовали свои. Здесь алгоритм другой: куча делится на несколько подкуч, каждая из которых предназначена для выделения блоков строго фиксированного размера: к примеру, одна предназначена для выделения 4-байтных блоков, вторая — 8-байтных, 3-я — для 16-байтных, и т. д. Такой подход имеет как минимум два преимущества. Во-первых, не нужно создавать дерево свободной памяти — достаточен простой список, так как нет необходимости в поиске свободного блока и можно взять просто первый попавшийся элемент списка (вспомним, что элементы фиксированного размера). Во-вторых, фрагментация практически отсутствует (по крайней мере, вероятность в какой-то момент получить отказ в выделении блока нужного размера резко снижается). Я уже не говорю о том, что в дефрагментации отпадает необходимость.
Алгоритм, примененный в Delphi и C++ Builder, оказался удачным, и его внедрили в последние версии операционной системы Windows под названием LFH (low-fragmentation heap). Теперь программист имеет возможность пользоваться как стандартной кучей, так и кучей с пониженной фрагментацией.
Здравствуйте, _wah, Вы писали:
_>Здравствуйте, ArhAngelVezel, Вы писали:
_>не-а, VS2005 и IDEA — самые скоростные сейчас.
ну не надо говорить о среде. Придержимся того что _стиль_ написания delphi приложений гораздо более подходит под стиль написания "надо было сделать еще вчера". Хотя, у меня знакомые пишут достаточно прогрессивные системы на delphi не используя VCL совсем. Ну любят люди Pascal, что сделать .
>>быстрота работы — C++. _>где? на какой аппаратной платформе? подробную спецификацию плз...
На любой. Не будем наивными и примим за факт что машина не может думать лучше людей (с творческой стороны). Если же как ни раз доказывалось написать хорошо на Basic и используя кривые руки написать на асме то тут можно тоже сравнивать скорости.
_>и вообще, я бы в контексте данного разговора не стал бы разделять .NET и Java. считаю. что их тут нужно вместе рассматривать.
А может не надо?. .Net более прогрессивние Java, ибо стандартных компонент в нем больше и не надо часами выбирать из GNU компонентов сторонних разработчиков (imho+Windows).
Здравствуйте, ShibaON, Вы писали:
SON>Не хочу повторятся, но: А что у Intel C++ Compiler так кардинально изменилось? Разве его от версии к версии переписывали с нуля?. Это не риторический вопрос, это просто вопрос.
Для того, чтобы капитально изменить кодогенератор не нужно переписывать весь компилер с нуля. Я начал пользоваться ICC с пятой версии и .pfk 5-7-8-9 версии. И могу уверенно сказать что качество генерируемого им кода улучшилось с тех пор в разы. Кроме того с тех пор (с 5-й версии) появилось дофига чего из процов — соотвественно менялся кодогенератор для ориентации на максимальную производительность кода для последних архитектур и т.п.
Если тебе хочется детальный changelist — вперед на intel.com
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
alexeiz wrote: > P>>Кстати, скомпиленое им под IA64 будет работать на AMD64? > CC>Вроде бы нет. Там набор команд для 64bit чутка отличается > Чутка. Ты шутишь?!
Нет, отличия между EM64 и AMD64 всего в нескольких командах и регистрах.
Здравствуйте, Cyberax, Вы писали:
C>alexeiz wrote: >> P>>Кстати, скомпиленое им под IA64 будет работать на AMD64? >> CC>Вроде бы нет. Там набор команд для 64bit чутка отличается >> Чутка. Ты шутишь?! C>Нет, отличия между EM64 и AMD64 всего в нескольких командах и регистрах.
C>Я не говорю про Itanium — это совсем другая вещь.
alex_kostylev wrote: > C>Естественно, можно сразу писать на Дельфи красиво и нормально. Вот > C>только все магические улучшения производительности программиста куда-то > C>пропадут. > Если перелопачивать половину форм — это не фича а коренная переделка при > изначально неверном проектировании.
Неа, это реалии жизни. Поменялась структура БД — и начинается колбашение
в формах.
А структура БД при RAD-разработке редко с первого раза бывает нормальной.
> И здесь в MFC будет такая же ж.... > Ибо когда неправильно спроектирована объектная модель проблем не меньше > это точно. Если изначально грамотно спроектировать приложение, то будь > оно на C++ и ли на дельфи добавлять новый функционал будет легко и приятно.
Вот только уже не будет таких суперкрутых преимуществ в скорости разработки.
Коваленко Дмитрий wrote: > Я, к примеру, использую компилятор от BCB5 для контроля компилятора VC8.
А вы, случайно, не используете IBM XT для контроля качества генерации
кода для Core 2 Duo?
Здравствуйте, Aquila, Вы писали:
A>Здравствуйте, anton_t, Вы писали:
_>>Здравствуйте, Aquila, Вы писали:
A>>>Люблю быстрые проги, люблю ассемблер.
_>>А я пельмени люблю.
A>Я раньше тоже любил, но сейчас решил отказаться в виду их резко негативного влияния на организм.
Не, ну они не так вредно влияют на организм, как ассемблер
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана.
Очччччень аргументировано и конструктивно .
А главное — объективно
_>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу
Ну так на C++ и сделан! А вообще, не знаешь — не говори.
Здравствуйте, Udjine, Вы писали:
_>>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу U>Ну так на C++ и сделан! А вообще, не знаешь — не говори.
Выражаю свою точку зрения — надеюсь очень объективно. То что на с++ это понятно, только там такая прослойка кода, что это превращается в vcl
Спасибо за обширный ответ, даже добавить нечего
SOL>бывает день сидишь у нужных контролов ON_WM_ERASEBKGND лочишь.
прям паранойа = )
Про дабл буферед знаю конечно, делается оч просто: если графики немного, то просчет рисования в WM_PAINT на "заднем плане", потом битблт. если графики много, хранится картинка в памяти, и никаких просчетов не делается в wm_paint, а сразу битблт. Ну и конечно ws_ClipChildren и ws_Clipblings в с++,мфц. А также еще несколько приемов есть.
SOL>Если знать технику, то все нормально получается, ты зря, кстати софт не скачал, там ничего не моргает, над интерфесом очень долго бились там у нас даже диалоги все точь в точь по стандарту.
А что есть стандарт? если окошки взять как стандарт, то тогда ладно а так — его как такового нету!
с чем связана безработица у дельфинов? работы как таковой нету по ней. Да и все твердят "с++ для профей". так ли это? я могу хорошую прогу написать и без дельфи, только как мне знакомый сказал — этого никто не оценит.
Если интересно, я занимаюсь чатами и всё что с ними связано, знаю все тонкости, опросы тоже не раз проводил, что нехватает юзерам в чатах (всё вместе по этой теме около года). То, чего они хотят, просто нереально сделать на delphi+vcl. Я попытался сделать нечто на дельфе, но это не без глюков получилось, забросил в конце концов. Это так, как конкретный пример.
Здравствуйте, unreg_flex, Вы писали:
_>На API нет такого свойства, ничего не надо переписывать и лочить, и ничего не моргает.
Только потому, что Anchors не используешь, попробуй тока начать сайзить контролы на WM_SIZE — сразу все поймешь
_>И тут появилась профессиональная группа поддержки с ящиком гнилых томатов _>Есть один такой компилятор от борланд (шел в комплекте с IDE) Borland C++ 3.0 (ето исчо под ДОС). _>Качество его кодогенератора просто ошеломляло своей паршивостью. В принципе в те времена и на тех машинах _>оптимизатору особо негде было разбегаться, но этот был из ряда вон! (в т.ч. и по глючности) _>И самое интересное, что с тех пор ничего в компиляторостроении от борланда не изменилось! _>У всех новых поделок борланда все тоже раритетное ядро. _>Даже Builder6 генерит все тот же поганый код, разве что регистры сменили на 32-х разрядные. _>Набери в любой версии билдера: _>
_>И он свалится, также как валились все его предшественники. _>И MS и Borland начали заниматься компиляторами в одно и тоже время (Turbo-C vs Quick-C). _>Я не утверждаю что компилер от Visual C++ идеален и безглючен, но MS его по крайней мере постоянно переписывает. _>Про сравнение оптимизаторов не буду флеймить. Если знаешь asm то сам сравнишь, а не знаешь, никто тебе ничего не докажет. _>А компилятор Delphi есть с чем сравнивать, например с билдером _>Их кодогенераторы идентичны.
На обед пойду, если не забуду скину линк на статью,где ассемблерщик сравнивает компиляторы, там Borland C++ всех натягивает, правда ассемблерщик говорит, что он все-таки ненадежен, но найдите мне прогу, которая чисто из-за ненадежности компилятора постоянно падает.
_>А в MS сидят ламеры _>И все проблемы в мире из-за действий мега-тупо-гопников
Самое смешное тут, это то, что,это отчасти правда
_>Что стало с билдером мы с вами уже знаем. Скорее то же будет и с Delphi.
А что с ним стало? Borland C++ Builder 2006 в составе Borland Developer Studio + 2 Update'а.
Есть у меня одно опасение, что все псевдо-ламо-кодеры со временем _>пересядут на """мегабезопасный удобный и безглючный фреймворк""". Точнее не пересядут а новые народятся, _>поскольку псевдо-ламо-кодеры не любят пересаживаться и совершать какие либо телодвижения.
Тут я твои опасения разделяю, потому что мне так кажется, что .NET сейчас по большей части движут (то есть пишут на нем софт) псевдо-ламо-кодеры, хотя я не спорю, что есть и профи, которые на нем вполне приличный софт пишут, но так и с любым инструментом, с тем же Delphi, хотя бы.
Дык вот, очень удачно в этом топеге пошло сравнение VCL и NET — это меня радует, то есть меня радует то, что люди к ним относятся как к альтернативе написания прог под винду, а не как к основному инструменту.
_>C API — плюс 0 кб к вашей проге.
Я в курсе , но все равно спасибо за напоминание .
_>А размер фрамеворка енто не проблема. В висте он будет запаян, хотя _>если проанализировать скорость с которой MS клепает новые версии, и учитывая их несовместимость то к _>выходу висты появится куча незапаянных новых версий которые нужно будет качать.
Размер фреймворка, сам по себе — это не проблема, но у меня всегда был такой вопрос, и сейчас, наконец я его задам: что там такого в Фреймворке, что его дистрибутив жрет 48 метров?
И опять вы про Висту, где эта Виста? Тока вторая бета есть и все, а лет то уже сколько прошло, вот когда выйдет Виста, тогда и говорить будем, а то вдруг Мелкософт скажет, что она опять собралась всю Висту переписывать.
_>ЗЫ Я тут собрался COM изучать, а MS сказала дескать COM атстой юзай .NET _>поэтому теперь ни COM ни .NET я изучать не тороплюсь. Вдруг завтра .NET будет атстой.
Здравствуйте, cod3r_200, Вы писали:
SOL>>Если знать технику, то все нормально получается, ты зря, кстати софт не скачал, там ничего не моргает, над интерфесом очень долго бились там у нас даже диалоги все точь в точь по стандарту. _> А что есть стандарт? если окошки взять как стандарт, то тогда ладно а так — его как такового нету!
Я имел в виду общепринятые правила. По стандарту — просто к слову пришлось. Например 75х23 — имхо стандартный размер кнопки, если вы на ней, конечно, "Войну и Мир" выводить не собираетесь. Или Left = 6, Top = 7 — стандартное положение табконтрола в диалоге и т.д.
Только потому, что Anchors не используешь, попробуй тока начать сайзить контролы на WM_SIZE — сразу все поймешь
Много раз сайзил на WM_SIZE (однажды даже около 20 штук) и все равно ничего не моргает!
А что такое Anchors?
На обед пойду, если не забуду скину линк на статью,где ассемблерщик сравнивает компиляторы, там Borland C++ всех натягивает, правда ассемблерщик говорит, что он все-таки ненадежен, но найдите мне прогу, которая чисто из-за ненадежности компилятора постоянно падает.
Примерно такой ответ я и ожидал увидеть.
Знаешь, гдето здесь обитает любитель оберона, так вот у него он тоже всех натягивает.
Но он по крайней мере прекрасно осознает, что именно он защищает и на все смотрит со своей позиции.
Самое страшное когда у человека нет собственного мнения потому что он не в состоянии сам сравнить
и вынужден приводить доводы типа: "Мне Васька сказал, что Петька круче всех во дворе."
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, ShibaON, Вы писали:
SON>>Вот, как и обещал: Сравнительный анализ компиляторов С++ >>> Intel C++ Compiler 4.5 CC>Он еще древнее найти не мог? CC>Я к тому времени на 7-м сидел.
особенно умиляет год создания статьи 2004 г
Здравствуйте, _wah, Вы писали:
_>Здравствуйте, CreatorCray, Вы писали:
CC>>Здравствуйте, ShibaON, Вы писали:
SON>>>Вот, как и обещал: Сравнительный анализ компиляторов С++ >>>> Intel C++ Compiler 4.5 CC>>Он еще древнее найти не мог? CC>>Я к тому времени на 7-м сидел. _> особенно умиляет год создания статьи 2004 г
Для слепых выделено ЖИРНЫМ
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
M>Алгоритм, примененный в Delphi и C++ Builder, оказался удачным, и его внедрили в последние версии операционной системы Windows под названием LFH (low-fragmentation heap). Теперь программист имеет возможность пользоваться как стандартной кучей, так и кучей с пониженной фрагментацией.
Пользовался LFH. Для multithreaded проги-сервера оказалось монопенисуально.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
SON>>>>Вот, как и обещал: Сравнительный анализ компиляторов С++ >>>>> Intel C++ Compiler 4.5 CC>>>Он еще древнее найти не мог? CC>>>Я к тому времени на 7-м сидел. _>> особенно умиляет год создания статьи 2004 г CC>Для слепых выделено ЖИРНЫМ
Не хочу повторятся, но: А что у Intel C++ Compiler так координально изменилось? Разве его от версии к версии переписывали с нуля?. Это не риторический вопрос, это просто вопрос.
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Здравствуйте, _wah, Вы писали:
_>>Здравствуйте, ArhAngelVezel, Вы писали:
_>>не-а, VS2005 и IDEA — самые скоростные сейчас. AAV>ну не надо говорить о среде. Придержимся того что _стиль_ написания delphi приложений гораздо более подходит под стиль написания "надо было сделать еще вчера". Хотя, у меня знакомые пишут достаточно прогрессивные системы на delphi не используя VCL совсем. Ну любят люди Pascal, что сделать .
Можно конкретные факты, что приложения на делфи писать быстрее, чем на дотнете (2.0, т.к. 1.1. уже становится практически неактуальным, большинство новых проектов начинают на второй версии) или джаве?
или это очередное мнение очередного фаната делфи?
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>На любой. Не будем наивными и примим за факт что машина не может думать лучше людей (с творческой стороны). ....
Здравствуйте, unreg_flex, Вы писали:
_>Здравствуйте, ShibaON, Вы писали:
_>
_>Не хочу повторятся, но: А что у Intel C++ Compiler так координально изменилось? Разве его от версии к версии переписывали с нуля?. Это не риторический вопрос, это просто вопрос.
_>Очень хочется влезть! _>Генерация машинного кода на основе потоковых команд (векторизация циклов) _>Поддержка новых расширений Intel-овских процессоров SSE2 SSE3. _>Оптимизация под несколько процессоров, с возможностью динамического выбора на стадии выполнения. _>Оптимизация под конкретные модели процессоров Up to P4 _>Отложенная кодогенерация на стадии сборки. _>Эмулятор компилируемого кода, для расчета вероятностей выполнения переходов и узких мест на стадии компиляции. (мегафича) _>Упрощение выражений, такого не видел нигде! Например sin(x)/cos(x) заменяются на tan(x)
Рад. А все ли это будет сказываться на моем AMD, а то меня правда заинтересовал ICC.
Здравствуйте, ShibaON, Вы писали:
SON>Здравствуйте, unreg_flex, Вы писали:
_>>Здравствуйте, ShibaON, Вы писали:
_>>
_>>Не хочу повторятся, но: А что у Intel C++ Compiler так координально изменилось? Разве его от версии к версии переписывали с нуля?. Это не риторический вопрос, это просто вопрос.
_>>Очень хочется влезть! _>>Генерация машинного кода на основе потоковых команд (векторизация циклов) _>>Поддержка новых расширений Intel-овских процессоров SSE2 SSE3. _>>Оптимизация под несколько процессоров, с возможностью динамического выбора на стадии выполнения. _>>Оптимизация под конкретные модели процессоров Up to P4 _>>Отложенная кодогенерация на стадии сборки. _>>Эмулятор компилируемого кода, для расчета вероятностей выполнения переходов и узких мест на стадии компиляции. (мегафича) _>>Упрощение выражений, такого не видел нигде! Например sin(x)/cos(x) заменяются на tan(x)
SON>Рад. А все ли это будет сказываться на моем AMD, а то меня правда заинтересовал ICC.
На любом AMD все кроме SSE, SSE2 и SSE3.
SSE Начиная c AMD AtlonXP
SSE2 На следующих прикрутили.
Здравствуйте, ShibaON, Вы писали:
SON>Рад. А все ли это будет сказываться на моем AMD, а то меня правда заинтересовал ICC.
Ну, если у тя не самый древний АМД то:
_>>Генерация машинного кода на основе потоковых команд (векторизация циклов)
будет _>>Поддержка новых расширений Intel-овских процессоров SSE2 SSE3.
Тут спорно: оптимизации часто используют нюансы архитектуры и то, что будет летать на интел процах на других такой производительности может и не покажет _>>Оптимизация под несколько процессоров, с возможностью динамического выбора на стадии выполнения.
будет в большинстве случаев _>>Оптимизация под конкретные модели процессоров Up to P4
ту вопрос. _>>Отложенная кодогенерация на стадии сборки.
будет _>>Эмулятор компилируемого кода, для расчета вероятностей выполнения переходов и узких мест на стадии компиляции. (мегафича)
будет. но эмулировать будет интел архитектуру — потому вопрос. _>>Упрощение выражений, такого не видел нигде! Например sin(x)/cos(x) заменяются на tan(x)
будет
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, unreg_flex, Вы писали:
SON>>Рад. А все ли это будет сказываться на моем AMD, а то меня правда заинтересовал ICC.
_>На любом AMD все кроме SSE, SSE2 и SSE3. _>SSE Начиная c AMD AtlonXP _>SSE2 На следующих прикрутили.
ICC руль
Кстати, скомпиленое им под IA64 будет работать на AMD64?
Здравствуйте, Pyromancer, Вы писали:
P>Здравствуйте, unreg_flex, Вы писали:
SON>>>Рад. А все ли это будет сказываться на моем AMD, а то меня правда заинтересовал ICC.
_>>На любом AMD все кроме SSE, SSE2 и SSE3. _>>SSE Начиная c AMD AtlonXP _>>SSE2 На следующих прикрутили.
P>ICC руль P>Кстати, скомпиленое им под IA64 будет работать на AMD64?
Вроде бы нет. Там набор команд для 64bit чутка отличается
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Pyromancer, Вы писали:
P>>Кстати, скомпиленое им под IA64 будет работать на AMD64? CC>Вроде бы нет. Там набор команд для 64bit чутка отличается
Здравствуйте, Cyberax, Вы писали:
>> P>>Кстати, скомпиленое им под IA64 будет работать на AMD64? C>отличия между EM64 и AMD64 всего в нескольких командах и регистрах.
+1
Невнимательность — порок! это я про себя...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, sndanil, Вы писали:
S>Здравствуйте, ShibaON, Вы писали:
SON>>Мелкософтовцы, кстати кое-что в своем НЕТе позаимствовали у Borland'a, например property.
S>Ну да, а до НЕТа у микрософта проперти нигде не было
S>
SON>>Теперь, что я думаю про Delphi: Delphi это результат многолетних трудов Borland, которая работает всю свою жизнь над компиляторами (в отличие от Майкрософт, которая написала компилатор, только для поддержания своего престижа).
S>Причем не один компилятор . Наверное что бы престижа больше было .
SON>>И компилатор, например С, думаю меня тут поддержат все профессионалы, у Borland гораздо лучше чем у Microsoft.
S>Уж тут тебя врятли кто-то поддержит.
SON>>Теперь сравним VCL с .NET Framework: VCL лет-то уже порядочно, он давно утвердился, а фреймворк — вещь молодая, кто ещё знает что с ней будет. C VCL — плюс 300-800 кб. к вашей проге. Фреймворк — 48 метров к вашему дистрибутиву (притензии типа: "раз установил и все" не принимаются, в VCL тоже так можно: максимум 16 метров в сжатом виде).
S>Где ты увидел 48 метров? S>Здесь черным для белого написано 22.4 MB
Хм, странно, а тут: www.getpaint.net предлагают скачать софтину вместе с дотнетом, и она тяжелее в два раза... Сожет быть это из-за поддержки двух языков ?
SON>Хм, странно, а тут: www.getpaint.net предлагают скачать софтину вместе с дотнетом, и она тяжелее в два раза... Сожет быть это из-за поддержки двух языков ?
не знаю, что ты там нашел. но я с того сайта скачал:
инсталляция PaintDotNet_2_64.exe 3 486 568
Здравствуйте, ShibaON, Вы писали: SON>Хм, странно, а тут: www.getpaint.net предлагают скачать софтину вместе с дотнетом, и она тяжелее в два раза... Сожет быть это из-за поддержки двух языков ?
Да, там явно 2 дистрибутива.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
If you do not have the .NET Framework installed, or if you are not sure, please download the following installer: Paint.NET v2.70 with .NET Framework 2.0 (49.2 MB, English and German)
Здравствуйте, ShibaON, Вы писали:
SON>Здравствуйте, _wah, Вы писали:
SON>Хм, может я туплю ?
SON>
SON>If you do not have the .NET Framework installed, or if you are not sure, please download the following installer: Paint.NET v2.70 with .NET Framework 2.0 (49.2 MB, English and German)
Здравствуйте, cod3r_200, Вы писали:
_>Здравствуйте, ShibaON, Вы писали:
_>[...вырезано...]
_>Спасибо за обширный ответ, даже добавить нечего
SOL>>бывает день сидишь у нужных контролов ON_WM_ERASEBKGND лочишь. _>прям паранойа = )
_> Про дабл буферед знаю конечно, делается оч просто: если графики немного, то просчет рисования в WM_PAINT на "заднем плане", потом битблт. если графики много, хранится картинка в памяти, и никаких просчетов не делается в wm_paint, а сразу битблт. Ну и конечно ws_ClipChildren и ws_Clipblings в с++,мфц. А также еще несколько приемов есть.
SOL>>Если знать технику, то все нормально получается, ты зря, кстати софт не скачал, там ничего не моргает, над интерфесом очень долго бились там у нас даже диалоги все точь в точь по стандарту. _> А что есть стандарт? если окошки взять как стандарт, то тогда ладно а так — его как такового нету!
_>с чем связана безработица у дельфинов? работы как таковой нету по ней. Да и все твердят "с++ для профей". так ли это? я могу хорошую прогу написать и без дельфи, только как мне знакомый сказал — этого никто не оценит.
_> Если интересно, я занимаюсь чатами и всё что с ними связано, знаю все тонкости, опросы тоже не раз проводил, что нехватает юзерам в чатах (всё вместе по этой теме около года). То, чего они хотят, просто нереально сделать на delphi+vcl. Я попытался сделать нечто на дельфе, но это не без глюков получилось, забросил в конце концов. Это так, как конкретный пример.
_> з.ы.: Соседнюю ветку почитал, поорал _>Крах Delphi.
Гасчёт размера загружаемого файла в MS любят врать по-чёрному. Я хотел скачать VS2005 Express, так каждый раз web-installer разный размер выдавал. Всё больше и больше.
Ни коммита без темплейта!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Эх, люблю выпить и переспать с кем нибудь!
Но чаще выходит перепить с кем — нибудь и выспаться...
Здравствуйте, fessa, Вы писали:
F>Здравствуйте, cod3r_200, Вы писали:
_>> Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана.
F>Total Commander, если не ошибаюсь, на ней написан. Такую прогу я бы купил.
Да, на Delphi. А потом сжат экзешник UPX'ом.
Ни коммита без темплейта!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Эх, люблю выпить и переспать с кем нибудь!
Но чаще выходит перепить с кем — нибудь и выспаться...
Здравствуйте, _wah, Вы писали:
_> Можно конкретные факты, что приложения на делфи писать быстрее, чем на дотнете (2.0, т.к. 1.1. уже становится практически неактуальным, большинство новых проектов начинают на второй версии) или джаве? _>или это очередное мнение очередного фаната делфи?
Я думаю, никто не спорит, что на NET писать быстрее. Сегодня NET пришел и вытяснил Delphi, но изначально эта ниша принадлежала именно ей. Когда небыло NET-а, то единственными альтернативани C++су были Delphi и VB — они и использовались, как инструменты быстрой разработки. Чего придераться к словам? (а? фанат .NET)
Здравствуйте, fessa, Вы писали:
F>Здравствуйте, cod3r_200, Вы писали:
_>> Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана.
F>Total Commander, если не ошибаюсь, на ней написан. Такую прогу я бы купил.
В том то и дело, что зависит все не от инструмента — а от того, от куда руки растут.
Здравствуйте, ShibaON, Вы писали:
SON> а время полной компиляции (если удалить все .dcu), обычно, не превышает и половины минуты, а так — секунды четыре.
Гы... Большой проект — это четыре часа компиляции Фортрана с вырубленной на хрен оптимизацией. С оптимизацией никто и не пытался компилять, ибо на фиг не надо.
Здравствуйте, mishin, Вы писали:
M>Среды разработки Delphi и C++ Builder, насколько известно автору, не "доверяют" стандартным функциям управления кучей и реализовали свои.
Вообще-то этот алгоритм выделения памяти появился ещё когда разработчики дельфей под стол пешком ходили. Так что, пожалуйста, не надо вменять им это в заслугу.
Здравствуйте, Whistler, Вы писали:
W>Здравствуйте, _wah, Вы писали:
_>> Можно конкретные факты, что приложения на делфи писать быстрее, чем на дотнете (2.0, т.к. 1.1. уже становится практически неактуальным, большинство новых проектов начинают на второй версии) или джаве? _>>или это очередное мнение очередного фаната делфи?
W>Я думаю, никто не спорит, что на NET писать быстрее. Сегодня NET пришел и вытяснил Delphi, но изначально эта ниша принадлежала именно ей. Когда небыло NET-а, то единственными альтернативани C++су были Delphi и VB — они и использовались, как инструменты быстрой разработки. Чего придераться к словам? (а? фанат .NET)
не выспался?
шеф наорал?
в транспорте с кем-то поругался?
в предыдушем топике автора дураком обозвал,
меня тут в "фанаты" причислил..
IT — эта сфера в которой я зарабатываю себе на жизнь. И фанатизм тут не уместен. Для каждой конкретной задачи нужно подыскать конкретный инструмент (т.е. технологию) без излишнего фанатизма.
Cyberax тебе хорошо написал в сообщение от 22.08.06 00:52 Именно по этим причинам, даже тогда делфи не был ни конкурентом ни альтернативой чему либо.
п.с. мне есть с чем сравнить. Писал и на билдере, писал и на делфях, на vc++, теперь на дотнете. И кстати. переход в своё время моей фирмы с борландовских продуктов на vc++ был как раз обусловлен теми причинами, что описал Cyberax
Здравствуйте, Pyromancer, Вы писали:
P>Потому что машинный видимо
Хорошая шутка
P>Хотя конечто если взять например MASM версии хотя бы 5 и от души попользоваться всякими нехарактерными для нормального ассмеблера наворотами тогда то, что скомпилится, может оказаться не совсем тем, что хотелось
Главное при оптимизации кода — не изменить результат его работы
Здравствуйте, Cyberax, Вы писали:
C>Whistler wrote: >> а) Visual C++ — 2 месяца работы двух программистов, лабающих на MFC + >> WinAPI и требующих зарплаты $1.6к (только потому, что они нефиговые >> C++-программеры, а не какие-то делфисты тупые). Бюджет: 1.6 * 2 мес * 2 >> чел = $6400 >> б) Delphi 7 — 2 недели одного Delphi-программиста (просто потому, что в >> делфи уже на базе VCL сужествует огромная куча функциональности привязки >> к данным, формирования отчетов и т.д.) с окладом $800 (потому, что >> квалификации программистов для данной задачи достаточно, чтобы знать >> только VCL + на базовом уровне SQL). Бюджет: $400. C>Развиваем идею. Приложение понравилось, в него решили добавить новые C>функции. Но в дельфяном приложении все построено на прямом биндинге C>полей к результатам запроса (а как же — надо чтобы все было быстро C>разработано), а в MFCшном приложении сделана объектная модель и выделен C>слой работы с БД.
C>Поэтому MFCшники очень быстро прикручивают новую фичу, а дельфинисты C>каждый раз перекурочивают половину форм. Причем получают в итоге C>глючащее приложение из-за того, что постоянно забывают поправить C>какой-то запрос.
C>Я лично такую ситуацию наблюдал не один раз. С помощью Дельфи/VB можно C>очень быстро сделать начальное приложение, но вот потом поддерживать его C>очень сложно.
C>Естественно, можно сразу писать на Дельфи красиво и нормально. Вот C>только все магические улучшения производительности программиста куда-то C>пропадут.
Если перелопачивать половину форм — это не фича а коренная переделка при изначально неверном проектировании. И здесь в MFC будет такая же ж.... Ибо когда неправильно спроектирована объектная модель проблем не меньше это точно. Если изначально грамотно спроектировать приложение, то будь оно на C++ и ли на дельфи добавлять новый функционал будет легко и приятно.
p.s. Слой работы с БД не есть особенность MFC, при необходимости его можно прикрутить куда угодно.
Здравствуйте, Cyberax, Вы писали:
C>Коваленко Дмитрий wrote: >> Я, к примеру, использую компилятор от BCB5 для контроля компилятора VC8. C>А вы, случайно, не используете IBM XT для контроля качества генерации C>кода для Core 2 Duo?
Нет, для него я использую двухпроцессорный антиквариат на базе PII-450
Я понимаю ваши издевательства над BCB5. Я сам люблю над ним измываться.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, Cyberax, Вы писали:
C>>Коваленко Дмитрий wrote: >>> Я, к примеру, использую компилятор от BCB5 для контроля компилятора VC8. C>>А вы, случайно, не используете IBM XT для контроля качества генерации C>>кода для Core 2 Duo?
КД>Нет, для него я использую двухпроцессорный антиквариат на базе PII-450
КД>Я понимаю ваши издевательства над BCB5. Я сам люблю над ним измываться.
Не надо издеваться над средами разработки. Если уж так приспичило, то уж над программистами что не умеют в них работать
Здравствуйте, alex_kostylev, Вы писали:
>>>> Я, к примеру, использую компилятор от BCB5 для контроля компилятора VC8. C>>>А вы, случайно, не используете IBM XT для контроля качества генерации C>>>кода для Core 2 Duo?
КД>>Нет, для него я использую двухпроцессорный антиквариат на базе PII-450
КД>>Я понимаю ваши издевательства над BCB5. Я сам люблю над ним измываться.
_>Не надо издеваться над средами разработки. Если уж так приспичило, то уж над программистами что не умеют в них работать
Если вы намекаете, что это у меня проблемы с билдером — то сильно заблуждаетесь. Я его фанат . Потому что
— А. Сопровождаю достаточно большой комплекс, написанный с его использованием. При это я еще и более чем участвовал в его создании.
— Б. Создал приличную подборку багов его компиляторов и STL.
По поводу А. мне борланд вообще должен был поставить памятник . Потому что я вопреки всему и всем довел этот проект до запуска, оставаясь на BCB3 (обожаю баги этого компилятора — круче него только BCB1 на голом NT4). Что, в прочем, на текущий момент, говорит только о количестве дури в моей голове, которой хватило бы минимум на десяток программистов
Как говорил один парень из релекса (в котором пишут линтер) — под NT и дурак напишет RDBMS, вы попробуйте аналогчное под DOS написать. То самое я могу сказать и про промышленное программирование на С++ с ипользованием VC8 и BCB
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Если вы намекаете, что это у меня проблемы с билдером — то сильно заблуждаетесь. Я его фанат . Потому что КД>- А. Сопровождаю достаточно большой комплекс, написанный с его использованием. При это я еще и более чем участвовал в его создании. КД>- Б. Создал приличную подборку багов его компиляторов и STL.
Это тем не менее не оправдывает забагованность данного компилера. Как был глюкаловом так и остался...
КД>По поводу А. мне борланд вообще должен был поставить памятник . Потому что я вопреки всему и всем довел этот проект до запуска, оставаясь на BCB3 (обожаю баги этого компилятора — круче него только BCB1 на голом NT4).
Да вы батенька — мазохист-хардкоршик
КД> Что, в прочем, на текущий момент, говорит только о количестве дури в моей голове, которой хватило бы минимум на десяток программистов
+1
КД>Как говорил один парень из релекса (в котором пишут линтер) — под NT и дурак напишет RDBMS, вы попробуйте аналогчное под DOS написать.
А можно вместо лексуса ездить на прогнившем запорожце, заводясь с толкача и глохнуть на каждом светофоре.
СМЫСЛ!?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
КД>>Как говорил один парень из релекса (в котором пишут линтер) — под NT и дурак напишет RDBMS, вы попробуйте аналогчное под DOS написать. CC>А можно вместо лексуса ездить на прогнившем запорожце, заводясь с толкача и глохнуть на каждом светофоре.
CC>СМЫСЛ!?
Билдер может давать некоторые предупреждения, которые не может дать VC8 (3-уровень). На четвертом может там все ок, признаюсь честно — не вникал.
Плюс у него есть заскоки, которые мне и билдеру не нравятся
И наконец, VC8 не идеален (я писал на форумах RSDN о выявленных проблемах) — хотя, не спорю, очень качественный компилятор. На текущий момент — я ему продался с потрохами
Я бы еще на третьем компиляторе прогонял код, например на интеле, но времени нет. Его всегда нет
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>И наконец, VC8 не идеален (я писал на форумах RSDN о выявленных проблемах) — хотя, не спорю, очень качественный компилятор. На текущий момент — я ему продался с потрохами
КД>Я бы еще на третьем компиляторе прогонял код, например на интеле, но времени нет. Его всегда нет
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Билдер может давать некоторые предупреждения, которые не может дать VC8 (3-уровень). На четвертом может там все ок, признаюсь честно — не вникал.
Например? Честно гря трудно представить... КД>И наконец, VC8 не идеален (я писал на форумах RSDN о выявленных проблемах) КД>Я бы еще на третьем компиляторе прогонял код, например на интеле, но времени нет. Его всегда нет
Дык переходи полностью на тот же интел
КД>не спорю, очень качественный компилятор.
ну, ИМХО не очень уж и качественный. Просто хороший — да.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
КД>>Билдер может давать некоторые предупреждения, которые не может дать VC8 (3-уровень). На четвертом может там все ок, признаюсь честно — не вникал. CC>Например? Честно гря трудно представить...
— Неиспользуемые параметры методов. VC иногда предупреждает, иногда нет
— Переменной присвоено значение, но оно не было использовано.
Может я вру, но по-моему мне это не приснилось.
КД>>И наконец, VC8 не идеален (я писал на форумах RSDN о выявленных проблемах) КД>>Я бы еще на третьем компиляторе прогонял код, например на интеле, но времени нет. Его всегда нет CC>Дык переходи полностью на тот же интел
Ты бы посмотрел на мою ленивую морду Я на студию перешел из-за лени
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>В чем-то лучше, в чем-то хуже.
Вот в этой части и все проблемы.
Дело именно не в языке (C или Pascal), а в среде. Сам я пишу на Delphi и могу отметить два радикальных момента, мешающих использовать VCL (да и CLX) во множестве проектов.
1. Вся работа с экраном идёт в одном потоке (исключая, правда MDI).
2. Юникод VCL не любит (но хотя бы CLX с ним дружит). Особенно паскудно это ощущать при написании dll и сервисов. Здесь CLX уже не поможет.
Проблема России не в том, что она не может накормить бедных, а в том, что богатые никак не нажрутся
Здравствуйте, siberia2, Вы писали:
S>Дело именно не в языке (C или Pascal), а в среде. Сам я пишу на Delphi и могу отметить два радикальных момента, мешающих использовать VCL (да и CLX) во множестве проектов. S>1. Вся работа с экраном идёт в одном потоке (исключая, правда MDI).
А причем здесь Delphi? Это же вроде ограничение win32.
Здравствуйте, Lloyd, Вы писали:
S>>Дело именно не в языке (C или Pascal), а в среде. Сам я пишу на Delphi и могу отметить два радикальных момента, мешающих использовать VCL (да и CLX) во множестве проектов. S>>1. Вся работа с экраном идёт в одном потоке (исключая, правда MDI).
L>А причем здесь Delphi? Это же вроде ограничение win32.
Я про такие ограничения в NT и далее ещё не слышал.
Проблема России не в том, что она не может накормить бедных, а в том, что богатые никак не нажрутся
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, siberia2, Вы писали:
L>>>А причем здесь Delphi? Это же вроде ограничение win32.
S>>Я про такие ограничения в NT и далее ещё не слышал.
L>Вроде как с окном можно работать только в том потоке, который его создал.
Если сможете переслать сообщения из другого потока, то сможете рулить любым окном
Здравствуйте, Lloyd, Вы писали:
L>>>А причем здесь Delphi? Это же вроде ограничение win32.
S>>Я про такие ограничения в NT и далее ещё не слышал.
L>Вроде как с окном можно работать только в том потоке, который его создал.
Вовсе нет. Но в VCL речь об этом не идёт — все окна работают в одном потоке.
Проблема России не в том, что она не может накормить бедных, а в том, что богатые никак не нажрутся
Здравствуйте, siberia2, Вы писали:
L>>Вроде как с окном можно работать только в том потоке, который его создал.
S>Вовсе нет. Но в VCL речь об этом не идёт — все окна работают в одном потоке.
SON>Если знать технику, то все нормально получается, ты зря, кстати софт не скачал, там ничего не моргает, над интерфесом очень долго бились там у нас даже диалоги все точь в точь по стандарту. Про моргание, мне что нравится в VCL, там у каждого контрола, который представляет собой окно, есть свойство DoubleBuffered, если его поставить в тру, то моргать он уже никогда не будет, а еще инетерсней его реализация, я когда посмотрел в исходниках, у себя в проге на MFC такое же замутил, переписал большинство контролов, чтобы у них тоже было свойство DoubleBuffered. А по поводу гор кода, это было бы страшно, если бы этот код был не ООП, а если следовать ООП, то по идее глюков должно быть меньше. Очень часто, у начинающих кодеров на Delphi есть одна глобальная (так сказать extern) проблема: не понимание ООП, из за этого, часто случаются косяки, потому что VCL рассчитана прежде всего на ООП, SON> пример ламаковского кода: SON> ... SON> ShowInformationBoxInCenter(Form1, 'Message'); SON> ... SON> пример правильного кода: SON> ... SON> ShowInformationBoxInCenter(self, 'Message'); SON> ...
t.e. po vashemu OOP zakluchaetsya v upotreblenii "self"? Vot kak delphi uchit "chto takoe OOP?"
Nastoyaschiy OOPshnik sdelal bi ShowInformationBoxInCenter virtualnim methodom obschego predka vseh svoih "form" proekta i napisal bii
ShowInformationBoxInCenter('Message');
Voobsche osnovnaya beta etih delphey — chto OOP fakticheski tam predstavleno tolko tem chto VCL razbita na classi. "Programmeri" na delphi schitaut chto OOP — eto kogda u tebya v nazvanii funkcii est simvol '.' A chto takoe i zachem nado polimorphizm, nasledovanie, virtualnie methodi etc. oni daavno zabili po sdache v VUZe zacheta/examena po programmuhe..
Samie prodvinutie delphyatniki kotorie ya vstrechal dazhe ponyali chto exzemplyarov TForm2 mozhet bit v programme srazu mnogo... No ya esche ne videl ni odnogo "korennogo" delphyatnika (ludey kotorie odinakovo horosho pishut na delphi/C++/Java proshu ne bespokoitsya ) kto dodumalsya hotyabi otnasledovatsya ot TForm, sdelat chtoto tipa TAnyDocumentForm, a ot nee otnasledovat TBmpDocumentForm, TTextDocumentForm a ot TTextDocumentForm — THtmlDocumentForm i vse eto zauzat v svoem kode, v kotorom netu ni odnogo upominanya o TBmpDocumentForm, TTextDocumentForm i THtmlDocumentForm, — a core logica rabotaet tolko s objectami tipa TAnyDocumentForm. A tomo cherez polgoda chtobi mona bilo bistro sest i otnasledovat ot TBmpDocumentForm kakoy nit TGifDocumentForm, napisat 1 "unit", ne trogaya ostalnogo koda i dobavit v progu novy funkcional. I estestvenno bez primenenia copy-paste... Obichny delhyatnik, schitauschy za OOP funkcii tipa OnButton1Click skazhet — "eto ideal i nedostizhimo", a ved takoy podhod, imya kotoromu OOP, vpolne uspeshno primenyaetsa na praktike. Prosto Delphi iznachalno priuchivaet k kakoy-to ubogo-izvraschennoy forme OOP. Nemnogie nahodyat v sebe sily vzglyanut dalshe etogo, bolshinstvo tak i prodolzhaut cherez copy-paste copirovat procedury renderinga kartinki iz svoey TBmpForm v TGifForm...
Здравствуйте, ДимДимыч, Вы писали:
S>>в VCL — все окна работают в одном потоке.
ДД>В VCL, насколько помню, есть класс TThread. Ничто не мешает с его помощью разделить потоки обработки GUI-сообщений и функционал приложения.
Но GUI весь будет работать в одном потоке.
Проблема России не в том, что она не может накормить бедных, а в том, что богатые никак не нажрутся
Dopolnu skazannoe vishe.
delphi predstavlyaet soboy etakuu smes buldoga s nosorogom: sama VCL napisana s dovolno gramotnim sobludeniem paradigmi OOP, hotya i v ney est lyapi v etom otnoshenii, no architecturno VCL gorazdo pravilnee uzaet OOP chem naprimer MFC (uzhas esche tot), no QT naprimer v etom otnoshenii delaet VCL. U VCL est drugaya problema — tormoznaya ona, v chem i uprekaut obichno delphyatnikov. No tormoznaya i pravilnaya VCL eto ne est beda Delphi. Osnovnaya beda v tom chto IDE delphi nastoychivo tolkaet programmista uzat FP paradigmu pri programmirovanii. Vot i poluchaetsa chto kod napisanniy tipichnim Delphi programmerom — eto FP-style kod uzauschiy objecty predostavlyaemie VCL, samoy po sebe napisannoy v otnositelno normalnom OOP stile. Etim i objyasnaetsa prostota delphi dlya nachinauschih — posle izuchenia v shkole tipichno funkcionalnogo podhoda legko perekluchitsya na delphi, ibo podhod tam po suti tozhe funkcionalny. No uzanie OOP-style bibliouteki kak VCL vovse ne oznachaet togo chto _vash_ kod napisan v paradigme OOP. Beda IDE opyat zhe ne v tom chto ona silno prostaya,- on-click components drops, events handlers generator etc — eto vse ochen horosho. Beda v tom chto vse etot avtomaticheski sgenerenniy kod na samom dele skoree FP nezheli OOP.
Za primerami daleko hodit ne nado: berem formu, kidaem na nee button, doubleclick'aem na etot button, poluchaem chtoto tipa:
TMainForm.ButtonHelloClick(Sender: TObject)
begin
end;
Pishem mezhdu begin i end ShowMessage('Hello'); i raduemsya. Vse ok. NO! Eto ved pryamoe narushenie paradigmi OOP! Pochemu eto pri clicke na object TButton u menya avtomaticheski vipolnyaetsa method TForm?? Vot i poluchaetsya — chto kod napisanniy programmerom v delphi pronizan logikoy mezhdu _raznimi_ logicheskimi unitami-objectami, chego bit _ne_dolzhno_ po osnovnoy paradigme OOP. Kak po drugomu? Posmotrite naprimer kak eto delaetsya by default v Java.
Vozvraschayas c subju v tekuschem contexte C++ — sam po sebe yazik vesma neprihotlivy, chem i objasnyaetsa ego populyarnost i dolgozhivuchest'. Tipichnie Delphyatniki perehodya na C++ prodolzhaut kodit' v privichnom dlya sebya FP stile, Java programmeri generyat kod perenagruzhenniy ispolzovaniem OOP — slishkom mnogo svyazey po nasledovaniyu tozhe ne est good. Delphisti kstati vidya kod napisanniy javistami nifiga v nem ne ponimaut . A javisti vidya kod napisanniy dekphistami figeut ot skvozyaschego v nem FP. I both delphisty i javisty figeut ot koda napisannogo true-Cpp'shnikami, napisannogo s uzaniem templatov, multiple inheritance etc I lish true Cpp'shniki svisoka smotray na kod bivshih delphistov i javistov, predstavlyauschiy dve kraynosti — pure FP & pure OOP
PS Vobschem vsem delphistam rekomenduu izuchit java. I ne na urovne hello worl, a poizuchat stil koda realnih proekov. Chisto dlya sebya hotyabi.
PPS sorry, nabolelo :/
CC>Слуш, найди транслитератор а... А то мне например твою писанину читать тоже "наболело"
gm sorry no na poisk "transliterator" mne predlagaut chegoto skachat i postavit. Eslib ya mog chegoto postavit na etoy machine mne bi ne bil bi nuzhet transliterator.
Ni odna iz etih linok tozhe ne pomogla: http://www.mashke.org/Conv/ http://www.cifirica.ru/cifirica.php http://www.privet.com/decoder — eto vrode to... no ne rabotaet applet.
Здравствуйте, apple-v-otpuske, Вы писали:
CC>>Слуш, найди транслитератор а... А то мне например твою писанину читать тоже "наболело" AVO>gm sorry no na poisk "transliterator" mne predlagaut chegoto skachat i postavit. Eslib ya mog chegoto postavit na etoy machine mne bi ne bil bi nuzhet transliterator.
re-translitted (ne mogu ispravit.. ibo net russkogo :
Дополну сказанное висхе.
делпхи представлыает собоы етакуу смес булдога с носорогом: сама ВCЛ написана с доволно грамотним соблудением парадигми ООП, хотыа и в неы ест лыапи в етом относхении, но арчитеcтурно ВCЛ гораздо правилнее узает ООП чем например МФC (ужас есче тот), но QТ например в етом относхении делает ВCЛ. У ВCЛ ест другаыа проблема — тормознаыа она, в чем и упрекаут обично делпхыатников. Но тормознаыа и правилнаыа ВCЛ ето не ест беда Делпхи. Основнаыа беда в том что ИДЕ делпхи настоычиво толкает программиста узат ФП парадигму при программировании. Вот и получаетса что код написанниы типичним Делпхи программером — ето ФП-стыле код узаусчиы обйеcты предоставлыаемие ВCЛ, самоы по себе написанноы в относително нормалном ООП стиле. Етим и обйыаснаетса простота делпхи длыа начинаусчих — после изучениа в схколе типично функcионалного подхода легко переклучитсыа на делпхи, ибо подход там по сути тоже функcионалны. Но узание ООП-стыле библиоутеки как ВCЛ вовсе не означает того что _васх_ код написан в парадигме ООП. Беда ИДЕ опыат же не в том что она силно простаыа,- он-cлиcк cомпонентс дропс, евентс хандлерс генератор етc — ето все очен хоросхо. Беда в том что все етот автоматически сгенеренниы код на самом деле скорее ФП нежели ООП.
За примерами далеко ходит не надо: берем форму, кидаем на нее буттон, доублеcлиcкьаем на етот буттон, получаем чтото типа:
ТМаинФорм.БуттонХеллоCлиcк(Сендер: ТОбйеcт)
бегин
енд;
Писхем между бегин и енд СховМессаге(ьХеллоь); и радуемсыа. Все ок. НО! Ето вед прыамое нарусхение парадигми ООП! Почему ето при cлиcке на обйеcт ТБуттон у меныа автоматически виполныаетса метход ТФорм?? Вот и получаетсыа — что код написанниы программером в делпхи пронизан логикоы между _разними_ логическими унитами-обйеcтами, чего бит _не_должно_ по основноы парадигме ООП. Как по другому? Посмотрите например как ето делаетсыа бы дефаулт в Йава.
Возврасчаыас c субю в текусчем cонтеxте C++ — сам по себе ыазик весма неприхотливы, чем и обйасныаетса его популыарност и долгоживучесть. Типичние Делпхыатники переходыа на C++ продолжаут кодить в привичном длыа себыа ФП стиле, Йава программери генерыат код перенагруженниы исползованием ООП — слисхком много свыазеы по наследованиыу тоже не ест гоод. Делпхисти кстати видыа код написанниы йавистами нифига в нем не понимаут . A йависти видыа код написанниы декпхистами фигеут от сквозыасчего в нем ФП. И ботх делпхисты и йависты фигеут от кода написанного труе-Cппьсхниками, написанного с узанием темплатов, мултипле инхеританcе етc И лисх труе Cппьсхники свисока смотраы на код бивсхих делпхистов и йавистов, представлыаусчиы две краыности — пуре ФП & пуре ООП
ПС Вобсчем всем делпхистам рекомендуу изучит йава. И не на уровне хелло ворл, а поизучат стил кода реалних проеков. Cхисто длыа себыа хотыаби.
ППС сорры, наболело :/
apple-v-otpuske wrote: > delphi predstavlyaet soboy etakuu smes buldoga s nosorogom: sama VCL > napisana s dovolno gramotnim sobludeniem paradigmi OOP, hotya i v ney > est lyapi v etom otnoshenii, no architecturno VCL gorazdo pravilnee > uzaet OOP chem naprimer MFC (uzhas esche tot), no QT naprimer v etom > otnoshenii delaet VCL.
А их всех делает Swing — там везде используется MVC.
AndrewVK wrote: > C>А их всех делает Swing — там везде используется MVC. > А Swing делает WPF, потому что там разделение аспектов лучше
Нет, это уже более высокий уровень — так что сравнивать не совсем корректно.
Здравствуйте, Cyberax, Вы писали:
>> А Swing делает WPF, потому что там разделение аспектов лучше C>Нет, это уже более высокий уровень — так что сравнивать не совсем корректно.
С чего это он более высокий? Тот же самый MVC, только называется по другому.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, ShibaON, Вы писали:
SON>Я ни разу не сталкивался с багами компилеров Borland's. Ни разу! Где они? Покажите мне их? Некорректная работа на всяких там {{{{{{{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}}}}}}} — это не довод!
А вот я постоянно сталкивался когда на багланде писал... интересно почему?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, siberia2, Вы писали:
S>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>В чем-то лучше, в чем-то хуже.
S>Вот в этой части и все проблемы. S>Дело именно не в языке (C или Pascal), а в среде. Сам я пишу на Delphi и могу отметить два радикальных момента, мешающих использовать VCL (да и CLX) во множестве проектов. S>1. Вся работа с экраном идёт в одном потоке (исключая, правда MDI).
А зачем тебе это?
S>2. Юникод VCL не любит (но хотя бы CLX с ним дружит). Особенно паскудно это ощущать при написании dll и сервисов. Здесь CLX уже не поможет.
есть tntControls..
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана. _>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу
Прямые руки вам в помощь.
И забудьте про свой MFC.
. Этаких ламаков очень много и прог у них очень много, из-за этого у всех складывается ощущение, что Delphi — это ламаковская фигня, и те кто пишут на Delphi тоже ламаки. Из-за этого я не люблю уже не Delphi, а этих ламаков 
В java полно сторонних фреймворков (Spring, Hibernate) и библиотек (от Apache.org), которые используются в промышленном коде и по BSD-like лицензиям. Я уж не говорю, о том, что многие из них портированы на .Net с приставкой N 
, почему-то никто не верит, а самому брать дизассамблер и делать тесты — у меня времени нет, да и зачем мне это нужно, меня-то ведь все устраивает. Здесь я не собираюсь навязывать свое мнение, здесь я просто им делюсь с остальными, внимательно выслушивая других. А что касается моего, конкретно, мнения про все это дело, то я за тот небольшой промежуток времени, с которого здесь зарегился, уже несколько раз высказал свое мнение "обо всем об этом": Для каждой задачи свой инструмент. Гаму, например на D3D на Delphi только пароноик писать начнет, зато небольшую офисную прогу на Delphi я сделаю гораздо быстрее, чем на MFC, но такого удовольствия, как от C++ я не получу никокда ни от какого языка программирования. И споры между кодерами на Delphi и С++ напоминают мне студенческие годы. Давайте просто говорить о достоинствах и недостатках, а не о том, что Delphi — это шит (если это шит, почему его тогда покупают, кучу книг о нем пишут?). Нет ничего идеального, правда нет, тут-то я точно сам все проверил и сравнил и идеального не нашел!
, ну вот так. 
, VCL по многим показателям гораздо лучше .NET Framework
1.1.4 stable rev. 510
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
