Дело не во фразе — дело в логике.
Delphi всю свою историю прежде всего предназначалась для GUI-приложений на платформе Win32 и там она до сих пор более чем актуальна (простота создания пользовательских интерфейсов, COM-объектов, клиентов различных СУБД и т.п. до сих пор не превзойдена благодаря сочетанию выразительности и читабельности языка). И требовать решительных успехов в неродных областях — значит проявлять заведомую предвзятость.
Кстати, пока не видел ни в одном статически типизированном языке встроенной поддержке агрегирования.
Считать тот же Skype проектом мелким или не успешным можно тоже только от большого желания повоевать.
Как раз эти самые ошибки «другого рода» и заставляют мучительно искать места утечек.
При автоматическом освобождении нужно не забыть обнулить все ссылки на объект… иначе утечки никуда не денутся.
Так что сборка мусора полезна, но избавляет только от сравнительно простых ошибок, которые легко обнаруживаются и без нее. ИМХО для хорошего разработчика польза (в плане избавления от ошибок) сводится к уменьшению сложности на константу, причем небольшую.
> Я пока понял (а скорее просто сам знаю), что на Delphi можно решать те же задачи и с неменьшими (а порой и с гораздо бОльшими) трудозатратами, что и на других средствах, плюс он значительно менее популярен
Ну вот и классика подоспела — человек ничего не знает о предмете, не дает никакой конкретики, но заявляет что знает и жалуется на отсутствие конкретики у оппонентов.
> Грубо говоря, есть при использовании Delphi приходится тратить в 3 раза больше ресурсов, чем на (к примеру) C#, то и разработка будет в 3 раза дороже.
У этого аргумента есть только один недостаток — он не соответствует действительности.
SciTE — подходит по всем пунктам без исключения.
Использую его, так как он не требует инсталляции, легко интегрируется с любыми консольными инструментами, позволяет легко не терять пользовательских настроек при смене версии, расширяется Lua-скриптами, хорошо документирован.
Предложение интересное, но излишне сложное в реализации, хотя достоинства его очевидны.
Стоит рассмотреть, а не будет ли простой игнор эффективнее сложного бота?
Если посты пользователя, помеченного как тролля, будет видеть только он сам и другие тролли, а для гостевого доступа выставить лаг в 10-30 минут, то тролление станет очень неинтересным занятием даже для того, кому заранее известно про данный механизм контроля. Причем чем больше троллей — тем выше эффективность (начиная с какого-то момента они вообще переходят на самообеспечение, кормя друг дружку), а чем меньше — тем меньше нужда в автоматике (модератор спокойно справится и сам).
Пример из RTL Delphi. Этот код создает класс при десериализации его из потока.
procedure CreateComponent;
var
ComponentClass: TComponentClass;
begin
try
ComponentClass := FindComponentClass(CompClass);
Result := nil;
if Assigned(FOnCreateComponent) then
FOnCreateComponent(Self, ComponentClass, Result);
if Result = nil then
begin
Result := TComponent(ComponentClass.NewInstance);
if ffInline in Flags then
begin
Include(Result.FComponentState, csLoading);
Include(Result.FComponentState, csInline);
end;
try
Result.Create(Owner);
except
Result := nil;
raise;
end;
end;
Include(Result.FComponentState, csLoading);
except
if not Recover(Result) then raise;
end;
end;
А для не полностью сконструированных конструктор должен все сделать сам. RAII помогает, конечно, но тем не менее дельфийский подход требует намного меньше труда и внимания — достаточно лишь аккуратно написать деструктор.
Формулировка и впрямь слишком резкая. Точнее, бросать исключения из конструктора в C++ требует гораздо больше труда и внимательности, так как деструктор при этом вызван не будет, а неинициализированные части объекта содержат мусор. В результате за очистку при прерывании инициализации отвечает конструктор, не имея вдобавок простых средств для отделения зерна от плевел.
Со стороны C++-программиста на проблему можно посмотреть по ссылке: alenacpp.blogspot.com/2006/11/blog-post.html
Вряд ли ошибка (если это именно ошибка) была совершена в 92-93 — Delphi вплоть до седьмой версии включительно был более чем на уровне.
Оптимальное время миграции — выход Delphi 8 под .NET. Именно тогда был взят гибельный курс. А вообще лично я не вижу проблемы для программиста с переходом на .NET и сейчас (если, конечно, нет жестких ограничений по времени и заработку прямо сейчас). И не наблюдаю реальных альтернатив Delphi для Win32.
Есть такие, но из них извлечь реальную пользу, ничего не порушив, куда сложнее.
Хорошо в них то, что оба имеют дело уже с «боевым» объектом, причем если AfterConstruction возбуждает исключение, то сначала вызовется BeforeDestruction, а уж потом деструктор.
Да, имеет смысл упомянуть, что FreeAndNil еще и висячей ссылки за собой не оставляет.
Free не поминал специально, так как считаю его применение в деструкторах (и вообще везде, кроме тех мест где FreeAndNil задействовать невозможно) неправильным.
Почему — успешно объяснено до меня и без меня по ссылке: gunsmoker.blogspot.com/2009/04/freeandnil-free.html
Учитывая что язык давно уже называется Delphi — неудивительно :)
А «вызов» — слово не слишком удачное, так как после возбуждения исключения в Delphi никакого возврата (как при «нормальных» вызовах) не происходит по определению.
Delphi всю свою историю прежде всего предназначалась для GUI-приложений на платформе Win32 и там она до сих пор более чем актуальна (простота создания пользовательских интерфейсов, COM-объектов, клиентов различных СУБД и т.п. до сих пор не превзойдена благодаря сочетанию выразительности и читабельности языка). И требовать решительных успехов в неродных областях — значит проявлять заведомую предвзятость.
Кстати, пока не видел ни в одном статически типизированном языке встроенной поддержке агрегирования.
Считать тот же Skype проектом мелким или не успешным можно тоже только от большого желания повоевать.
При автоматическом освобождении нужно не забыть обнулить все ссылки на объект… иначе утечки никуда не денутся.
Так что сборка мусора полезна, но избавляет только от сравнительно простых ошибок, которые легко обнаруживаются и без нее. ИМХО для хорошего разработчика польза (в плане избавления от ошибок) сводится к уменьшению сложности на константу, причем небольшую.
Ну вот и классика подоспела — человек ничего не знает о предмете, не дает никакой конкретики, но заявляет что знает и жалуется на отсутствие конкретики у оппонентов.
У этого аргумента есть только один недостаток — он не соответствует действительности.
Использую его, так как он не требует инсталляции, легко интегрируется с любыми консольными инструментами, позволяет легко не терять пользовательских настроек при смене версии, расширяется Lua-скриптами, хорошо документирован.
Стоит рассмотреть, а не будет ли простой игнор эффективнее сложного бота?
Если посты пользователя, помеченного как тролля, будет видеть только он сам и другие тролли, а для гостевого доступа выставить лаг в 10-30 минут, то тролление станет очень неинтересным занятием даже для того, кому заранее известно про данный механизм контроля. Причем чем больше троллей — тем выше эффективность (начиная с какого-то момента они вообще переходят на самообеспечение, кормя друг дружку), а чем меньше — тем меньше нужда в автоматике (модератор спокойно справится и сам).
procedure CreateComponent; var ComponentClass: TComponentClass; begin try ComponentClass := FindComponentClass(CompClass); Result := nil; if Assigned(FOnCreateComponent) then FOnCreateComponent(Self, ComponentClass, Result); if Result = nil then begin Result := TComponent(ComponentClass.NewInstance); if ffInline in Flags then begin Include(Result.FComponentState, csLoading); Include(Result.FComponentState, csInline); end; try Result.Create(Owner); except Result := nil; raise; end; end; Include(Result.FComponentState, csLoading); except if not Recover(Result) then raise; end; end;Со стороны C++-программиста на проблему можно посмотреть по ссылке: alenacpp.blogspot.com/2006/11/blog-post.html
Оптимальное время миграции — выход Delphi 8 под .NET. Именно тогда был взят гибельный курс. А вообще лично я не вижу проблемы для программиста с переходом на .NET и сейчас (если, конечно, нет жестких ограничений по времени и заработку прямо сейчас). И не наблюдаю реальных альтернатив Delphi для Win32.
Хотя собственный родитель (Borland) приложил очень много усилий к организации «дельфицида».
Хорошо в них то, что оба имеют дело уже с «боевым» объектом, причем если AfterConstruction возбуждает исключение, то сначала вызовется BeforeDestruction, а уж потом деструктор.
Free не поминал специально, так как считаю его применение в деструкторах (и вообще везде, кроме тех мест где FreeAndNil задействовать невозможно) неправильным.
Почему — успешно объяснено до меня и без меня по ссылке: gunsmoker.blogspot.com/2009/04/freeandnil-free.html
А «вызов» — слово не слишком удачное, так как после возбуждения исключения в Delphi никакого возврата (как при «нормальных» вызовах) не происходит по определению.