Здравствуйте, gandjustas, Вы писали:
_>>В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин? G>Автоматическая сборка мусора.
И неконтролируемая... Из-за которой, порой, возникают прелесные фризы на ровном месте.
G>Просто Delphi был единственным инструментом ПРОСТОЙ визуальной разработки. То есть не требовались знания C\C++ и WinAPI, чтобы сделать более-менее рабочее приложение.
Далеко не единственным (были уже и Симантеки с их визуальщиной). Он планировался (изначально), как VB-killer. Но концептуально несравнимо выше.
_>>Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда. G>Это не преимущество, а попытка скрыть недостатки.
Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток? Я еще добавлю, что Delphi и за интерфейсами сама следит.
G>Да, синтаксис паскаля многословный очень. Особенно бесило Procedure и Function. Это все при том, что почти не было поддержки со cтороны IDE.
Чет я не понял... Чего тебе IDE должна поддерживать в процедуре или функции?
G>1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет.
Уж и не знаю кому сложнее, но старому Паскалисту сильно проще чем в C++
G>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)
Интерфейсы есть с очень древней (3/4) версии. А в шарпе делегирование оных есть уже?
G>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля)
Дженерики есть в 2007 под .Net. В 2008 обещают и для нативного кода.
G>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля)
Перегрузка функций/методов есть с 4 версии. Операторы можно перегружать уже с 2005 (для классов только под .Net, для натива можно перегружать для advanced records (class-like)). А с 2006 есть еще и перегружаемые свойства-массивы. Можно еще добавить class/record хелперы.
G>5)Ужасная работа с указателями. (наследие паскаля)
Конкретика? Типизация указателей имеется со времен... очень давно в общем имеется. Адресная арифметика на уровне. Чего не нравится?
G>6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых междц собой).
Чудесная библиотека ввода/вывода (позволяющая при умении заворачивать интереснейшие вещи без участия низкоуровневых API).
G>7)Практически полное отсутствие контейнерной библиотеки
Списки (различные), стеки, очереди, бит-контейнеры, ассоциативные массивы. Мало?
G>8)Большенство классов являются неочень качественными обертками над WinAPI.
Мы сегодня что-нибудь конкретное услышим уже?
G>9)Исполняемые файлы получаются очень тяжеловесными.
Скомпиль с пакетами в Delphi, или в статике с MFC (или присовокупи .Net FW, JVM). Потом сравнивай.
G>Я могу продолжить, но думаю этого хватит.
И вправду можешь не продолжать... Ты явно не в теме (ну, или сильно субъективен, что аж перекашивает).
Здравствуйте, Don Reba, Вы писали:
DR>Не нравится Дельфи из за типично чрезвычайно низкого качества написанных на ней программ.
А мне не нравится краска в балончиках, из-за типично чрезвычайно низкого качества художественных и даже литературных произведений воспроизводимых при участии оной на стенах и заборах.
Здравствуйте, hattab, Вы писали:
H>А мне не нравится краска в балончиках, из-за типично чрезвычайно низкого качества художественных и даже литературных произведений воспроизводимых при участии оной на стенах и заборах.
Правильные балончики для заборов проверяют орфографию.
Паскаль был придуман как учебный язык для изучения основ программирования. Прежде всего из-за этого он приобрел популярность, и его уже потом Борланд (собственно и выросший, насколько помню, на Турбо Паскале) стал его развивать как промышленный. На Дельфи не работал, но в свое время мне Турбо Паскаль не нравился своей эклектичностью: на язык, изначально придуманный только для обучения, не для разработки, стали искуственно навешивать необходимую функциональность и модные фичи. Но это все эмоции. Понятно, что на Паскале можно писать.
Раньше на Паскаль смотрели без уважения и нехорошо из-за нестандартности, отсутствия кроссплатформенности и вообще минимальной переносимости. Для меня лично, например, программирование на Паскале только из-за этого вообще не имело смысла. Я подозреваю, что в "серьезных местах" для разработки "серьезных приложений" Дельфи используют очень редко.
И ведь среда по подходу не хакерская ни разу. Формочки там всякие, драг-н-дропы. Несерьезно .
Не знаю как сейчас, но на Дельфи еще недавно учили толпы студентов и школьников (а какая альтернатива? Бэйсик?). Учили очень часто низкокачественно. Одно время действительно гуляло большое количество "крутых программистов на Дельфи", которые веселили искушенную публику разными штуками, и кодом. По личным ощущениям массово стали нормально учить программированию только последние несколько лет, и в серьезных местах преподают уже не Дельфи (если что, поправьте, пож-та, кто ближе к образованию).
Кто знаком с "рынком" Дельфи-программистов в СНГ и в мире? Я не в курсе, а было бы интересно узнать.
misha_irpen пишет: > Сам я от большого программинга уже отошел, хотя по прежнему могу считать > себя профессионалом Delphi и ASM. И у меня приактически никогда не > возникало проблем из-за каких-то ограничений языка. Я с уверенностью > могу сказать, что могу написать на нем абсолютно все что угодно в рамках > имеющихся API и математических моделей.
Прям как я.
> Просветите плиз вашу точку зрения, только объективно.
1) Плохо стандартизованный. Паскаль и C++ в этом плане похожи. У обоих
формально есть свои стандарты, и не какие–нибудь ECMA, а самые что ни на
есть ISO, но практически есть один–два забугорных компилятора, полностью
реализующих эти стандарты, но о них не каждый слышал, и ими практически
никто не пользуется. Вместо этого пользуются расширенными подмножествами
(эвфемизм для "вольными интерпретациями") стандарта. Для C++
единственный мне известный — это Comeau, для Pascal, пожалуй, gpc, хотя
не уверен. И у Comeau, и у gpc очень мало пользователей по сравнению с
другими "реализациями".
2) Чего не хватает:
шаблоны/дженерики; -- no comments
иерархическое пространство имён; -- тоже не хватает
объявление по месту; -- declare-begin-end — это удобно
автоматическая финализация;
-- я дублировал иерархию классов иерахией интерфейсов, не айс
нисходящие замыкания; -- вроде такого:
procedure Some_Outer_Procedure(...) is
...
Var1 : ...;
Var2 : ...;
Var3 : ...;
begin
-- some code
declare
Var4 : ...;
Var5 : ...;
procedure Enum_Windows_Proc(hwnd : in Handle_Wnd) is
begin
-- some processing here using any of Var1-5
end Enum_Windows_Proc;
begin
Enum_Windows(Enum_Windows_Proc'Access);
end;
-- some code
end Some_Outer_Procedure;
-- notice lParam stripped from both Enum_Windows invokation and
-- Enum_Windows_Proc prototype. lParam is used internally to pass the
-- stack frame pointer or what else is needed to invoke a closure.
Приведённый пример на Delphi сейчас можно реализовать через for-in-do,
но замыкания не ограничиваются перечислением. К тому же, for-in-do
требует генератора, т. е. чтоб перечислитель был вызываемым, а не
вызывающим.
Нисходящее замыкание — это более общий вариант указателя на процедуру. В
Delphi указатель на процедуру может быть расширен до указателя на метод,
а замыкание ещё более общий вариант. У нисходящего замыкания время жизни
меньше, но возможности больше. http://groups.google.com/group/borland.public.delphi.nativeapi.win32/browse_thread/thread/7fe4286d0b8598bb/6a2daa5eaee295e9
агрегаты для массивов, записей и объектов; -- мелочь, а приятно
не объявлять переменную для for; -- и так понятно, какого она типа
встроенная многозадачность; -- актуально
смещение компоненты в записи, не кратное байту;
-- например, для работы с 15 и 16битными bitmap пригодилось бы
битовые массивы размером более, чем 256 битов;
размеры, не определённые на этапе компиляции;
-- на самом деле, редко, когда заранее известно, сколько потребуется
места для данных; использовать буфер статического размера — опуститься
до уровня C, использовать динамический — overhead при
выделении/освобождении; в C99 (?9 лет назад) эта константность в разных
местах была убрана
3) не к самому Delphi, но в сравнении с Free Pascal
Эти реализации разъезжаются. Free Pascal реализует фичи раньше, но в
стиле C++. Borland реализует аналогичную фичу обычно позже, FPC уже
догнал и перегнал Delphi. Но при этом Borland делает вид, что FPC нет, и
реализует фичу в стиле Delphi.NET. Вот так, например, произошло с
перегрузкой операторов. Чтобы написать математику с перегрузкой
операторов переносимо, придётся знать и ту, и другую реализацию. Чем
дальше в лес, тем больше дров. В 2008 появятся дженерики, а в FPC они
уже есть.
4) что не так именно в Delphi
Delphi сильно заточен под платформу. И это не просто зависимость на
уровне библиотек. Платформа определяла появление и реализацию фич. Вот
взять те же интерфейсы, это ведь не просто интерфейсы, это интерфейсы
COM. Причём, автоматическое уничтожение в интерфейсах есть, а в классах
нет. И если класс реализует COM интерфейс, то работать с ним надо уже
через этот интерфейс, потому что иначе можно пожать утечки памяти. В
нормальных языках классы и интерфейсы не отличаются друг от друга
настолько. WideString. Своим появлением обязан всё тому же COMу. И
именно поэтому AnsiString со счётчиком ссылок, а WideString — без. Ещё
одна привязка к платформе — это "message WM_XXX;" в методе. Страшно
неприятный момент выкинутая поддержка COFF. Она была давно, но её
выкинули (по политическим соображениям, как я понял), а вы теперь
крутитесь как знаете.
5) мораль
Всё из перечисленного сделано как надо в Аде (кроме замыканий — они
есть, но там обёртки для API ещё нужно написать). И, собственно, зуб мой
на Delphi в том, что при всей его лоскутности, нецелостности, отсталости
и т. д. он перекрывает популярность, которую бы могла иметь Ада.
Перекрывает поток энтузиастов. Знай каждый паскалист Аду, было бы
столько библиотек, столько книжек и других ресурсов для Паскаля? FPC
вообще бы не состоялся за ненадобностью. Delphi — это как собака на сене
(на программистах, то есть)
Чем по сути занимаются разработчики Delphi и FPC? Они реализуют фичи,
которые давно были в Аде. Вот та же перегрузка операторов в Delphi
появилась только в 2006й версии. В Аде она была в 83ей. Шаблонов в
Delphi на данный момент нет. Опять же, в 83ей уже такой функционал был.
В Delphi недревовидное пространство имён, как в 83й Аде. В .NET
по–другому, но Delphi.NET — это отдельный разговор. Delphi по многим
пунктам отстаёт лет на 10-15 (справедливости ради отмечу, что интерфейсы
появились в Аде только в 2005й версии, но до этого их можно было
заменять mix-in'ами). Отставание будет только нарастать. Потому что
контора в первую очередь занимается GUI, в чём они преуспели, это факт.
Вирт от Паскаля отказался. Он исправил свои ошибки и воплотил свои
замыслы в Модуле и Обероне. Помимо школы Вирта, есть Ада. От Паскаля
отказались все, кто мог. Паскаль не умирает только из–за Borland. Есть
FPC, но он ИМХО индуцирован Delphi, без Delphi был бы только GPC.
Весьма активно работал в этой среде лет 5 назад (когда не было .NET, который свёл к нулю полезность этой среды). Что не нравилось:
1. Многа букв — ну это момент очень субъективный.
2. Слишком умный, часто не по делу, компилер. Когда использовал DirectX в дельфи — глюков получал из-за этой "умности" море — дико бесило
3. Серьёзные проблемы с юникодом в VCL
4. Поддержка готовых решений — в подавляющем большинстве случаев ужас — куда непонятных компонент, неясно откуда взятых и непонятно как работающих (а местами и не работающих ). Сама IDE подталкивает в такому использованию — edit28'ов повидал немало.
5. Отсутствие в винде рантайма для дельфей — в итоге гигантские модули.
6. Несовместимость разных версий IDE
7. Слишком строгая типизация — арифметика указателей очень быстро превращается в нечитаемую кашу из PDWORD(DWORD()). Особенно доставало опять же при работе с DX.
8. Необъяснимые проблемы при работе с Direct3D — непонятные ошибки, вылезающие в случайных местах. Гугл на них находил только аналогичные моему вопросы в основном без ответов
Чего хорошего можно написать такими неприличными символами?
:=
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
Здравствуйте, OCTAGRAM, Вы писали:
OCT>2) Чего не хватает: OCT>иерархическое пространство имён; -- тоже не хватает
Nested types появились в 2005/6. Или речь о другом?
OCT>объявление по месту; -- declare-begin-end — это удобно
Shift+Ctrl+V (Refactoring: Declare Variable). Не замена, но кого напрягает...
OCT>автоматическая финализация;
Есть, для управляемых типов.
OCT>встроенная многозадачность; -- актуально
Обещают в 2009. Не думаю, что сделают как в Ada, но чего-то сделать обещают.
OCT>битовые массивы размером более, чем 256 битов;
TBits.
OCT>размеры, не определённые на этапе компиляции; OCT>-- на самом деле, редко, когда заранее известно, сколько потребуется OCT>места для данных; использовать буфер статического размера — опуститься OCT>до уровня C, использовать динамический — overhead при OCT>выделении/освобождении; в C99 (?9 лет назад) эта константность в разных OCT>местах была убрана
Кроме статики и динамики какие еще варианты? А вообще Array Of xxxx.
OCT>3) не к самому Delphi, но в сравнении с Free Pascal OCT>Эти реализации разъезжаются. Free Pascal реализует фичи раньше, но в OCT>стиле C++. Borland реализует аналогичную фичу обычно позже, FPC уже OCT>догнал и перегнал Delphi. Но при этом Borland делает вид, что FPC нет, и OCT>реализует фичу в стиле Delphi.NET. Вот так, например, произошло с OCT>перегрузкой операторов. Чтобы написать математику с перегрузкой OCT>операторов переносимо, придётся знать и ту, и другую реализацию. Чем OCT>дальше в лес, тем больше дров. В 2008 появятся дженерики, а в FPC они OCT>уже есть.
В Delphi уже есть Nested types, а у FPC даже в планах нет Вроде и нормальный вариант-диспатчинг появился только-только... И вообще, с чего CodeGear должен ориентироваться на FPC, когда их уличали неоднократно (с горячими разборками в блогах) в прямом копировании кода VCL (читай в плагиате).
OCT>Delphi сильно заточен под платформу. И это не просто зависимость на OCT>уровне библиотек. Платформа определяла появление и реализацию фич. Вот OCT>взять те же интерфейсы, это ведь не просто интерфейсы, это интерфейсы OCT>COM.
Интерфейсы в Delphi появились имено благодаря COM, но это не COM интерфейсы
OCT>Причём, автоматическое уничтожение в интерфейсах есть, а в классах OCT>нет. И если класс реализует COM интерфейс, то работать с ним надо уже OCT>через этот интерфейс, потому что иначе можно пожать утечки памяти.
Это не совсем так TComponent -- являет собой пример класса имеющего интерфейсы, но требующего ручной сборки мусора. Это не минус и не плюс, это фича для тех кому нужно.
OCT>В нормальных языках классы и интерфейсы не отличаются друг от друга OCT>настолько.
И что же в этом хорошего?
OCT> WideString. Своим появлением обязан всё тому же COMу. И OCT>именно поэтому AnsiString со счётчиком ссылок, а WideString — без.
Так и есть. В 2008 обещают новый тип строк, что-то вроде UnicodeString.
OCT>Ещё одна привязка к платформе — это "message WM_XXX;" в методе.
Это чудесная вещь! Появилась благодаря Win API, но никакой привязки к платформе тут нет, ибо чудесно работало и в Kylix
OCT>Всё из перечисленного сделано как надо в Аде (кроме замыканий — они OCT>есть, но там обёртки для API ещё нужно написать). И, собственно, зуб мой OCT>на Delphi в том, что при всей его лоскутности, нецелостности, отсталости OCT>и т. д. он перекрывает популярность, которую бы могла иметь Ада. OCT>Перекрывает поток энтузиастов. Знай каждый паскалист Аду, было бы OCT>столько библиотек, столько книжек и других ресурсов для Паскаля? FPC OCT>вообще бы не состоялся за ненадобностью. Delphi — это как собака на сене OCT>(на программистах, то есть)
Я тоже полюбил Ada после прочтения RM95
OCT>Отставание будет только нарастать. Потому что OCT>контора в первую очередь занимается GUI, в чём они преуспели, это факт.
Справедливости ради, сейчас CodeGear взялась за язык (что еще развивать в GUI под нативом). Правят древние баги, добавляют языковые фичи. Роадмап у них, в принципе, интересный. В анкете интересовались вопросами кросплатформенности (Linux/MacOS)...
Здравствуйте, koandrew, Вы писали:
K>2. Слишком умный, часто не по делу, компилер. Когда использовал DirectX в дельфи — глюков получал из-за этой "умности" море — дико бесило
Он умный все же чаще по делу...
K>3. Серьёзные проблемы с юникодом в VCL
TNTControls не решает проблем?
K>4. Поддержка готовых решений — в подавляющем большинстве случаев ужас — куда непонятных компонент, неясно откуда взятых и непонятно как работающих (а местами и не работающих ). Сама IDE подталкивает в такому использованию — edit28'ов повидал немало.
IDE ни к чему не подталкивает. На начальном этапе, да, можно писать очень криво. Если это вошло в систему, ну... ССЗБ.
K>5. Отсутствие в винде рантайма для дельфей — в итоге гигантские модули.
Да, Майкрософт отказала влючать пакеты Borland'а в Windows. Политика.
K>6. Несовместимость разных версий IDE
А зачем мне совместимость IDE? Чего там совмещать?
K>7. Слишком строгая типизация — арифметика указателей очень быстро превращается в нечитаемую кашу из PDWORD(DWORD()). Особенно доставало опять же при работе с DX.
И кошек вы вероятно тоже не любите... Нет никакой проблемы с указателями -- можно использовать так, как только заблагороссудится. Можно типизированно, можно без типизации. Готовить нужно уметь
K>8. Необъяснимые проблемы при работе с Direct3D — непонятные ошибки, вылезающие в случайных местах. Гугл на них находил только аналогичные моему вопросы в основном без ответов
Я бы мог поставить диагноз... Но обижать не хочется
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
G>>Да даже не в этом дело. В C++ можно вернуть из метода экземпляр класса. В делфи нельзя. Ибо экземпляр — это ссылка, для которой явно надо вызвать Free.
J>Почему нельзя, можно конечно. J>
J>function TSameObject.CreateStringList: TStringList;
J>begin
J> Result := TStringList.Create;
J>end;
J>
Не смеши меня.
на C++
A f()
{
return A();
}
...
{
A x = f();
}//Здесь вызвовется деструктор ч
На Delphi
function TSameObject.CreateStringList: TStringList;
begin
Result := TStringList.Create;
end;
...
var x:TStringList;
begin
x:=SameObject.CreateStringList;
end; //А тут ничего не вызовется, получим утечку памяти
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
G>>Недостатки G>>1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет.
J>знаешь, нормальный дельфист сразу видет парные Create/Free. Приемущество c++ в том, что в нем объекты на стеке могут распологаться..
Конструкторы могут называтся как угодно. Банальным Ctrl+F уже не найдешь.
G>>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля) J>интерфейсы есть уже лет 10, наверно...
Да уж, только то COM-интерфейсы
G>>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля) G>>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля) J>хм. ранние — это какие?? такое ощущение, что ты знаешь только о delphi1
Я работал на делфях версий 2-7.
Перегрузка функций появилась в delphi 5 кажись, перегрузка операторов не было и в delphi 7
G>>5)Ужасная работа с указателями. (наследие паскаля) J>Что значит "ужасная" ??? Или строгая типизация тя не устраивает???
Отсутствие операций инкремента и декремента, а также невозможно указать типа указателя в месте использования.
G>>6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых междц собой). J>то есть в с++ — только один способ ввода/вывода??
Я всегда пользовался iostream и мне хватало.
G>>7)Практически полное отсутствие контейнерной библиотеки G>>8)Большенство классов являются неочень качественными обертками над WinAPI. J>в чем конкретно некачественность?? ТОка не надо описывать конкретные глюки отдельных компонентов, такие вещи есть в любой библиотреке классов. В
чем некачественность на уровне Classes.pas/Controls.pas/Forms.pas ??
Класс TThread. 1)Не позволяет узнать завершился ли поток — надо использовать WinAPI. 2)Непонятен в использовании (из-за наследования), на первой работе неделю ловили баг из-за неправильного использования Thread. Человек банально скопировал код из примера и сам чего-то дописал. 3)Потоки есть — а примитивов синхронизации в VCL нет, приходится снова юзать WinAPI
G>>9)Исполняемые файлы получаются очень тяжеловесными. J>Хм. Ну давай я статически слинкую mfc exe'шник и сбилжу пустую форму на дельфи с ран-тайм пакетамм — и скажу MSVC — генериит очень тяжеловесные экзешники.
А почему Borland C++ Builder собирает exeшники в 3-4 раза меньшие по объему?
G>>Я могу продолжить, но думаю этого хватит. J>В принципе этого хватит. Уже видно, что все твои знания о дельфи почерпнуты из холли-варов на рсдн..
Делфи с 7 класса школы изучал и 2 года работал.
Здравствуйте, gandjustas, Вы писали:
G>Недостатки G>1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет.
Не совсем верно. Сборка мусора была — Free можно было забыть вызвать.
А ссылочная объектная модель — что в этом плохого?
G>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля)
Зато были делегаты (нет необходимости в интерфейсах), виртуальные конструкторы (вроде, сам уже плохо помню) и еще много чего.
G>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля)
Шаблон — это скорее развитый препроцессор. Препроцессор отношения к языку не имеет (что мне мешает взять и мои исходники на дельфях обработать препроцессором того же gcc?).
G>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля)
Ну отсутствие перегрузки функций я по ходу и не застал, а вот с операторами не очень понятно надо ли оно — ручной парсинг такого кода крайне сложен (т.е. сложно въехать в чужой проект).
G>5)Ужасная работа с указателями. (наследие паскаля)
Спорный вопрос. Нормально работалось (ну требовалось иногда явное приведение типов, но это, ИМХО, только читабельность повышало.
G>6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых между собой).
Ну по сравнению с каким-нибудь char *, CString и std::string — это еще было не так все плохо
G>7)Практически полное отсутствие контейнерной библиотеки
G>8)Большенство классов являются неочень качественными обертками над WinAPI.
G>9)Исполняемые файлы получаются очень тяжеловесными.
Зато самодостаточными (за редким исключением).
Кстати, возможность собрать более легкий файл, но с зависимостями тоже была
G>>>5)Ужасная работа с указателями. (наследие паскаля) J>>Что значит "ужасная" ??? Или строгая типизация тя не устраивает??? G>Отсутствие операций инкремента и декремента, а также невозможно указать типа указателя в месте использования.
Подробнее? Все было...
G>>>6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых междц собой). J>>то есть в с++ — только один способ ввода/вывода?? G>Я всегда пользовался iostream и мне хватало.
Я всегда пользовался read/write и мне хватало
G>>>9)Исполняемые файлы получаются очень тяжеловесными. J>>Хм. Ну давай я статически слинкую mfc exe'шник и сбилжу пустую форму на дельфи с ран-тайм пакетамм — и скажу MSVC — генериит очень тяжеловесные экзешники. G>А почему Borland C++ Builder собирает exeшники в 3-4 раза меньшие по объему?
А ты его запусти на другой машине — быстро поймешь
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
_>>>В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин? G>>Автоматическая сборка мусора. H>И неконтролируемая... Из-за которой, порой, возникают прелесные фризы на ровном месте.
За год работы на .NET ни одного случая не видел, вам видимо везет.
_>>>Кстати, сборка мусора для некоторых типов данных (строки и динамические массивы) у Delphi была уже тогда. G>>Это не преимущество, а попытка скрыть недостатки. H>Да ты что? Управляемая (читай контролируемая) сборка мусора это недостаток? Я еще добавлю, что Delphi и за интерфейсами сама следит.
А как еще можно было сделать динамические строки и массивы, но не нагружать программиста вызовами Free?
В C++ автоматически вызывается деструктор по выходу из scope.
За интерфейсам следит не делфи, за интерфейсам следит комилятор, фактически вставляя вызов Release для интерфейса, что может потянуть кучу необъяснимых глюков. Да и разная семантика работы с классами, реазиующими интрфейсы и нереалзующими их — тоже немалый недостаток.
G>>Да, синтаксис паскаля многословный очень. Особенно бесило Procedure и Function. Это все при том, что почти не было поддержки со cтороны IDE. H>Чет я не понял... Чего тебе IDE должна поддерживать в процедуре или функции?
Delphi 7 нажимаешь ctrl+space begin, end, procedure, function он и не думает завершать.
G>>1)ссылочная обьектная модель в отсутствии сборщика мусора. надо явно вызывать Free для каждого объекта, что многие забывают. В С++ с этим проще, визуально несложно проверить парность new и delete. В деляфх гораздо сложнее из-за синтаксиса вызова конструктора. В С# вообще такой проблемы нет. H>Уж и не знаю кому сложнее, но старому Паскалисту сильно проще чем в C++
Ну смотри пример выше. сылочная объектная модель без GC вносит ограничения, которые невозможно обойти.
Хотя я не сомневаюсь что старому паскалисту делфи гораздо легче чем С++.
В приниче этим и объясняется распространение делфи в России (на западе такого не было), в школах и вузах традиционно учат паскалю.
G>>2)Отсутствие интерфейсов и множественного наследования. (наследие паскаля) H>Интерфейсы есть с очень древней (3/4) версии. А в шарпе делегирование оных есть уже?
COM — нитерфейсы. К ООП они вообще мало отношения имеют. Делегирование интерфейсов в шарпе нет по тойже причине. Если поковыряться с интеропом, то возможно что-то подобное есть и на .NET. Но мне не доводилось таким заниматься.
G>>3)Отсутствие Generic типов или шаблонов любого вида. (наследие паскаля) H>Дженерики есть в 2007 под .Net. В 2008 обещают и для нативного кода.
Мда... Это на фоне того, что появилось в C# 3.0 в 2007 году. Делфи тут оооочень сильно отстает.
G>>4)Отсутствие перегрузки функций (в ранних версиях) и операторов (вплоть до поздних). (тоже наследие паскаля) H>Перегрузка функций/методов есть с 4 версии. Операторы можно перегружать уже с 2005 (для классов только под .Net, для натива можно перегружать для advanced records (class-like)). А с 2006 есть еще и перегружаемые свойства-массивы. Можно еще добавить class/record хелперы.
А с какого года это есть в C++? Тут очевидно стремление delphi догнать С#
G>>5)Ужасная работа с указателями. (наследие паскаля) H>Конкретика? Типизация указателей имеется со времен... очень давно в общем имеется. Адресная арифметика на уровне. Чего не нравится?
то что надо явно объявлять тип указателя и отсутствие инкремента\декремента
G>>6)Невнятная библиотека ввода-вывода (на самом деле несколько возможностей осуществлять IO, несовместимых междц собой). H>Чудесная библиотека ввода/вывода (позволяющая при умении заворачивать интереснейшие вещи без участия низкоуровневых API).
Пример в студию.
G>>7)Практически полное отсутствие контейнерной библиотеки H>Списки (различные), стеки, очереди, бит-контейнеры, ассоциативные массивы. Мало?
Это оно когда появилось? Случаем не в Delphi.NET ?
H>И вправду можешь не продолжать... Ты явно не в теме (ну, или сильно субъективен, что аж перекашивает).
Я на Delphi писал большую часть моей программистской жизни.
А вы на C# попробуйте пописать, сразу поймете.
Здравствуйте, misha_irpen, Вы писали:
_>Я с уверенностью могу сказать, что могу написать на нем абсолютно все что угодно в рамках имеющихся API и математических моделей. При этом практически никогда не приходится изобретать велосипедов и извращаться чтобы обойти ограничения языка или стандартных библиотек. В чем по вашему мнению я заблуждаюсь? Что такого рулезного есть в новомоюдых сишарпах и иже с ними кроме монстровидных, а часто еще и тормозных RTE/виртуальных машин?
По мне так сишарпы — это дальнейшее развитие тех же идей. Пока я 5 лет на дельфях программировал, тоже казалось, что все задачи можно решить и всё замечательно. Вопрос в том, насколько эффективно это можно сделать. Например, рассмотрим обобщённый алгоритм сортировки. Чтобы сделать его обобщённым в Delphi, ему нужно передовать указатель на функцию сравнения. А в C++, благодаря наличию шаблонов, функция сравнения может быть inline'ом вкомпилирована в саму сортировку. Если речь идёт о сортировке обычных чисел, то это даёт прирост производительности в несколько раз, т.к. простое сравнение чисел в несколько раз быстрее вызова функции с передачей параметров и последующего возврата из неё.
Также C++ даёт возможность размещать классы не только в куче, но и в стеке и в глобальной памяти. Деструкторы объектов вызываются автоматически, даже в случае исключения. Это позволяет эффективно управлять временем жизни объектов в большинстве случаев обходясь без ручного выделения/освобождения, да плюс ещё заворачивания в try/finally блок. Ну и т.д.
Здравствуйте, lifrsdn, Вы писали:
L>Что хотелось бы иметь:
L>1. Объявление переменных в месте использования. Не критично, но ползти в var неприятно.
На вкус и цвет — когда в одном месте, оно читабельнее. L>2. Переопределяемых операторов. Часто сложная математика выглядит с ними привычнее. Читать потом тяжко...
CString str;
...
(char *)str //вот и пойми, что это перегруженный оператор на самом деле :xz:
L>3. Вынесу отдельно — возможности построения типов с поведением, как у стандартных.
А подробнее? Вроде все строилось как надо...
L>4. Препроцессор. Да его ругают, но лучше иметь возможность его использовать.
Используй внешний (и отлаживаться проще).
J>хм. прочем тут дельфи? Утечки памяти были, есть и будут во всех языках без GC
GC в Дельфи был. И очень неплохой — они использовали собственный менеджер памяти (из-за этого программа на дельфи кушала память большими кусками, по 10 Мб, если мне не изменяет память).
Здравствуйте, Don Reba, Вы писали:
DR>Если в программе вместо буков вопросительные знаки — значит она написана на Дельфи.
DR>Не нравится Дельфи из за типично чрезвычайно низкого качества написанных на ней программ. Троечники собирают на этом небезопасном языке свои компоненты из компонентов написанных другими троечники, а конечные программы являются результатом нескольких итераций этого процесса.
Что-то мне подсказывает, что еще пара лет и так же начнут хаять .Net с C#...
). Сама IDE подталкивает в такому использованию — edit28'ов повидал немало.
TComponent -- являет собой пример класса имеющего интерфейсы, но требующего ручной сборки мусора. Это не минус и не плюс, это фича для тех кому нужно.
Нет никакой проблемы с указателями -- можно использовать так, как только заблагороссудится. Можно типизированно, можно без типизации. Готовить нужно уметь 
