Здравствуйте, Gregory_krovosos, Вы писали:
G_>Почитал и решил высказать свое мнение. В настоящее время я разрабатываю систему интернет-трейдинга в финансовой компании, проекту уже 4 года. Интерфейсная часть написана на Delphi, есть также некоторое кол-во библиотек и подпроектов на C++.
G_>Я считаю, что если есть необходимость создать Windows-приложение, в котором будет много формочек и нет ограничений (серьезных) на размер программы и на навыки программистов, то Delphi — отличный выбор, потому что:
Точнее — была отличным выбором (и то с большим количеством "но"). Теперь отличный выбор — .NET WinForms (не без "но" конечно тоже). VCL дальше развиваться не будет, поэтому использовать ее в новых проектах... крайне неразумно.
G_>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.)
То же самое в WinForms. Как, впрочем, и в VBx(x<7) в связке с ActiveX-компонентами.
G_>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message.
Но нету PreProcessMessage
G_>3) Delphi — _модульная_ система программирования. Поэтому компиляция после исправления пары-тройки форм на моем
Вовсе не поэтому, а потому что компилятор однопроходный. Кстати, попробуй инстанцировать чистый абстрактный класс — результат тебя удивит... вероятно. G_>компьютере занимает _ПАРУ СЕКУНД_.
Э-э... Это на проекте, которому уже 4 года? Позволю себе не поверить.
G_>Я очень ценю подобную скорость отклика, так как таков мой стиль программирования — быстро вносить изменения и смотреть что происходит.
Это вредная привычка. Проведи терапию парой сеанцев с достаточно большим количеством ATL/WTL/STL/своего шаблонного кода C++ В действительности, мелкие ошибки должны выявляться средой разработки по ходу написания кода без компиляции (см., например, VS.NET, IDEA и т.п.)
G_>С++ — не модульный язык. Даже включив всякие оптимизации компилирования, я очень долго __жду__ Это плохо.
Плохо то, что ты не знаешь, что такое "модульный язык". Тут дело в другом — компиляторы C++ двупроходные.
G_>А Дельфи замечательно переваривает большие проекты (скажем, сейчас у меня в проекте 118 юнитов из них 58 форм) — _никаких_ _тормозов_. Это замечательно.
По секрету скажу, что 58 форм и 118 юнитов — это *не*большой проект. Ну разве что средний размер одного юнита у тебя — 1MB G_>4) Удобная среда, есть все что нужно и работает быстро.
Удобная среда заканчивается там, где заканчивается мышевозня, то бишь при выходе из дизайнера форм (который, кстати, тоже далеко не идеален — есть и более интересные решения).
G_>5) Производимый компилятором код на мой взгляд очень неплох. Я имею в виду быстродействие там где оно нужно.
Перефразируем: для бОльшинства задач код, выдаваемый компилятором Delphi, вполне нормален. Там, где, например, начинается большое количество математики компилятор Delphi сильно уступает, например, компилятору Intel C++. Кстати, инлайнить код и генерировать типизированный на основе шаблонов, компилятор Delphi не умеет.
G_>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi ).
В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...
G_>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и его уничтожение приходится делать собственноручно. Т.е. C++:
Таких примеров можно привести еще очень много. Поэтому я и говорю, что все удобства в Delphi заканчиваются, когда заканчивается мышевозня...
G_>Шаблоны бы не помешали, но вообще говоря это не must have.
Это must have однозначно, потому как: валидация во время компиляции, потому как: универсальный строго типизированный код без надобности кастования типов (list<int>, list<string> ...), потому как: патерны (smartpointer, class factory, singleton и т.д. и т.д.).
G_>Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты.
Маленькие, да, тянет. Большие... — разве что у мазохистов/энтузиастов.
G_>А еще лучше он становится, если его доработать своими собственными библиотеками (хоть на C++, хоть на чем еще . И под него удобно делать и ActiveX-ы и еще много чего другого.
ActiveX, как и VCL — мертвые технологии, потому что MS официально отказалась от COM в пользу .NET (которая с лихвой покрывает функциональность COM), потому что Borland отказалась от VCL в пользу .NET Framework (которая с лихвой покрывает функциональность VCL).
G_>PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#.
А с чего ты взял, что эти идеи принадлежат Borland? Кстати, ничего отличного в них не вижу. Как и невижу ничего хорошего во всевсяческих кастованиях типов (что во многих случаях есть костыль при отсутствии шаблонов).
G_>>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и G_>>его уничтожение приходится делать собственноручно.
S>http://www.rsdn.ru/Forum/?mid=394033
Since object types do not descend from TObject, they provide no built-in constructors, destructors, or other methods. You can create instances of an object type using the New procedure and destroy them with the Dispose procedure, or you can simply declare variables of an object type, just as you would with records.
Т.е. нет у них конструкторов и деструкторов. Отсюда их неполноценность. 1) — объект придется инициализировать руками,
поскольку несмотря на то, что он будет лежать на стеке, как мы понимаем, в его полях будет мусор.
2) если объект выделяет динамический ресурс, то надо не забыть "дернуть" деструктор.
Вообще получается на нас опять ложится вся эта рутина, а прелесть стековых объектов в C++ именно в том, что у них есть и конструктор и деструктор
и они корректно вызываются, в том числе и при бросании исключений. И всю работу компилятор делает за нас.
Это позволяет пользоваться техникой Resource Managment (то есть выделять ресурс в конструкторе и освобождать в деструкторе)
ну и делать другие приятные вещи.
Повторюсь — в Delphi это достигается через try ... finally, это хорошая штука но опять-таки больше печатать.
G_>>Почитал и решил высказать свое мнение. В настоящее время я разрабатываю систему интернет-трейдинга в финансовой компании, проекту уже 4 года. Интерфейсная часть написана на Delphi, есть также некоторое кол-во библиотек и подпроектов на C++.
G_>>Я считаю, что если есть необходимость создать Windows-приложение, в котором будет много формочек и нет ограничений (серьезных) на размер программы и на навыки программистов, то Delphi — отличный выбор, потому что: А>Точнее — была отличным выбором (и то с большим количеством "но"). Теперь отличный выбор — .NET WinForms (не без "но" конечно тоже). VCL дальше развиваться не будет, поэтому использовать ее в новых проектах... крайне неразумно.
Я бы поспорил. Для нашего приложения, например, (да и для других тоже) критичным является то, что у пользователя может стоять любая Windows на его
домашнем компьютере. И он скачает установочный пакет размером 2 Mb и начнет работать (торговать акциями).
В случае .NET возникают 2 проблемы —
a) не уверен что Windows 95/98/ME/NT поддерживает .NET, надо посмотреть, но какие-то Windows из перечисленных точно не поддерживаются
b) надо скачать и установить ран-тайм для .NET.
Вот у меня лежит dotnetfx.exe, его размер — 24265736 байт.
Для кого-то это все ерунда (у него допустим Windows 2003 стоит, где уже есть .NET framework),
а кого-то из клиентов это оттолкнет. А для компании важны все клиенты, сами понимаете
G_>>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.) А>То же самое в WinForms. Как, впрочем, и в VBx(x<7) в связке с ActiveX-компонентами.
Ну нет. Я согласен, что WinForms как и C# и .NET — хорошая вещь (а как ей не быть таковой, если Microsoft опять .... как бы это выразиться ...
ну скажем позаимствовала все самые лучше идеи для разработки
Но VB с ActiveX — не предлагать!!!
Это мертворожденная технология (как VB так и ActiveX) и серьезные вещи на них делать не стоит.
G_>>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message. А>Но нету PreProcessMessage
result := CallWindowProc(fmChildWindow.OldProc, wnd, msg, wparam, lparam);
end;
G_>>3) Delphi — _модульная_ система программирования. Поэтому компиляция после исправления пары-тройки форм на моем А>Вовсе не поэтому, а потому что компилятор однопроходный. Кстати, попробуй инстанцировать чистый абстрактный класс — результат тебя удивит... вероятно.
А зачем это делать??
G_>>компьютере занимает _ПАРУ СЕКУНД_. А>Э-э... Это на проекте, которому уже 4 года? Позволю себе не поверить.
Только что сделал полный build проекту. Первый раз — 15 секунд. Последующие build (_build_!) — 2-3 секунды (потому как все попало в кеш видимо).
Напоминаю — build: полное перепостроение всего кода. Размер результирующего приложения: 2253824 байта.
Общий размер всех pas файлов в проекте — 1.096.671 байт.
У меня Windows 2000, памяти 512, процессор — около 2 Ghz, точно не помню. Вопросы?
G_>>Я очень ценю подобную скорость отклика, так как таков мой стиль программирования — быстро вносить изменения и смотреть что происходит. А>Это вредная привычка. Проведи терапию парой сеанцев с достаточно большим количеством ATL/WTL/STL/своего шаблонного кода C++ В действительности, мелкие ошибки должны выявляться средой разработки по ходу написания кода без компиляции (см., например, VS.NET, IDEA и т.п.)
Это уведет нас в сторону, но опять-таки таков мой стиль — я люблю проводить быстрые эксперименты — написать пробный код и тут же посмотреть
его в деле — и Delphi очень помогает в этом.
G_>>С++ — не модульный язык. Даже включив всякие оптимизации компилирования, я очень долго __жду__ Это плохо. А>Плохо то, что ты не знаешь, что такое "модульный язык". Тут дело в другом — компиляторы C++ двупроходные.
Под модульным в данном случае я подразумеваю схему компиляции и линковки.
G_>>А Дельфи замечательно переваривает большие проекты (скажем, сейчас у меня в проекте 118 юнитов из них 58 форм) — _никаких_ _тормозов_. Это замечательно. А>По секрету скажу, что 58 форм и 118 юнитов — это *не*большой проект. Ну разве что средний размер одного юнита у тебя — 1MB
Ну все относительно конечно Мой предыдущий большой дельфийский проект насчитывал более 100 форм. А каков Ваш наибольший проект?
Или это из серии "я видел людей которые видели людей которые видели Ленина"?
G_>>4) Удобная среда, есть все что нужно и работает быстро. А>Удобная среда заканчивается там, где заканчивается мышевозня, то бишь при выходе из дизайнера форм (который, кстати, тоже далеко не идеален — есть и более интересные решения).
Аргументы?
G_>>5) Производимый компилятором код на мой взгляд очень неплох. Я имею в виду быстродействие там где оно нужно. А>Перефразируем: для бОльшинства задач код, выдаваемый компилятором Delphi, вполне нормален. Там, где, например, начинается большое количество математики компилятор Delphi сильно уступает, например, компилятору Intel C++. Кстати, инлайнить код и генерировать типизированный на основе шаблонов, компилятор Delphi не умеет.
1) для специальных задач специальное решение всегда лучше типового решения. Если инженеры Intel не спят ночами и роясь в мануалах по семейству
x86 изыскивают методы ускорения расчетов — разумеется — их код всегда будет лучше кода компилятора Дельфи. Но умные люди (как мы с вами) никогда
ведь и не будут использовать бейсик для написания движка физики в игре, правильно?
Ес-но если взять и самому написать sin(x) * cos(sin(y)) на стеке сопроцессора, то это будет работать быстрее чем код, сгенеренный Дельфи (потому
как тот ес-но не будет исходить из предположения что все влезет на стек, а построит более общую схему расчта). Кто с этим спорит?
2) инлайн... ну да, наверное. тем не менее на Дельфи можно писать полностью ассемблерные процедуры с минимальным overhead, что может и отменит
необходимость в инлайн.
3) насчет шаблонов я уже говорил. да их нет, но это не критично.
G_>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi ). А>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...
Ну да. Вот это действительно беда Delphi. Даже в Яве есть набор замечательных структур с добавлением/поиском/удалением за O(log n)...
G_>>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и его уничтожение приходится делать собственноручно. Т.е. C++: А>Таких примеров можно привести еще очень много. Поэтому я и говорю, что все удобства в Delphi заканчиваются, когда заканчивается мышевозня...
Я предпочитаю говорить о конкретных недостатках...
G_>>Шаблоны бы не помешали, но вообще говоря это не must have. А>Это must have однозначно, потому как: валидация во время компиляции, потому как: универсальный строго типизированный код без надобности кастования типов (list<int>, list<string> ...), потому как: патерны (smartpointer, class factory, singleton и т.д. и т.д.).
Шаблоны это замечательно, согласен. Кстати, они появились в Яве (1.5). Но повторяюсь в третий раз — можно пережить и без них.
G_>>Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты. А>Маленькие, да, тянет. Большие... — разве что у мазохистов/энтузиастов.
Аргументы?
G_>>А еще лучше он становится, если его доработать своими собственными библиотеками (хоть на C++, хоть на чем еще . И под него удобно делать и ActiveX-ы и еще много чего другого. А>ActiveX, как и VCL — мертвые технологии, потому что MS официально отказалась от COM в пользу .NET (которая с лихвой покрывает функциональность COM), потому что Borland отказалась от VCL в пользу .NET Framework (которая с лихвой покрывает функциональность VCL).
Напоминаю — проекту 4 года А 3 года назад ActiveX + ASP было весьма распространенное явление.
G_>>PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#. А>А с чего ты взял, что эти идеи принадлежат Borland? Кстати, ничего отличного в них не вижу. Как и невижу ничего хорошего во всевсяческих кастованиях типов (что во многих случаях есть костыль при отсутствии шаблонов).
Да я не о том, что кому принадлежит. Я к тому, что .NET вобрала в себя лучшее и безусловно будет доминировать.
as и is — не обязательно "костыль"
Простейший пример — обход контролов на форме с целью прописывания только лейблам какого-то свойства.
Простой, наглядный код с as и is. (а не static_cast<label> и пр.)
Здравствуйте, Gregory_krovosos, Вы писали:
G_>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.) G_>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message.
То-то же до сих пор Юникода в ней нет. В NT юникодные контролки были изначально, в 9x появились в IE5 (т.е. начиная с Win98SE есть в штатной поставке)
G_>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки.
Это Вы о VCL? Тогда согласен
By the grace of God Almighty
And the pressures of a marketplace
The human race has civilized itself
It's a miracle
G_>>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.) G_>>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message. SC>То-то же до сих пор Юникода в ней нет. В NT юникодные контролки были изначально, в 9x появились в IE5 (т.е. начиная с Win98SE есть в штатной поставке)
То бишь сторонние решения, полностью совместимые по коду.
Во-вторых, потребность в Unicode есть все же не в каждом проекте.
В-третьих, даже если в 9x и появились эти самые Unicode-контролы это не значит, что 9x стали поддерживать Unicode.
G_>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. SC>Это Вы о VCL? Тогда согласен
Я же вроде бы написал подробно, что имел в виду. Вы до конца сообщения дочитали?
Или этот взрыв эмоций не совместим с рациональным мышлением?
Здравствуйте, Gregory_krovosos, Вы писали:
G_>и они корректно вызываются, в том числе и при бросании исключений. И всю работу компилятор делает за нас. G_>Это позволяет пользоваться техникой Resource Managment (то есть выделять ресурс в конструкторе и освобождать в деструкторе) G_>ну и делать другие приятные вещи.
G_>Повторюсь — в Delphi это достигается через try ... finally, это хорошая штука но опять-таки больше печатать.
Но в С++ за тебя это делает компилятор оборачивая все через дополнительный код. Хорошо это или плохо ситуации разные бывают иногда нужен полный котроль над кодом.
Работая же в Net и потом переходя в нативный Delphi вызов деструкторов уже начинаешь игнорировать.
Delphi отличный язык с метаклассами продуманной иерархией и базового класса и прежде всего силен в сложный иерархических моделях, что мы видим в Net и Java.
И для того времени когда был создан считаю его революционным, но к сожалению кроме компоненто строительства принципиальных изменений внесено не было. Курс на Net считаю правильным, но придется сильно напрячся. К тому же Хэйлсберг в лагере M$ а C# стандарт дефакто, хотя и не без изъянов.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
G_>>PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#. А>А с чего ты взял, что эти идеи принадлежат Borland? Кстати, ничего отличного в них не вижу. Как и невижу ничего хорошего во всевсяческих кастованиях типов (что во многих случаях есть костыль при отсутствии шаблонов).
Не боись дженерики заменят шаблоны. А насчет Хэйлсбега ты зря. Можно спорить на что Net (Delph.Net,C#) похож на Java или Delphi но общего у них очень много.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
G_>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi ). А>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...
А>А перегрузки операторов и в 7-ой нету.
В 8 ой есть. Не видел еще 7.1 но говорят должна многое поддерживать для перехода на Net.
Кстати перегрузка операторов хороша для шаблонов и кодогенерации. в Net этим редко пользуются.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
G_>>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi ). А>>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...
S> Который пишется часа за два с нуля, а типизируется за 2 минуты. S> http://www.rsdn.ru/Forum/Message.aspx?mid=419818&only=1
S> И все остальные векторы мапы итд. Это не проблема.
Не согласен.
1. создать нормальный мап — совершенно нетривиальная задача! (ну-ка давайте-ка по памяти напишем процедурку удаления узла из красно-черного или AVL дерева, слабо?)
2. стандартизация — великая вещь, а так у каждого будут в проекте свои контейнеры и свои способы работы с ними и т.д., это очень плохо
То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту.
G_>>>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi ). А>>>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...
S>> Который пишется часа за два с нуля, а типизируется за 2 минуты. S>> http://www.rsdn.ru/Forum/Message.aspx?mid=419818&only=1
S>> И все остальные векторы мапы итд. Это не проблема.
G_>Не согласен.
G_>1. создать нормальный мап — совершенно нетривиальная задача! (ну-ка давайте-ка по памяти напишем процедурку удаления узла из красно-черного или AVL дерева, слабо?)
Блин я этих деревьев перенаписал блевать на них хочется.
G_>2. стандартизация — великая вещь, а так у каждого будут в проекте свои контейнеры и свои способы работы с ними и т.д., это очень плохо
Предпочитаю свои классы, т.к. стандартные как правило ограничены. G_>То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту.
Пользоваться можно чем угодно в том числе и генераторами кода.
А против стандарта и корпоративного кодирования ничего против не имею, только скучно.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
G_>>>>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi ). А>>>>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее...
S>>> Который пишется часа за два с нуля, а типизируется за 2 минуты. S>>> http://www.rsdn.ru/Forum/Message.aspx?mid=419818&only=1
S>>> И все остальные векторы мапы итд. Это не проблема.
G_>>Не согласен.
G_>>1. создать нормальный мап — совершенно нетривиальная задача! (ну-ка давайте-ка по памяти напишем процедурку удаления узла из красно-черного или AVL дерева, слабо?) S>Блин я этих деревьев перенаписал блевать на них хочется.
G_>>2. стандартизация — великая вещь, а так у каждого будут в проекте свои контейнеры и свои способы работы с ними и т.д., это очень плохо
S> Предпочитаю свои классы, т.к. стандартные как правило ограничены.
Это спор разработчика-одиночки и разработчика-члена-команды. Понятно, что свои компоненты ближе к сердцу и можно делать с ними все что
угодно, только иногда как ни странно важна стандартизация и абсолютная безглючность, проверенная временем.
Я тоже написал в свое время Б-дерево, идея возникла за 15 минут, реализация — за день. Только вот
_нормальное_работающее_Б-дерево_, охваченное итераторами, оптимизированное где нужно, с самопроверкой и пр. взошло не один месяц спустя.
Мое самое оптимизированное Б-дерево все равно было медленнее map примерно в 1.5 раза.
G_>>То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту. S> Пользоваться можно чем угодно в том числе и генераторами кода. S> А против стандарта и корпоративного кодирования ничего против не имею, только скучно.
Да уж, зато вставить в свою программу глючный компонент, обрушить пару сотен терминалов в самый разгар торгов,
получить сотню одновременных звонков на предмет невозможности торговать от клиентов, кучу претензий, удары по всем
частям тела от хедпдеска и от начальства и от начальства начальства — быстро начинать править код, каждый
5 сек. дергаемый словами "ну что готово" и "там опять все упало", быстро раздать это все какой-то паре сотен клиентов — вот ерунда-то! — это конечно не скучно, это очень весело!!!!!
S>> Предпочитаю свои классы, т.к. стандартные как правило ограничены.
G_>Это спор разработчика-одиночки и разработчика-члена-команды. Понятно, что свои компоненты ближе к сердцу и можно делать с ними все что G_>угодно, только иногда как ни странно важна стандартизация и абсолютная безглючность, проверенная временем.
G_>Я тоже написал в свое время Б-дерево, идея возникла за 15 минут, реализация — за день. Только вот G_>_нормальное_работающее_Б-дерево_, охваченное итераторами, оптимизированное где нужно, с самопроверкой и пр. взошло не один месяц спустя.
Когда опираешься на собственные реализации алгоритмов и проверенные временем то они становятся для меня уже стандартными.
Кстати многие сишникиеи простейших алгоритмов не знают. Зато знают вектор map итд. А переходя на C# руки опускаются. G_>Мое самое оптимизированное Б-дерево все равно было медленнее map примерно в 1.5 раза.
Значит таков алгоритм или его реализация. А под мап можно подогнать и Хэш таблицы и BitArray и B+ деревья и просто массив и у всех есть плюсы и минусы и своя область применения.
G_>>>То, что STL появилась на свет и успешно существует и очень многими используется доказывает мою правоту. S>> Пользоваться можно чем угодно в том числе и генераторами кода. S>> А против стандарта и корпоративного кодирования ничего против не имею, только скучно.
G_>Да уж, зато вставить в свою программу глючный компонент, обрушить пару сотен терминалов в самый разгар торгов, G_>получить сотню одновременных звонков на предмет невозможности торговать от клиентов, кучу претензий, удары по всем G_>частям тела от хедпдеска и от начальства и от начальства начальства — быстро начинать править код, каждый G_>5 сек. дергаемый словами "ну что готово" и "там опять все упало", быстро раздать это все какой-то паре сотен клиентов — вот ерунда-то! — это конечно не скучно, это очень весело!!!!!
Значит не надо делать глючные компоненты. А своих багов добавить и простейший код всегда пожалуйста, а во многом юзерский код оказывается намного алгоритмически сложнее чем стандартные библиотеки где кода 10 строчек.
Не ошибается тот кто ничего не делает, а кривизны в стандартных библиотеках хватает выше крыши как в Delphi, Net, Java.
Нет кривизны только в STL !!!!!!
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
А>В действительности о Delphi, как таковой, можно забыть как о страшном сне. Borland ее развивать не будет. В более-менее серьезных проектах использовать Delphi, в виду убогости Object Pascal и, собственно, VCL, не рационально. Да и зачем, если есть .NET?.
Могу допустить убогость VCL, но вопрос в чес убогость Object Pascal?
Здравствуйте, Serginio1, Вы писали:
S> Не ошибается тот кто ничего не делает, а кривизны в стандартных библиотеках хватает выше крыши как в Delphi, Net, Java.
Можно узнать перечень "кривизны" в .NET? И что подразумевается под "выше крыши", применительно к кривизне .NET? S> Нет кривизны только в STL !!!!!!
Ага... Особенно в std::auto_ptr.
Задумайтесь, почему многие предпочитают заменять "стандартный" STL в VС++ на STLPort, а вместо std::auto_ptr использовать boost::shared_ptr
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Вот у меня лежит dotnetfx.exe, его размер — 24265736 байт. G_>Для кого-то это все ерунда (у него допустим Windows 2003 стоит, где уже есть .NET framework), G_>а кого-то из клиентов это оттолкнет. А для компании важны все клиенты, сами понимаете
В действительности, если уж клиент может позволить себе преобрести ваше ПО, то и скачать 25-30MB для него труда не составит, потому как это копейки.
G_>>>1) VCL — достаточно продуманная и гибкая обертка для Windows GUI, которая берет на себя огромную часть рутины и позволяет программировать на высоком уровне абстракций (Button1.Caption := 'Ляля' и т.д.) А>>То же самое в WinForms. Как, впрочем, и в VBx(x<7) в связке с ActiveX-компонентами. G_>Ну нет. Я согласен, что WinForms как и C# и .NET — хорошая вещь (а как ей не быть таковой, если Microsoft опять .... как бы это выразиться ... G_>ну скажем позаимствовала все самые лучше идеи для разработки
А что Вы в этом видите предосудительного? Разве чьи-то авторские права были нарушены? G_>Но VB с ActiveX — не предлагать!!! G_>Это мертворожденная технология (как VB так и ActiveX) и серьезные вещи на них делать не стоит.
Тем не менее, на них куда больше действительно серьезных коммерческих проектов. Пример Microstrategy. Разве есть что-то близкое по классу, но написанное на VCL? Я лично не знаю. Так что Вы весьма заблуждаетеся. Delphi (CBuilder) на западе распространены значительно в меньшей степени, чем VB, C++ или Java. Только на просторах постсоветских стран Delphi и CBuilder на столько популярны, что даже в институтах по ним читают целые курсы лекций...
G_>>>2) если возможностей VCL не хватает — можно переопределить оконную процедуру и обрабатывать самостоятельно специфические Windows-сообщения или использовать методы со свойством message. А>>Но нету PreProcessMessage G_>Я же говорю:
PreProcessMessage позволяет обработать сообщение непосредственно перед dispatch.
G_>>>3) Delphi — _модульная_ система программирования. Поэтому компиляция после исправления пары-тройки форм на моем А>>Вовсе не поэтому, а потому что компилятор однопроходный. Кстати, попробуй инстанцировать чистый абстрактный класс — результат тебя удивит... вероятно. G_>А зачем это делать??
Делать этого конечно не нужно, но компилятор Делфи, к сожалению, позволяет это сделать.
G_>>>компьютере занимает _ПАРУ СЕКУНД_. А>>Э-э... Это на проекте, которому уже 4 года? Позволю себе не поверить. G_>Только что сделал полный build проекту. Первый раз — 15 секунд. Последующие build (_build_!) — 2-3 секунды (потому как все попало в кеш видимо). G_>Напоминаю — build: полное перепостроение всего кода. Размер результирующего приложения: 2253824 байта. G_>Общий размер всех pas файлов в проекте — 1.096.671 байт.
1MB для всех файлов? Так это ма-а-ахонький проектик. Как Вам удалось растянуть его на 4 года?
G_>>>С++ — не модульный язык. Даже включив всякие оптимизации компилирования, я очень долго __жду__ Это плохо. А>>Плохо то, что ты не знаешь, что такое "модульный язык". Тут дело в другом — компиляторы C++ двупроходные. G_>Под модульным в данном случае я подразумеваю схему компиляции и линковки.
Модульная схема компиляции и линковки? А как это?
G_>>>А Дельфи замечательно переваривает большие проекты (скажем, сейчас у меня в проекте 118 юнитов из них 58 форм) — _никаких_ _тормозов_. Это замечательно. А>>По секрету скажу, что 58 форм и 118 юнитов — это *не*большой проект. Ну разве что средний размер одного юнита у тебя — 1MB G_>Ну все относительно конечно Мой предыдущий большой дельфийский проект насчитывал более 100 форм. А каков Ваш наибольший проект? G_>Или это из серии "я видел людей которые видели людей которые видели Ленина"?
Большие проекты насчитывают сотни мегабайт исходного кода (только кода, заметьте).
G_>>>4) Удобная среда, есть все что нужно и работает быстро. А>>Удобная среда заканчивается там, где заканчивается мышевозня, то бишь при выходе из дизайнера форм (который, кстати, тоже далеко не идеален — есть и более интересные решения). G_>Аргументы?
Навскидку:
1. Гайдлайны в дизайнере форм MFC/ATL/WTL.
2. Layout manager`ы в дизайнерах форм Java, .NET
3. Размещение невизуальных компонентов вне пределов формы на отдельной специально предназначенной области в дизайнере форм VS.NET
4. Локинг элементов на форме там же.
5. Удобный визуальный tab ordering в дизайнере форм MFC/ATL/WTL.
...
G_>2) инлайн... ну да, наверное. тем не менее на Дельфи можно писать полностью ассемблерные процедуры с минимальным overhead, что может и отменит необходимость в инлайн.
Ассемблерные вставки ухудшают читабельность кода и являются потенциальным глюкодромом, не избавляя тем не менее от overhead`а. В C++ компилятор сам может догадаться проинлайнить тот, либо иной метод.
G_>3) насчет шаблонов я уже говорил. да их нет, но это не критично.
Смотря что понимать под "критично". Overhead и возможные ошибки при преобразованиях типов — для меня, например, это весьма критично.
G_>>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi ). А>>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее... G_>Ну да. Вот это действительно беда Delphi. Даже в Яве есть набор замечательных структур
Э-э, smart pointers — это не структура данных. Это патерн, уничтожающий объект в момент, когда он становится никому более не нужным. Чаще всего реализуется путем подсчета ссылок. G_>с добавлением/поиском/удалением за O(log n)...
А в Java та же проблема, что и в Delphi и в .NET — без generics-типов (шаблонов) невозможно создать алгоритм, специализируемый при компиляции с проверкой времени компиляции, поэтому приходится прибегать все к тому же кастованию типов. На Delphi, точно так же, как и на Java можно реализовать и slice-списки, и B-деревья, и прочие весьма эффективные (для конкретной задачи) структуры. Однако гибкости, предоставляемой шаблонами, нам не получить. Впрочем, в Java шаблоны вроде бы обещали в JDK 1.5, а в C# шаблоны будут во второй редакции языка... так что не все так мрачно.
G_>>>Далее, серьезный недостаток Delphi Pascal — отсутствие стековых объектов, все объекты — в дин. памяти и соот-но создание объекта и его уничтожение приходится делать собственноручно. Т.е. C++: А>>Таких примеров можно привести еще очень много. Поэтому я и говорю, что все удобства в Delphi заканчиваются, когда заканчивается мышевозня... G_>Я предпочитаю говорить о конкретных недостатках...
О конкретных недостатках правильнее говорить в контексте той или иной задачи — класса задач.
G_>>>Шаблоны бы не помешали, но вообще говоря это не must have. А>>Это must have однозначно, потому как: валидация во время компиляции, потому как: универсальный строго типизированный код без надобности кастования типов (list<int>, list<string> ...), потому как: патерны (smartpointer, class factory, singleton и т.д. и т.д.). G_>Шаблоны это замечательно, согласен. Кстати, они появились в Яве (1.5).
Таки появились? Замечательно. G_>Но повторяюсь в третий раз — можно пережить и без них.
Можно, бесспорно. Живет ведь Янус (RSDN@Home) без них. И наши проекты на C# тоже живут. Тем не менее, шаблоны исключительно важны для любого современного языка.
G_>>>Вообщем, надеюсь главная мысль ясна. Дельфи — замечательная "обертка" для проекта под Windows, он легко "тянет" и маленькие, и большие проекты. А>>Маленькие, да, тянет. Большие... — разве что у мазохистов/энтузиастов. G_>Аргументы?
Назову один, но весьма-весьма весомый — в Delphi отсутствуют smart pointers/garbage collector.
G_>>>PS Один из отцов-основателей Delphi ушел в Microsoft разрабатывать C#, так что нетрудно заметить как отличные идеи в Delphi (скажем as и is) переползли в C#. А>>А с чего ты взял, что эти идеи принадлежат Borland? Кстати, ничего отличного в них не вижу. Как и невижу ничего хорошего во всевсяческих кастованиях типов (что во многих случаях есть костыль при отсутствии шаблонов). G_>Да я не о том, что кому принадлежит. Я к тому, что .NET вобрала в себя лучшее и безусловно будет доминировать.
VB, C++, Java безусловно доминировали до создания .NET Да и сейчас, впрочем, Java и C++ доминируют.
G_>as и is — не обязательно "костыль" G_>Простейший пример — обход контролов на форме с целью прописывания только лейблам какого-то свойства. G_>Простой, наглядный код с as и is. (а не static_cast<label> и пр.)
А зачем в этой задаче static_cast? В таком случае действительно удобнее было запросить у формы коллекцию этих объектов и пройтись по коллекции оператором foreach. Например, так:
foreach(Label label in MyForm.Controls["Label"])
{
label.Text = label.Name;
...
}
Здравствуйте, Serginio1, Вы писали:
G_>>>Разумеется, у Delphi есть недостатки. Самый главный ИМХО — "плохие" библиотеки. При работе с TCP/IP, потоками и пр. самое лучшее — написать свои собственные библиотеки на базе Win32 API. Скажем, самый главный компонент многозвенных приложений TClientDataSet "теряет" память. Включенные в поставку компоненты для поддержки интернет-протоколов — это @#$@$#@$#! Далее в Delphi нет STL и даже вообщем-то аналогов. Например, я до сих пор не нашел аналога map в стандартной поставке Delphi (может быть гуру подскажут?) и мне пришлось написать на C++ DLL-ку и свой модифицированный TStringList, где поиск ключа идет со скоростью O(log n), а не простым перебором (каковой можно наблюдать в исходных текстах Delphi ). А>>В бОльшинстве случаев интереснее hash_map. А еще нету интеллектуальных указателей, без коих много-много сложнее... S> Который пишется часа за два с нуля, а типизируется за 2 минуты.
Типизировать вручную? Нет уж, увольте от такого сомнительного удовольствия. Это идеологически неверно.
Здравствуйте, DarkGray, Вы писали:
DG>1. C# DG>2. Delphi DG>3. Builder DG>4. C++ + MFC DG>5. C++ + WTL/ATL
DG>P.S. Если надо писать небольшие приложения, то я бы поставил связку C++ + WTL/ATL на 2 место.
А для средних и больших проектов пункты 2 и 3 вообще выкинуть, как нерелевантные.
Здравствуйте, Anatolix, Вы писали:
DG>>1. C# DG>>2. Delphi DG>>3. Builder DG>>4. C++ + MFC DG>>5. C++ + WTL/ATL
A>Я бы вот только BCB вынес на первое место т.к. он юзает и компоненты от Delphi и просто C++ либы.
В итоге получается нечто такое, что вообще использовать нельзя ни в коем случае. Даже на очень-очень малых проектах легко столкнуться с пресловутой глючностью CBuilder. A>На счет C# на первом месте — считаю что спорно, но спорить не буду. A>И надо еще Java куда-нибудь воткнуть, куда-нибудь наверх, у них тоже очень хороший набор библиотек.
А Java как раз рядом с C# неплохо смотрится.
Это плохо.
Тут дело в другом — компиляторы C++ двупроходные. 
В таком случае действительно удобнее было запросить у формы коллекцию этих объектов и пройтись по коллекции оператором foreach. Например, так: