![]() |
Здравствуйте, гость ( Вход | Регистрация )
![]() |
31512 |
![]()
Сообщение
#1
|
![]() Студент ![]() Группа: Новичок Сообщений: 26 Регистрация: 13.3.2008 Из: Красноярск Пользователь №: 119 Спасибо сказали: 0 раз(а) Репутация: ![]() ![]() ![]() |
1)возможно, некоторым и интереснее клепать все интерфейсы и прочее почти автоматически в борланде, а мне интереснее писать все самому, иначе это уже фактически не программирование, хотя у Qt4 тоже довольно высокоуровневые апи ![]() 2)в этой среде разработки я постараюсь собрать лучшее из других IDE 3)вообще не хочу с тобой спорить - итак работы куча над проектом, времени не хватает, а переубедить ты меня все равно не сможешь, слишком упрямый я ![]() Достойный ответ. Только вот спорить-то я с тобой не собирался. А хотел понять: твои мотивы и понял. Правда есть возражения. Не знаю, что ты подразумеваешь под программированием. Вряд ли стоит называть программированием деланье всего в ручную, через универсальный интерфейс именуемый з..... . Если ты думаешь (а я искренне надеюсь что это не так), что те кто пишут на Delphi не программируют а занимаются только кнопкокидательством, то сильно заблуждаешься. Жаль мой вопрос остался открытым. ![]() хотя у Qt4 тоже довольно высокоуровневые апи Настолько высокоуровневые, что нивелируются все достоинства компилятора С++. Да и не API это с формальной точки зрения. Они, как раз, во главу угла ставят уход от всяческих API и системных вызовов. Ибо кроссплатформенность. |
|
|
![]() |
AD |
![]()
Сообщение
#2
|
Профессионал ![]() ![]() ![]() ![]() ![]() Группа: Участник Сообщений: 2003 Регистрация: 4.2.2008 Из: S-Petersburg Пользователь №: 84 Спасибо сказали: 70 раз(а) Репутация: ![]() ![]() ![]() |
VCL и Qt - сравнивать, по-моему, не стоит. У Qt задач больше, они шире и глубже и выполняет Qt их очень даже успешно.
|
|
|
Tonal |
![]()
Сообщение
#3
|
![]() Активный участник ![]() ![]() ![]() Группа: Участник Сообщений: 452 Регистрация: 6.12.2007 Из: Новосибирск Пользователь №: 34 Спасибо сказали: 69 раз(а) Репутация: ![]() ![]() ![]() |
[злостный оффтоп]
Ну если уж пошло мерение разными органами, то проект, на в котором я работал дольше всего (~10 лет), имел такую статистику: 180424 строк на паскале, 107346 на C++ и 289 на Asm Delphi начиная с 4ки и заканчивая 7кой. Последние ~1.5, 2 года я был тимлидом, и вёл поддержку/разработку 18 из 26 модулей delphi и половины модулей на С++. Щас непомню в скольких регионах было промышленное внедрение, но крутится цифра 30... Ушел оттуда ~6 лет назад. Так что я в курсе возможностей Delphi. ![]() А один мой хороший знакомый создал и поддерживал промышленную систему на VB6 там была и графика, и сложные рассчёты, и печатные отчёты и скриптование. Но не было базы данных. ![]() [/злостный оффтоп] [VCL vs Qt] Главный недостаток VCL-я в кривой архитектуре и неподдержки MVC - из за этого приходится делать специализацию любых сложных контролов под конкретную задачу. Что и делают библиотеки EhLib, DevExpress, JVCL и много других. В названных тобой прогах используются в основном тоже свои внутренние специализации. Причём специализация для VCL-я - это пакет Delphi, т.е. дополнительный проект, который должен быть установлен в среду. Сравни это с Qt, где простым изменением модели (класс приложения) я могу заставить грид или дерево работать и с базой и с любым моим контейнером, или где для того, чтобы в комбобоксе показывалось дерево требуется классик ~100 строк в приложении. Ну и пакеры в VCL существенно хуже чем в Qt - попробуй например создать форму с изменянмыми размерами, на которой 2 грида и каждый занимает ровно половину не зависимо от размеров (без кода). Ну о мелких ляпах я не новорю - они везде есть да и подзабыл уже. ![]() [/VCL vs Qt] Как IDE Delphi тоже не айс (по крайней мере включая 7ку): 1) Нет возможности настроить несколько конфигураций сборки и их переключать - приходится каждый раз, при необходимости пересобрать релиз после дебага открывать настройки проекта и перенастраивать. И так для каждого проекта в "группе проектов". 2) Нет возможности указать зависимости одного проекта от другого - либо пересобирать явно руками, либо все. 3) Нет возможности указать пользовательские шаги сборки (можно написать плагин к delphi но API долго не было описано и меняется с каждой версией). 4) Добавление обработки своего типа исходного файла мучительно (тоже через плагины) 5) Добавление подсветки своего типа исходного файла невозможно (может через плагины?) 6) Интеграция с системами контроля версий не от багланда появилась только недавно (плагин из JVCL) 7) Файл настроек проекта *.dof содержит как общую информацию так и пользовательскую, так что неудобно работать с системами контроля версий. 8 ) Файл *.dof содержит версию модуля, но игнорирует её изменение т.к. она же содержится в *.res файле. Поэтому для того, чтобы поднять вериси модулей нужно это делать руками в каждом проекте (или удалять *.res файлы модулей, а потом тупо жмякать на мессадж о том что *.res будет пересоздан для каждого проекта. 9) Редактор и среда не скриптуется (опять же можно через плагины) 10) Регулярные выражения для поиска в редакторе куцые 11) Фолдинга нет 12) Перехода по парам begin/end или if/then/else нет 13) Автоматического форматирования блока кода нет. 14) Узнать где используется символ невозможно (удобнейшая возможность в Slick-е) 15) Рефакторинга нет 16) Отладчик путается если пытаться ходить внутрь dll-ек или пакетов. 17) Отладчик часто ломается при исключениях. 18) Сломать отладку можно прото посмотрев значения свойства (всплывающая подсказка при наведении). Короче, для своих применений среда вполне сносная. Особенно если доставить/дописать кучу плагинов для удобной работы. ![]() Собственно о чём это я? Я о том, что когда выбираешь среду хотелось бы чтобы в ней было как можно меньше этих косяков, не зависимо от языка. Сообщение отредактировал Tonal - 3.7.2008, 8:46 |
|
|
![]() ![]() |
![]() |
|
Текстовая версия | Сейчас: 20.7.2025, 4:08 |