> Компилятор у Борланда хорош, пожалуй только поддержкой стандартов.
> Говорят, что:
> 1)По качеству оптимизации он уступает Микрософтовому.
> 2)Те, кто видел, ЧТО за код он генерит, матерят его.

А кому нужны +/- 5% производительности на практике?

> По поводу VC++. Ну наверное Вы не прониклись тем, что от Вас хотят
> создатели MFC. Конечно, библиотека MFC немного постарше VCL, она
> наверное годится в ровесники OWL. Но, ее архитектура, IMHO
> намного достойнее VCL...

IMHO у них просто идеология разная - MFC если "объектно-ориентированная", как бы, то VCL - "компонентно-ориентированная", опять же, как бы ;)
Потом, по функциональности VCL=MFC+ADO+...

Диментий. mailto:dimentiy@mail.ru

На практике небольшое отставание в производительности может вылезти в очень большое торможение.Например, если тормозным оказался частовыполняемый участок кода. Также 5% торможение мягко говоря нежелательно при написании ядра операционной системы и прочих time-critical штучек (вроде ядер эмуляции прцессоров). Я конечно понимаю, что C++ - не C, который "переносимый ассемблер", и он предназначен совсем для других вещей (IMO он предназначен только для GUI и ни для чего больше), но я не хочу никаких компромиссов когда речь идет о моих программах. Что касается качества генерации кода, то у Borland оно традиционно плохое. Советую где-нибудь найти небольшую тестовую программу для C-компиляторов и затем посмотреть на ассемблерный листинг...

Что-то вы все братцы говорите, что ядра на С++ не пишутся. А как же тогда BеOS. Или я неверно осведомлен?

languages

Боже мой... Ядра на C++, гуйня на C... Я фигею, дорогая редакция... <p>Да, народ, просветите меня немного насчёт Delphi. Когда-то, очень давно, когда я ещё учился в школе (6-10 классы), Pascal was my favourite language. Тогда это был небезызвестный Трубо Паскакаль, из OOP samples к версии 5.5 которого вырос сначала Turbo Vision, а затем, видимо, VCL (рылся как-то в сырцах последнего и отметил некоторое сходство ;) Позже я перешёл на C/C++ и обратно возвращаться не собираюсь, но тем не менее кое-что про дельфю хотелось бы узнать, а ставить её ради этого влом. А именно, поддерживаются ли там <p> <li>перегрузка функций и *операторов*</li> <li>templates</li> <li>конструкторы для копирования/преобразования типов</li> <li>множественное наследование</li> <li>и тому подобные приятные штуки...</li> <p>Или всё, что там нового - механизм properties??? Вопрос в том, возможно ли на Delphi сделать, например, библиотеку для автоматического дифференцирования и interval arithmetics.

languages

Здешний HTML(limited) appears to be broken. Повторяю попытку.

Боже мой... Ядра на C++, гуйня на C... Я фигею, дорогая редакция...

Да, народ, просветите меня немного насчёт Delphi. Когда-то, очень
давно, когда я ещё учился в школе (6-10 классы), Pascal was my
favourite language. Тогда это был небезызвестный Трубо Паскакаль,
из OOP samples к версии 5.5 которого вырос сначала Turbo Vision,
а затем, видимо, VCL (рылся как-то в сырцах последнего и отметил
некоторое сходство ;) Позже я перешёл на C/C++ и обратно возвращаться не собираюсь, но тем не менее кое-что про дельфю
хотелось бы узнать, а ставить её ради этого влом. А именно,
поддерживаются ли там

- перегрузка функций и *операторов*
- templates
- конструкторы для копирования/преобразования типов
- множественное наследование
- и тому подобные приятные штуки...

Или всё, что там нового - механизм properties??? Вопрос в том,
возможно ли на Delphi сделать, например, библиотеку для автоматического дифференцирования и interval arithmetics.

Последние версии вроде умеют операторы перегружать.
Пытаются из него С++ сделать :)

Где-то я слышал, что американские школьники изучают программирование на Delphi. Вот это - правильно, IMO Паскаль для этого прекрасно подходит (убил бы того урода, который придумал использовать Васик в качестве языка для обучения... Тот кто не слазит с него вовремя, становится морально покалеченным на всю жизнь)

Kylix vs Java

Думается скоро Java вытеснит всякие Delphi/Kylix, и правильно

Нету у меня Kylix на презентации Borland его мучал

Спорить тоже не стоит преимущества и недостатки у всего есть так что если кто скучает по C++ можно использовать C++ Builder там вам и C++ и VCL

MFC безнадёжно устарела

RONA

Докажи, плиз.
С моей точки зрения у MFC всетаки дизайн получше и разобраться в ней проще.
В ней большинство методов умещаются на один экран. А смотришь в VCL - видишь
сплошной Паскаль (ничего против него не имею, но это не мой язык), причем километровой длины.

P.S. я VCL и MFC юзаю достаточно плотно (сейчас больше MFC), так что я могу быть беспристрастным

...и все-таки, MFC устарела. Именно в плане С++ библиотеки. Скорее всего, и из за нее тоже Microsoft не спешит приводить свой компилятор в соответствие со стандартом. C Havoc я согласен -- доступные дизайн и идеология это немаловажные вещи. И действительно, когда видишь очень ДЛИННЫЕ функции это, по-меньшей мере, настораживает.

VCL vs MFC

ноги, крылья... Главное - хвост! :) И MFC, и VCL, строго говоря, по сравнению с Qt "гроша выеденного" не стоят. Если бы Qt для Win32 не стоил $1500+, то давно бы их вытеснил. Я думаю не просто так Тролли цену на него уже много лет не снижают, и при этом, как будто, не бедствуют. Вот если бы Borland не страдал фигнёй, а сделал бы билдер который бы напрямую с Qt работал, а не через VCL - было бы рульно... Но пока виндовская версия труднодоступна, такому, наверное, не бывать :( А так - properties там есть, пожалуйста, может быть нет встроенного механизма хранения форм - да что от него особо толку, намного ли хуже генерение лишних .h & .cpp ? OK, всё это, конечно, apart from the fact that в Билдере и Дельфях есть data-aware components и тому подобные приятности. Но ничего, вот опубликуют они свой CLX под LGPL - портируем что нужно из-под ихнего кривого компилера под gcc ;) Оно, правда, может оказаться на Паскале, но это тоже решабельно ;)

pascal - дерьмо

Я где-то слышал, что государственным организациям США запрещалось (и может до сих пор запрещается) покупать софт написанный на паскале. Надеюсь, на delphi это распространяется.
И еще о паскале: афоризм: "паскаль создан чтобы учить людей программировать. С и С++ созданы чтобы программировать".

2ivan4th: Назови мне более-менее серьезный софт под винду, писанный на Qt.
Qt задрала, когда версия чуть не такая, часто код приходится руками править.

Зато сам Visual C копеечный... Глянул на сайте M$, цена за Enterprise-комплектацию $1399, за Professional - около $600. Да что там C, такие же точно цены на Visual Basic! Я понимаю, здесь все такие честные и богатые, они купят, но остальным-то что делать остается? :) Либо воровать, либо покупать Builder/Delphi, они на порядок дешевле.

Цены цены, цена сама по себе ни о чём не говорит важно соотношение функциональности к цене... В MFC маленкие методы потому что это по определению тонкая оболочка поверх Win32 API. В результате методы людей которые под неё пишут большие. Окромя этого MFC это: Колекции и строки - котрые STL лучше реализует Поддержка OLE - котрую ATL лучше реализует Поддержка GUI - которая практически ничего не даёт поверх API Document View - которая ни к селу ни к городу не MVC + Вспомогательные классы - против этих особо ничего не имею кроме того что они особо исключения не испольуют Очевидно MFC больше развиваться не будет ибо Microsoft переходит на Common Language Run-time и WinForms/WebForms RONA

Кстати, для граждан США Visual Studio (включая VB, VC, VFP, VJ++) стоит $50 (но по-моему только если они обязются не продавать сделанный с помощью этого софт - то есть скрипты и утилиты для себя чтоб писать - но что есть такое условие я точно не помню, то что за $50 можно купить это я точно помню). Уточняйте кому хочется, при каком условии (кроме гражданства США) можно купить VS за $50. А по мне - чем выше абстракция, тем круче. По сему все MFC которые пахнут win32 API отпадают (они либо специально такие win32-ориентед чтобы код был непортабельный либо авторы хотели как можно тоньше прослоку сделать), да и VCL тоже особо не лезет в это определение (нет layot managers). Если есть возможность, нужно юзать скриптовые языки. И похрену на размер кода/рантайма - вы же не для embedded environments пишите - ваше время и продуктивность превыше всего (если вы конечно не игрушки пишете).

Зато MFC - это C++
А VCL что? Прогу, написанную на билдере, никуда больше не перенесешь.
Ну нету в C++ слова property. С другой стороны MFC поддерживают и другие
компиляторы, в том числе и Билдер.

Пипл, я читаю дискуссию и тихо фигею. Люди считают MFC не то, что приемлимой, даже хорошей. Все приплыли, вот до чего дельфи довели. ГУЯ мне приходилось писать много и на разных платформах, так вот, MFC и OWL - это худшее, что мне приходилось хоть когда-нибудь видеть. Они не просто плохи, они никакие. Такое впечатление, что их писал тот, кто впервые увидел C++ и узнал странные слова oop (до ooa/d там вообще не дошло :) ) Это не пустые слова. Тот, кто работали с PowerPlant, должен понять. Небо и земля. И вообще, C++ слабо подходит для гуя, даже статейки по этому поводу пробегали где-то. Например, из-за strong статической типизации, что делает обработку сообщений мягко говоря сложной. Кроме того, порядок конструирования классов и виджетов различается, что приводит к хакам типа TWindow::SetupWindow() (эт из OWL). Толи дело динамические языки: Smalltalk(а еще лучше Squeak), TCL/Tk, Scheme (STk - вообще рулит), CL. Набросать прототип более-менее сложного диалога на TCL/Tk дело 10-15 мин. Причем такие фитчи, как layout management, о котором в мире Wintel не очень-то и слышали, приводит к более быстрому и качественному результату.

Не трожьте Kylix !

Раз дают, так возьмем!

Нечего на Kylix гнать. Ламо как было так и будет, а дополнительное средство разработки под Linux никогда не помешает.

Например стоит задача по миграции факультета информационых технологий под Linux. Получается, что все за (деканат, професора, студенты :}), а дружественых сред (для начинающих програмистов) не хватает, а то студенты, выращеные под виндой, просто в обморок падают от VI. В текстовом режиме еще как-то обошлись RHide, но под Х просто завал.

Так что после выхода Kylix, можно будет полностью перейти под нормальную систему, причем соблюдая все правовые рамки, и вырастить действительно професиональных программистов под Unix.

Думаю сие действие сделает заметный шаг в продвижении общей идеи свободного ПО.

О том, что MFC - _ГУЕВАЯ_ библиотека никто и не говорит. Но, хорошим каркасом любого Win32 приложения она была достаточно долгое время. Сейчас все на нее стали смотреть как на анахронизм, но реальной альтернативы скажем лет 4-5 назад у нее (IMHO) не было.

Интересно, почему борланд все начинает с паскаля, а потом уже Цэ++?
И вообще, они обищают Kylix/C++ в дополнению к Kylix/Pascal?

VCL на паскале написан Delphi IDE тоже в этом весь замут
Повторное использование кода называется

C++ будет но позже, вроде ещё будет Kylix/Delphi Studio - C++ & Pascal в одном флаконе за одну низкую цену ж)))))

RONA

2RONA: Ты случайно не на Softool-е видел Kylix? Там кажется еще С.Орлик говорил что в планах Борланда "свести" вместе 6-е версии Delphi и Kylix, т.е сделать взаимно переносимым код между ними (ну.. _почти_ без переделок).
2All: Кстати, как сказал С.Орлик Kylix естесс-но принесет с собой в линукс ряд своих библиотек (IMHO == гемморой с инсталляцией прог) и вот не успели мы тогда его спросить как будут в Kylix обстоять дела дела с linux-овым fork-ом. Кстати, народ, если кто не знает, весь IDE у Kylix пока работает в эмуляторе win :))) Поэтому тормоза присутствуют. На момент софтула они переписали по словам СОрлика немного-непомню-точно-сколько кода :))

Нет не на Softoole

Delphi 6 опережает Kylix по набору функциональности (они разрабатываются паралельно)

Kylix основан на библиотеке CLX, Delphi 6 на VCL однако CLX будет поставлятся и с Delphi 6 что позволит реализовать облегченную переносимость между CLX на Linux и на Windows. При этом VCL работающая только на Windows будет развиваться паралельно с CLX.
Визуальная часть CLX основана на Qt и имеет модель обработки событий отличную от Windows API?

Kylix я видел на пне слабом с 32 метрами пахал он только так без задержек. Кроме того CLX имеет уже имеет уровень абстракции операционки типа ввод вывод процессы и т п. Я сильно сомневаюс что на данный момент Borland сильно полагается на эмуляцию (компилятор точно не полагается)...

RONA

2RONA: Как сказал на софтуле Орлик final release не будет на эмуляторе работать, но _пока_ это так.

Delphi - язык для домохозяек. Delphi был написан для того, чтобы любой чайник особо не вдаваясь в подробности мог создать работающее приложение. Это не я придумал, а сами Борланды. Я лично фирму Борланд не люблю еще со времен С++ 3.1. Отстой полный!!! Чего там компилятор с регистрами вытворял ужас. Я не понял чего тут народ размерами экзешников стал меряться. Какая разница какой размер если при запуске прога выделяет память под все статично нарисованные формы а? Я видел результаты труда некоторых деятелей где прога учета кадров с 15 формами требовала минимум 32Мб и работала с жуткими тормозами при пустой базе. Я не спорю, что если приложить мозги можно и на Delphi клепать большие проекты, но все таки Delphi не для серьезной работы.

Короче в руках профессионала Delphi это мощный и удобный инструмент, а в руках бездыря рецепт для неудачи.

Звучит как описание почти любого другого средства разработки.

RONA

THE END.

Зачем каждый? Возьми один из них.

А кто скажет, где можно хотя бы посмотреть на PowerPlant (как я понял он теперь только за деньги)?

Насчет С++ и Excell, то никто не заставляет тебя использовать статическую компоновку (просто прога тогда быстрее форцает). Используй динамическую как в твоем любимом Delphi. Просо он статически связать не может (разьве что через ж...). С CORBA в Delphi те же проблемы.