Чем VB лучше и хуже Delphi?

[LSL]

is
Говорят что C++ быстрее VB, это понятно ...
Правда, что скорость выполн. программ C# и VB.NET одинакова..

А что из себя представляет Delphi 7 по отн. к .NET
?

Grossmeister Провал? Я так не думаю..

[is]

LSL Можно сделать в С++ программе такие лики, что она будет медленее VB программы Легко. ) И, к тому же, поставит на колени систему (в худшем случае это может быть сервер; правда, на VB сервера не пишут и такое сравнение не совсем уместно, но возможные лики в приложениях, написанных на С++ и при кривых руках, не отменяют).

Хорошо насчет этого написал Scot Wingo

(Here's a funny analogy I saw posted...) Well, the principle is the same (create interface, add code to respond to events, add code to do something useful). But programming in Visual Basic is like riding a kiddy bike, while programming in C++ is like driving a Formula 1 racing car—be prepared for accidents.

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

Но! Тут важна еще и стоимость разработки. На VC она больше, чем на VB. Так как VC-программер стоит дороже Правда, часто функциональность таких программа уже другая...

Насчет скорости программ на C# и VB.NET не могу сказать определенно. Знаю только, что программы на C# могут по скорости _превосходить_ программы, написанные на C++. Если интересны подробности, то их можно обсудить. В кратце скажу, что в этом "виноват" GC. Реализован он достаточно удачно. Плюс дополнительные фишки, но это как-нибудь в другой раз Пост разросся и так...

Delphi7 по отношению к .NET? Я мог бы пуститься в пространные рассуждения... Но не стану. Вроде никак прямо они не завязаны. Определенно не могу сказать, т.к. Delphi не в сфере моих интересов. Могу только заметить, что выйдет Delphi .NET. Тут уже определенно завязка будет Говорят, люди уже во всю тестируют Delphi .NET Developer Preview.

Если вы занимаетесь девелопментом на Delphi интересны аспекты связки Delphi и .NET, то могу посмотреть. Уверен, что-нибудь, да найдется. There's no problem

[dthnth]

Kerish доброго дня.
можете ли вы выслать мне исходник с перехватом ctrl shift esc ?
буду очень благодарен. [email protected]

[Alexey]

Grossmeister : хыхх.... ты выясни, кто ты. программист или экономист?

[Xop]

Мое личное мнение:
1) при написании алгоритмической части рулит C++ и STL. Быстро, эффективно, портабельно.
2) для небольших проектов интерфейс быстрее всего создается в Delphi/C++ Builder (VCL), но вот когда такой проект раздувается, понять там что либо - черт ногу сломает.
Поэтому склоняюсь для больших проектов на сторону C++ с использованием MFC, а если нужна портабельность - то Qt.
3) для быстрых численных расчетов есть такая библиотека - Intel Performance Primitives. Написана на C, есть версии под винду и юникс, есть бесплатные версии. Кроме заголовочных файлов включает набор реализаций оптимизированных под конретные процессоры в DLL/SO файлах. Даже на ассемблере вы вряд ли сами быстрее напишете.

[is]

Xop Во многом согласен с Вами. Для небольших проектов MFC тоже рулит.
Для больших - тут не так все однозначно. Маршрутизация сообщений в MFC крайне запутанна, многопоточность тоже не ахти как реализована.

Вообще, MFC представляет собой не очень удачный результат проектирования - большинство классов порождено от CObject. В идеале должен быть "лес", а не дерево классов (как нас учат господа Страуструп и Буч ). Хотя, по сравнению с чистым винапи, удобно. Но втл/атл тоже еще никто не отменял

[Xop]

is Для больших проектов обмен сообщениями надо писать самому, специально под этот проект. А все эти MFC, VCL, Qt и прочие - они создавались как универсальные средства, а за универсальность приходится иногда платить удобством.

Xop добавил [date]1053000567[/date]:
Кстати, Страуструп и Буч - рулят