Здравствуйте, shvonder, Вы писали:
_>>Опять же если заниматься адскими вычислениями то зачем выбирать борланд? S>Согласен, фортран удобнее. Но ещё более удобен Matlab (кроме шуток). Вейвлет-фильтрация матрицы в 10 строчках + рисуночек — это вам не асме оптимайзить.
а в чем проблема?
он вроде позволяет реализованную функцию в COM-объект запихнуть или в .dll
Здравствуйте, Сергей, Вы писали:
С>Здравствуйте, Mazay, Вы писали:
M>>ИМХО M>>1) Потому что более не разумно использовать неуправляемый код для больших работ по GUI.
С>А можно поподробнее с этого места — почему неразумно? Delphi — очень мощная вещь для разработки GUI. При правильном подходе реализовать интерфейс, скажем, аналогичный интерфейсу Microsoft Office — это дело одного-двух рабочих дней.
В управляемой среде программировать гораздо приятнее благодаря:
1) Сплошной RTTI и вся информация о типах в рантайме + reflection. Напрямую в прикладном коде это, разумеется, не часто используется, но позволяет делать разные вкусности вроде аккуратного стэк-трэйса, оборачивания объектов, плюс то что перечисленно ниже:
2) Нет таких страшных вещей как расстрел стэка или "Access Violation". Есть, конечно, NullPointerException, но как правило локализует легко, даже без отладчика.
3) Неверное явное приведение типов ловится сразу же и так же лего локализуется.
3) Динамическая загрузка кода. Поясню — если половина классов в проекте на Яве не компилируется, это ещё не значит, что проект не сможет запуститься. И вообще манипулирование сборками/class-файлами гораздо проще чем динамичесая подгрузка DLL.
4) Не нужно думать о таких вещах как передача параметра по указателю или по значению, о владении объектом, о том делать или не делать метод виртуальным и т. п. Для всего этого есть неплохое решение по умолчанию, которое, по крайней мере, не позволит выстрелить себе в ногу.
В общем, то что на Дельфи делается "при правильно подходе", здесь могут делать "тупые индусы".
Разумеется, за эти преимущества приходится платить снижением гибкости и вычислительными ресурсами. В случае приложений, где важен GUI (аськи, плееры, почтовики, органайзеры) это может стать фатальным.
Главное гармония ...
Re[2]: почему ушел C++ Builder / Delphi?
От:
Аноним
Дата:
27.11.07 14:26
Оценка:
Здравствуйте, dip_2000, Вы писали:
_>Здравствуйте, lamer11, Вы писали:
_>4) Тут нет у меня подтверждения, но есть ощущение что Делфи был так популярен именно в ExUSSR А за его пределами он был популярен совсем не так сильно. Границы стираются, и мы приходим к тому же, что и весь мир. http://google.com/trends?q=delphi говорит что Вы правы.
M>1) Потому что более не разумно использовать неуправляемый код для больших работ по GUI.
чем ?
M>2) Потому что на этот рынок пришла Микрософт. (Там судя по всему много чего было — и финансово Борланд зависели от МС, и людей МС переманила важных, да и вообще — жутковато с МС тягаться, особенно учитывая страшные сказки про смерть WinAPI в Vista)
никуда винапи не делся, да и болбшая часть в ней самой на С++ родном и написано
M>Это оказало косвенное вляние. С появлением дотнета на C++ имело смысл делать GUI если хочешь переносимости, чего Борланд предложить не сумел, зато его конкуренты — QT и wxWidgets это умели всегда, а теперь эта фича стала относительно более весомой.
Вы что-то путаете что B2006 что B2007 работаеют с .NET а последняя и под Висту.
_>>1) Там давно нет с++ там уродливое наречие сильно напоминающее с++
проходит все ANSI тесты
_>>2) Продукт перестал развиваться самим родителем(Борландом)
Его развивает другая компания, не думаю что это минус
S> По-поводу BCB согласен с автором. Это и не C++, и не Delphi, ни рыба не мясо. Пользуясь им всё равно приходиться знать Deplhi.
ЗА 10 лет пользования ни разу не приходилось копаться в Delphi
S> Низкое качество C++ (собенно шаблонов) проявляется при попытке установить любую популярную библиотеку. Boost приходиться ковырять
Все версии boost включая самую последнюю компилятся удачно. Можте что-то другое ?
Здравствуйте, AndrewJD, Вы писали:
AJD>А можно ссылки на софт или хотя бы скриншоты софта написанного на Delphi с интерфейсом уровня Microsoft Office? AJD>Только не Office 97, а хотя бы 2000-2003
Мда, что-то не находится. На предыдущей работе приходилось иметь дело с некой средой разработки для микроконтроллеров — так вот она была построена на Jedi VCL, в ней самыми примечательными были компоненты для Dock-окошек, MSOffice-подобные тулбары/меню и компоненты для сохранения состояния всего этого дела в конфиг. Попробовал найти какие-нибудь скриншоты Jedi VCL — на офф. сайте не нашлось. Даже самому стало интересно, что там изменилось за полтора года.
С ходу нашлось только это: http://www.tmssoftware.com/advtoolbar.htm
Это демка набора компонентов, реализующих эелементы интерфейса Office-2007. Штука платная, но цена не кусается, так что если стоит задача делать подобный интерфейс — в любом случае дешевле купить, чем самому писать.
В принципе, можно еще привести в качестве примера саму среду Delphi.
Здравствуйте, Максим2006, Вы писали:
М>Здравствуйте, Сергей, Вы писали:
С>>А можно поподробнее с этого места — почему неразумно? Delphi — очень мощная вещь для разработки GUI. При правильном подходе реализовать интерфейс, скажем, аналогичный интерфейсу Microsoft Office — это дело одного-двух рабочих дней. М>Аналогичный не получится — у них всё на самопальных контролах построено (типа MsoCommandBar). Вряд ли за два дня удастся их воспроизвести.
Воспроизводить и не надо — такие компоненты существуют, как бесплатные, так и платные.
Здравствуйте, Mazay, Вы писали:
M>В управляемой среде программировать гораздо приятнее благодаря: M>1) Сплошной RTTI и вся информация о типах в рантайме + reflection.
RTTI в Delphi тоже весьма богат — если сравнивать с C++.
Рефлекшена в Delphi (нативном, разумеется — не Delphi.NET) нет. В чем полезность этой фичи в условиях наличия исходников?
M>Напрямую в прикладном коде это, разумеется, не часто используется, но позволяет делать разные вкусности вроде аккуратного стэк-трэйса, оборачивания объектов, плюс то что перечисленно ниже: M>2) Нет таких страшных вещей как расстрел стэка или "Access Violation". Есть, конечно, NullPointerException, но как правило локализует легко, даже без отладчика. M>3) Неверное явное приведение типов ловится сразу же и так же лего локализуется.
Всё это, бесспорно, удобно, но я акцентировал внимание именно на преимуществах управляемого кода для написания GUI.
M>3) Динамическая загрузка кода. Поясню — если половина классов в проекте на Яве не компилируется, это ещё не значит, что проект не сможет запуститься. И вообще манипулирование сборками/class-файлами гораздо проще чем динамичесая подгрузка DLL.
В Delphi есть понятие Runtime Package — это DLL с дополнительной информацией о содержимом, благодаря чему также намного удобнее Plain-C DLL.
M>4) Не нужно думать о таких вещах как передача параметра по указателю или по значению, о владении объектом, о том делать или не делать метод виртуальным и т. п. Для всего этого есть неплохое решение по умолчанию, которое, по крайней мере, не позволит выстрелить себе в ногу.
M>В общем, то что на Дельфи делается "при правильно подходе", здесь могут делать "тупые индусы".
С этим спорить не буду — "тупые индусы" на Delphi пишут всю логику в OnClick'ах.
M>Разумеется, за эти преимущества приходится платить снижением гибкости и вычислительными ресурсами. В случае приложений, где важен GUI (аськи, плееры, почтовики, органайзеры) это может стать фатальным.
Мне в Delphi сильно импонирует то, что результат не требует ничего, кроме стандартных системных DLL. Да и нативное приложение намного быстрее запускается.
Собственно, мой интерес к теме разработки GUI на управляемом коде был вызван вот чем: 2 года назад я работал Delphi-программистом, и собственно тогда и понял, что сила Delphi в наличии большого количества компонент, которые как правило очень просто встроить в своё приложение. Например, в JediVCL было много компонентов, повторяющих поведение оригинальных элементов управления других программ — например, Dock-окна a-la VS2005, Navigation Bar от Norton Antivirus. Весьма навороченный интерфейс можно было создать весьма просто. Сейчас, я смотрю, все в "мире Delphi" осталось примерно на том же уровне — похоже, умирает. Вот я и хотел узнать, как с этим делом (наличием сторонних компонент) в разработке на .Net/Java.
Здравствуйте, silart, Вы писали:
S>Тут был разговор про высокую цену Qt. S>Скажите пожалуйста, сколько же стоит коммерческая лицензия Qt под Windows, для MSVC2005?
Здравствуйте, Alex_Avr, Вы писали:
A_A>Здравствуйте, silart, Вы писали:
S>>Тут был разговор про высокую цену Qt. S>>Скажите пожалуйста, сколько же стоит коммерческая лицензия Qt под Windows, для MSVC2005?
A_A>здесь
Да заходил я уже по таким ссылкам. Точную цену никогда не говорят. Как-будто большой секрет. Там регистрироваться нужно. Вы мне можете назвать цифру? Хотя бы порядок цифр. 1000 баксов, 10000 баксов, 100000 баксов? Сколько примерно?
Здравствуйте, silart, Вы писали:
S>Здравствуйте, Alex_Avr, Вы писали:
A_A>>Здравствуйте, silart, Вы писали:
S>>>Тут был разговор про высокую цену Qt. S>>>Скажите пожалуйста, сколько же стоит коммерческая лицензия Qt под Windows, для MSVC2005?
A_A>>здесь
S>Да заходил я уже по таким ссылкам. Точную цену никогда не говорят. Как-будто большой секрет. Там регистрироваться нужно. Вы мне можете назвать цифру? Хотя бы порядок цифр. 1000 баксов, 10000 баксов, 100000 баксов? Сколько примерно?
Прошу прощения, Daevaorn.
Просто вчера торопился, не стал заходить по вашей ссылке. У меня инет медленный.
Спасибо за ссылку.
Что-то действительно дороговато.
$3300 за Qt Desktop для одной платформы.
Хотя, за хороший продукт, да если еще контора профессионально занимается разработкой, по-моему стоит приобрести.
Ни с какими Делфи, Билдером и MFC не сравнится. Все гораздо круче.
Здравствуйте, lamer11, Вы писали: L>так ли это? еще какие-нить причины?
Плохая оптимизация. Особенно вычисрений с плаваюшей запятой.
Ещё очень много глюков, причём не только компилятора ("сложные" шаблоны) но и рантайма.
Самое обидное, что большенство из этихглюков очень давно известны, но не исправляются...
Здравствуйте, Dym On, Вы писали:
DO>[skip]
S>>Да кто ж спорит. Хорошая вещь. Но мне нужны матрицы библиотечные (Blitz), библиотеки надёжные (boost) и контейнеры стандартные. А формочки — что делать ? — придётся из wxWidgets брать. DO>Если Вас все в BCB не устраивает, то зачем Вы им пользовались?
Ааааа, не надо по больному месту... Ну, не по своей воле. Старого кода туева хуча есть, вот и сидим на (де)билдере.
Что я могу сказать: проблем куча есть и отрицать их наличие фразами типа 'ха, пионэры, вы просто билдер готовить не умеете правильно' по меньшей мере странно. Причем большАя часть глюков-глючков-глючочков просто детские какие-то. То среда косячит, то память в ней утекает... То инлайн подстановки не выполняются (оказалось, IDE не передает параметр компилятору... детсад просто).
Но есть и куча косяков более фундаментальных, вроде поддержки стандарта С++. Конечно, полностью его никто не поддерживает, но так, как его не поддерживает Билдер... эх, блин.
S>Что-то действительно дороговато. S>$3300 за Qt Desktop для одной платформы.
Есть варианты: Qt Light Desktop Edition (только QtCore + QtGui)
или заполнить и отправить документы по спецпредложению для мелких контор,
получив скидку в 70%
Мы недавно докупали лицензии как раз с такой скидкой.