Comments 74
Собственно, интересны ваши впечатления от запуска такого приложения на устройстве.
А чем такое приложение должно отличаться от любого другого?
весом?)
Скоростью работы?
Требованиями к версии ОС и устройству?
А вот вы не правы. Приложение, написанное в XE5, прекрасно работает на Galaxy Tab первой модели под Android 2.3 и 2.2 (старее я просто уже не нашёл).
В чем я не прав? Я не утверждал, что оно там не работает. Наоборот, мне интересно узнать, где оно работает, а где нет.
Вот тут (http://docwiki.embarcadero.com/RADStudio/XE5/en/FireMonkey_Platform_Prerequisites) написано:
RAD Studio supports the development of applications for Android devices running on an ARMv7 processor with NEON support.
Вот тут (http://docwiki.embarcadero.com/RADStudio/XE5/en/FireMonkey_Platform_Prerequisites) написано:
RAD Studio supports the development of applications for Android devices running on an ARMv7 processor with NEON support.
Вот официальный список поддерживаемых устройств
docwiki.embarcadero.com/RADStudio/XE5/en/Android_Devices_Supported_for_Application_Development#Results_of_Our_Android_Device_Testing
Вот ещё статья про это
www.tdelphiblog.com/2013/10/sovmestimostjandroididelphi.html
docwiki.embarcadero.com/RADStudio/XE5/en/Android_Devices_Supported_for_Application_Development#Results_of_Our_Android_Device_Testing
Вот ещё статья про это
www.tdelphiblog.com/2013/10/sovmestimostjandroididelphi.html
Спасибо. Вот эта статистика снимает все вопросы:
Проверено устройств: 118
Не установилось на: 10
Зависло (Application not responding) на: 3
Успешно запустилось на: 105
Процент успеха: 89%
Но там проверяли Hello World, на более сложных приложениях проблем будет, очевидно, больше.
Проверено устройств: 118
Не установилось на: 10
Зависло (Application not responding) на: 3
Успешно запустилось на: 105
Процент успеха: 89%
Но там проверяли Hello World, на более сложных приложениях проблем будет, очевидно, больше.
Уверен, что реально работает практически на всём. Поясню почему.
Использовались, судя по всему, не тесты, а кривые «антитесты». Почитал про свой аппарат:
Samsung Galaxy Tab2 10 Bug reported about Location Demo and Audio Recording
Обиделся. Это же не клон какой-то, это наоборот то, с чего все клоны и делаются. Я его специально для разработки брал, чтобы был самый что ни есть стандартный.
Посмотрел Location Demo. Запустил. Действительно, показывает, что я в Канзасе. Видимо, и Тотошка с Железным Дровосеком где-то рядом. А долгота-широта-то сверху на лейблах — правильные!
Смотрим текст. В Гугл-мап строку передаются координаты, полученные через ToString. В России, я так понимаю, будут они с десятичными запятыми. Ищем 1 мин и находим, как надо эту строку формировать:
support.google.com/maps/answer/18539?hl=ru
Прямо сказано, что через точку. А цепкому глазу к тому же видно, что после точки — 5 знаков. Не 6, не 123, а пять! Переписываем процедуру из демки:
Запускаем. Показывает улицу, дом. Чуть ли не квартиру. Всё правильно.
Я вот сижу и думаю — а сколько в Эмбаркадеро писателям тестов платят, может, устроиться? И сразу всё на всём заработает как часы…
Использовались, судя по всему, не тесты, а кривые «антитесты». Почитал про свой аппарат:
Samsung Galaxy Tab2 10 Bug reported about Location Demo and Audio Recording
Обиделся. Это же не клон какой-то, это наоборот то, с чего все клоны и делаются. Я его специально для разработки брал, чтобы был самый что ни есть стандартный.
Посмотрел Location Demo. Запустил. Действительно, показывает, что я в Канзасе. Видимо, и Тотошка с Железным Дровосеком где-то рядом. А долгота-широта-то сверху на лейблах — правильные!
Смотрим текст. В Гугл-мап строку передаются координаты, полученные через ToString. В России, я так понимаю, будут они с десятичными запятыми. Ищем 1 мин и находим, как надо эту строку формировать:
support.google.com/maps/answer/18539?hl=ru
Прямо сказано, что через точку. А цепкому глазу к тому же видно, что после точки — 5 знаков. Не 6, не 123, а пять! Переписываем процедуру из демки:
procedure TLocationForm.LocationSensor1LocationChanged(Sender: TObject;
const OldLocation, NewLocation: TLocationCoord2D);
const
LGoogleMapsURL: String = 'https://maps.google.com/maps?q=%s,%s&output=embed';
var
latS, lonS: string;
begin
{ convert the location to latitude and longitude }
Str(NewLocation.Latitude:8:5, latS);
Str(NewLocation.Longitude:8:5, lonS);
lbLatitude.Text := 'Latitude: ' + NewLocation.Latitude.ToString;
lbLongitude.Text := 'Longitude: ' + NewLocation.Longitude.ToString;
{ and track the location via Google Maps }
// WebBrowser1.Navigate(Format(LGoogleMapsURL, [NewLocation.Latitude.ToString, NewLocation.Longitude.ToString]));
WebBrowser1.Navigate(Format(LGoogleMapsURL, [latS, lonS]));
end;
Запускаем. Показывает улицу, дом. Чуть ли не квартиру. Всё правильно.
Я вот сижу и думаю — а сколько в Эмбаркадеро писателям тестов платят, может, устроиться? И сразу всё на всём заработает как часы…
Через это проходят все пользователи их продуктов. Я таким образом менеджер пакетов для Дельфы сделал. Штатные средства — это ужас.
Если про отличия от десктопного приложения — то в первую очередь дизайном интерфейса (ну, понятно, один палец для работы, никаких всплывающих меню и т.п.). А по памяти и быстродействию гаджеты уже догоняют десктопы. Вот у меня на Tab-2 — 1 Gb ОЗУ. Даже неизвестно, чем его можно израсходовать — программа моя ела, я смотрел, лишь 70 Mb. Быстродействие, конечно, пока сильно отстаёт, ну, так не нагружать слишком!
Если запускать напрямую с устройства готовую Release сборку, всё работает очень быстро. Я вообще никаких задержек не заметил. Единственно, запуск занимает 3-4 сек, и при этом чёрный экран. Кажется, что долго. Для сравнения запустил Маркет. Те же 4 сек. Только он сразу показывает верхнюю панель и выставляет крутящийся курсор ожидания, потому кажется, что запустился мигом. Вообще надо было бы какой-нибудь сплеш сделать, да времени не хватило.
Резюмируя — задержек при работе нет, и надо обязательно делать сплеш, чтобы не светить чёрный экран при запуске. Как сделать — вроде на каком-то форуме про это видел, надо опять поискать.
Резюмируя — задержек при работе нет, и надо обязательно делать сплеш, чтобы не светить чёрный экран при запуске. Как сделать — вроде на каком-то форуме про это видел, надо опять поискать.
Может быть Вы об этом?
Столько лишних операторов, на Java Будет и быстрее и лучше.
Чую набегут делфи-хейтеры и заминусуют всё и вся. Я например рад, что можно разрабатывать под андроид на любимом делфи, и судя по отзывам, с производительностью всё нормально.
Вопрос только в том, сколько стоит «любимое делфи» и зачем его покупать, есть на джаве все сделать проще и быстрее?
UFO just landed and posted this here
Я вас скажу по секрету, что переписать логику с нуля с джавы на шарп стоило сопоставимо покупки лицензии на делфи. Иногда лучше начать с нуля.
UFO just landed and posted this here
Вот оригинал, а вот порт на айос Спортировать джаву на шарп не составляет особого труда.
Мне кажется, корректней будет Delphi сравнивать с Xamarin. По цене и возможностям, если я правильно вижу, они похожи.
UFO just landed and posted this here
Это если у вас есть дефли специалисты и вы уверены в том, что стоит инвестировать в делфи.
UFO just landed and posted this here
Если надо писать хорошее приложение на маркет, то надо делать две отдельные версии для IOS и Android, если писать игру, то можно на юнити написать кросплатформ.
Написать на Делфи, теоретически можно что то с кнопочками для внутреннего пользования, владельцы айфонов на такое не клюнут.
Написать на Делфи, теоретически можно что то с кнопочками для внутреннего пользования, владельцы айфонов на такое не клюнут.
UFO just landed and posted this here
А я вот не троллинга ради а интереса для хочу спросить: а вот делфи пока под мобайл не было, бизнес-приложений на айпадах тоже не было?
Я тут Java не пользовался, но в студии вполне за 4 дня накидал бизнес приложение… с геолокацией, картой, чтением QR кодов, ну в общем все как по последней моде и нативненько… Хотя конечно до этого 3 дня репу чесал к чему подступиться… :)) До этого Objective C кусал, ничего докусался, таки интегрировал в мармелад GPUImage, да написал пару фишек и заменил модуль звука мармелада с ихнего на свой нативненький так сказать, работало лучше в разы. Но с объективом возился дольше намного. больше сложно синтаксис осилить не взорвав мозг. Зато теперь рад, что могу продолжаь изучение Java и Objective C.
Дешевле нанять C# программиста и купить ему лицензию на Xamarin. И лучше выйдет и платформа гораздо стабильней чем Делфи.
Изучил Ваш блог и нашел 2 весьма интересных поста.
Первый пост — про разницу в реализации модальных форм на десктопе и мобильных девайсах. Да, в Android при запуске каждого окна старое не ожидает, пока новое закроется. Но ведь и колбеки не используются, потому что Android может в любой момент закрыть предыдущие окна, даже если они ожидают результата от других окон. Все компоненты действительно разделены и при необходимости будут убираться из памяти. В случае же Delphi в памяти будут висеть все предыдущие окна, так как они получают результаты в виде колбека, в котором могут модифицироваться элементы окна, где этот колбек был создан. Если уж стандартное поведение Андроида не используется, не проще было бы в собственной графической песочнице эмулировать привычное дельфистам поведение? Не говоря уже, что так лучше для кроссплатформенности.
Второй пост — про то что линии с одинаковой толщиной рисуются в Delphi по разному. В нашем Преферансе достаточно серьезно используется Canvas из Android SDK и такая проблема неведома. Координаты и размеры линий задается в числах с плавающей точкой и выглядят на экране сглажено и одинаково. Можете посмотреть на скриншоты пули в Android-версии преферанса. С градиентами и изогнутыми линиями. Мне страшно представить, каких бы усилий стоило бы нарисовать такое в Delphi.
Возникает вопрос — а не проще ли использовать нативный и предсказуемый инструмент, чем искать, как обходить баги вот в таком вот «кроссплатформенном»? Я уж не представляю, что будет, когда придется искать какую-то платформозависимую багу.
Еще вопрос, почему такой довольно взрослой и недешевой среде для каждой новой версии требуются патчи от некоего Andreas Hausladen? Неужели в такой бизнес-ориентированной компании как Embarcadero не могут нанять квалифицированный QA отдел и программистов, которые имея полный исходный код фиксили бы те баги, которые один скромный программист фиксит, имея лишь дизассемблер?
Кстати, по блогам и форумам пишут, что на FireMonkey нету контрола для отображения HTML. Врут? В Android и iOS SDK такие есть.
Первый пост — про разницу в реализации модальных форм на десктопе и мобильных девайсах. Да, в Android при запуске каждого окна старое не ожидает, пока новое закроется. Но ведь и колбеки не используются, потому что Android может в любой момент закрыть предыдущие окна, даже если они ожидают результата от других окон. Все компоненты действительно разделены и при необходимости будут убираться из памяти. В случае же Delphi в памяти будут висеть все предыдущие окна, так как они получают результаты в виде колбека, в котором могут модифицироваться элементы окна, где этот колбек был создан. Если уж стандартное поведение Андроида не используется, не проще было бы в собственной графической песочнице эмулировать привычное дельфистам поведение? Не говоря уже, что так лучше для кроссплатформенности.
Второй пост — про то что линии с одинаковой толщиной рисуются в Delphi по разному. В нашем Преферансе достаточно серьезно используется Canvas из Android SDK и такая проблема неведома. Координаты и размеры линий задается в числах с плавающей точкой и выглядят на экране сглажено и одинаково. Можете посмотреть на скриншоты пули в Android-версии преферанса. С градиентами и изогнутыми линиями. Мне страшно представить, каких бы усилий стоило бы нарисовать такое в Delphi.
Возникает вопрос — а не проще ли использовать нативный и предсказуемый инструмент, чем искать, как обходить баги вот в таком вот «кроссплатформенном»? Я уж не представляю, что будет, когда придется искать какую-то платформозависимую багу.
Еще вопрос, почему такой довольно взрослой и недешевой среде для каждой новой версии требуются патчи от некоего Andreas Hausladen? Неужели в такой бизнес-ориентированной компании как Embarcadero не могут нанять квалифицированный QA отдел и программистов, которые имея полный исходный код фиксили бы те баги, которые один скромный программист фиксит, имея лишь дизассемблер?
Кстати, по блогам и форумам пишут, что на FireMonkey нету контрола для отображения HTML. Врут? В Android и iOS SDK такие есть.
А вот хочется писать на любимом делфи. А на нелюбимой яве — не хочется.
Спасибо за информацию. Всё никак не соберусь посмотреть на последние версии Дельфи, хотя пишу на нем уже много лет. С появлением поддержки Android думал уже пересесть на ХЕ5, но прочел довольно много критических обзоров — мол, совсем сырая эта поддержка. Как по Вашим ощущениям, можно что-то серьезное написать, или баловство всё это?
Ну по моим ( я не автор статьи, но пробывал ) ощущениям хорошее приложение, занимающее топы вы врятли напишете, но вот специфическое ПО — вполне. Например можно организовать работу выездных специалистов с планшетом. Банальные примеры: инвентаризация на складе, учет техники, техосмотр с занесением всего в журнал. Быстро создать такое приложение вполне возможно. Да и не только такое. Чисто на производстве для внутренних корпоративных целей очень даже подходит, особенно если уже есть специалисты по делфи, а обычно в этом сегменте их есть у них.
Я тоже читал подобные отзывы (сырая и т.п.). Пост и посвящен в том числе развенчанию некоторых таких легенд. 3D я, например, использовать не стал, да для этого есть та же Юнити с тесселяциями и скелетными анимациями.
А вот что-то «обычное» — панели, кнопки, списки, сетки — это вполне можно делать на Делфи. Если там ещё с базой надо общаться — тогда именно на Делфи (а на чём же ещё?!). Она всегда была именно под это и заточена.
Надеюсь, с конкурса чего-нибудь опубликуют для всеобщего обозрения, вот и посмотрим, что там и насколько серьёзное получилось. У меня-то программа несерьёзная выложена, но красивая. Анимации, звуки и прочее (в 2D).
Будет интересно посмотреть, что у кого получилось.
А вот что-то «обычное» — панели, кнопки, списки, сетки — это вполне можно делать на Делфи. Если там ещё с базой надо общаться — тогда именно на Делфи (а на чём же ещё?!). Она всегда была именно под это и заточена.
Надеюсь, с конкурса чего-нибудь опубликуют для всеобщего обозрения, вот и посмотрим, что там и насколько серьёзное получилось. У меня-то программа несерьёзная выложена, но красивая. Анимации, звуки и прочее (в 2D).
Будет интересно посмотреть, что у кого получилось.
Спасибо, пишите еще.
Меня больше всего интересует производительность FMX. Последний раз я пробовал работать с FM на Delphi XE3, и производительность меня очень не порадовала. Мне всего-то нужен был примерно такой список:
Само собой элементы списка должны уметь динамически меняться. На них появляются прогрессбары, в момент загрузки, статус загрузки и т.п. иногда на них анимация может крутиться.
Я реализовал этот список. Закинул в него около 150-200 элементов, и оно стало заметно подтормаживать, особенно заметно на скроллинге. И это всего лишь один список. Для меня это оказалось не приемлемо, ибо у меня машина не самая слабая, а приложение я хотел очень легкое, шустрое и отзывчивое. Подобные списки с тысячами элементов, сортировками, поисками и всем чем только можно — я прекрасно реализую на TVirtualTreeView, и оно на VTV работает на порядки шустрее с десятками тысяч — чем этот чудосписок со 100 элементами. Список на картинке как раз на VTV.
Собственно вопрос, улучшилась ли ситуация в XE5? А то тут говорят производительность норм… Насколько сложный был гуй? Было что-то сложнее картинки, трех кнопок и двух чекбоксов? Просто на FMX который был в Delphi XE3 написать что-то по сложности сопоставимое с Delphi IDE — невозможно на том FMX который с ним поставлялся. Простенькое приложение написать можно, но зачем оно на мобильных платформах? Батарею жрать? А на десктопах под винду — VCL шустрее.
p.s. У меня есть наработки типа библиотеки контролов, которые используют OpenGL для вывода графики. Когда то, когда навелосипедил для себя (когда еще никаких этих FireMonkey не было). Плюнул развивать это дело, когда выкатили FMX c XE. Но даже сейчас мои контролы работают шустрее. Потому что я заморачивался по поводу оптимизаций. Эх, знал бы что этот цирк с FMX затянется так…
Картинко
Само собой элементы списка должны уметь динамически меняться. На них появляются прогрессбары, в момент загрузки, статус загрузки и т.п. иногда на них анимация может крутиться.
Я реализовал этот список. Закинул в него около 150-200 элементов, и оно стало заметно подтормаживать, особенно заметно на скроллинге. И это всего лишь один список. Для меня это оказалось не приемлемо, ибо у меня машина не самая слабая, а приложение я хотел очень легкое, шустрое и отзывчивое. Подобные списки с тысячами элементов, сортировками, поисками и всем чем только можно — я прекрасно реализую на TVirtualTreeView, и оно на VTV работает на порядки шустрее с десятками тысяч — чем этот чудосписок со 100 элементами. Список на картинке как раз на VTV.
Собственно вопрос, улучшилась ли ситуация в XE5? А то тут говорят производительность норм… Насколько сложный был гуй? Было что-то сложнее картинки, трех кнопок и двух чекбоксов? Просто на FMX который был в Delphi XE3 написать что-то по сложности сопоставимое с Delphi IDE — невозможно на том FMX который с ним поставлялся. Простенькое приложение написать можно, но зачем оно на мобильных платформах? Батарею жрать? А на десктопах под винду — VCL шустрее.
p.s. У меня есть наработки типа библиотеки контролов, которые используют OpenGL для вывода графики. Когда то, когда навелосипедил для себя (когда еще никаких этих FireMonkey не было). Плюнул развивать это дело, когда выкатили FMX c XE. Но даже сейчас мои контролы работают шустрее. Потому что я заморачивался по поводу оптимизаций. Эх, знал бы что этот цирк с FMX затянется так…
Гуй был простой, чтобы любая девочка разобралась. Главный напряг ресурсов процессора приходится у меня на моменты, когда анимация контрола происходит одновременно с проигрыванием звукового файла. На Виндах явно заметно дёрганье анимации, т.е. что-то перегружено. Как ни странно, на Андроиде такого нет. Вот это поразительно. К слову, одни и те же 3D сцены, сделанные на Юнити, имея на десктопе фпс порядка 150-200, на этом же планшете падают в фпс до 15-20, т.е. на порядок.
try
Create;
finally
Free;
end
аж глаз режет, никогда не понимал такого подхода — всегда пишу так:
Create;
try
..
finally
Free;
end
А если нужно создать два объекта то писать вот так?
Я лично предпочитаю так:
obj1 := TMyObj1.Create;
try
obj2 := TMyObj2.Create;
try
....
finally
obj2.Free;
end;
finally
obj1.Free;
end;
Я лично предпочитаю так:
obj1 := nil;
obj2 := nil;
try
obj1 := TMyObj1.Create;
obj2 := TMyObj2.Create;
...
finally
obj1.Free;
obj2.Free;
end;
Если в конструкторе вылетает исключение, то у Вас по любому будет отрабатываться деструктор, а это черевато.
Чревато не знать делфи. Free если что делает проверку на nil. Код который я привел абсолютно корректен.
А вдруг я перекрыл Free? ) Не говорите ерунды, finally нужен для освобождения памяти, если память не была выделена, то и освобождать ничего не надо. Перепишите свой пример с GetMem/FreeMem, например, и все станет ясно.
Это вы говорите ерунду. Метод TObject.Free — не виртуальный, и если вы его перекрыли — то ССЗБ.
Не знаю что вам не ясно в примере выше, но вот то же самое на GetMem-ах
p.s. Видимо не стоит ввязываться в спор о Delphi с вашими знаниями этого языка.
Не знаю что вам не ясно в примере выше, но вот то же самое на GetMem-ах
item1 := nil;
item2 := nil;
try
GetMem(item1, SizeOf(item1^));
GetMem(item2, SizeOf(item2^));
...
finally
if assigned(item1) then FreeMem(item1);
if assigned(item2) then FreeMem(item2);
end;
p.s. Видимо не стоит ввязываться в спор о Delphi с вашими знаниями этого языка.
Как не знали дельфисты про MVC/MVVP, так и продолжают лепить копрокод в конце 2013-го.
UFO just landed and posted this here
Вы абсолютно правы. Все дельфисты — профессиональные говнокодеры, неспособные к написанию сложных приложений. MVC им ни о чем не говорит, а всякие ActionManager'ы и LiveBinding запилили в Дельфу просто так, чтобы показать «что и мы так можем».
А Эмбаркадеро финансируется мировой закулисой. Потому что не может быть такого, что нашлось достаточно разработчиков, готовых потратиться на никому ненужную XE3-4-5.
А Эмбаркадеро финансируется мировой закулисой. Потому что не может быть такого, что нашлось достаточно разработчиков, готовых потратиться на никому ненужную XE3-4-5.
> Как не знали дельфисты про MVC
Тащемта, делфя сама по себе — уже MVC.
То, что вы имеете в виду — это MVC поверх MVC.
Спорный вопрос, в общем.
Тащемта, делфя сама по себе — уже MVC.
То, что вы имеете в виду — это MVC поверх MVC.
Спорный вопрос, в общем.
Люблю Delphi с детства, был момент когда думал что делфи каюк настал, но вижу, что команда не сдается и так просто не уступит.
Я надеюсь, что делфи будет жить и баги устранят. Спорить чем делфи лучше или хуже не собираюсь, у меня достаточно опыта было на других языках они тоже не совершенны.
Я надеюсь, что делфи будет жить и баги устранят. Спорить чем делфи лучше или хуже не собираюсь, у меня достаточно опыта было на других языках они тоже не совершенны.
Спасибо, очень интересный опыт.
Как раз занимаюсь Android-разработкой, а на Дельфи пришлось плотно поработать в прошлом месяце (поддерживал немного Windows-СУБД на Delphi XE2). До 2009 года писал на Delphi 7 более двух лет.
В общем, с одной стороны хорошо, что появляются такие возможности выбора, но с другой строны лично я добровольно с Java на Delphi никогда бы неперешёл вернулся.
Простые причины на поверхности:
* Стандартными средствами можно легко разрабатывать под Android, не вкладывая денег в ПО. Сейчас работаю в Ubuntu и с Android Studio. В случае Delphi — это покупка Windows + самой среды разработки как минимум (?)
* Уровень документации. Официальная документация просто отличная + куча тематических блогов, StackOverflow, хабр в конце-концов. Нерешаемых проблем практически нет.
* Просто эстетическое удовлетворение от работы и удобствоIntelliJ IDEA Android Studio. После неё XE2 — это просто адъ и израиль какой-то :) Надеюсь в XE5 всё гораздо лучше, никогда её не видел.
Конечно, это всё касается чистого Андроида, задач писать под iOS/Windows Phone/Whatever пока не возникало.
Как раз занимаюсь Android-разработкой, а на Дельфи пришлось плотно поработать в прошлом месяце (поддерживал немного Windows-СУБД на Delphi XE2). До 2009 года писал на Delphi 7 более двух лет.
В общем, с одной стороны хорошо, что появляются такие возможности выбора, но с другой строны лично я добровольно с Java на Delphi никогда бы не
Простые причины на поверхности:
* Стандартными средствами можно легко разрабатывать под Android, не вкладывая денег в ПО. Сейчас работаю в Ubuntu и с Android Studio. В случае Delphi — это покупка Windows + самой среды разработки как минимум (?)
* Уровень документации. Официальная документация просто отличная + куча тематических блогов, StackOverflow, хабр в конце-концов. Нерешаемых проблем практически нет.
* Просто эстетическое удовлетворение от работы и удобство
Конечно, это всё касается чистого Андроида, задач писать под iOS/Windows Phone/Whatever пока не возникало.
UFO just landed and posted this here
Вы почти правы. В первом случае проблема не столько в том что TStringList.Create внутри try, а в том что в StrList может быть не nil до входа в try, соответственно код лучше переделать либо как вы сказали на:
либо на:
Я лично предпочитаю второй способ, потому что если надо создать несколько объектов — можно все в один try впихнуть.
Во втором же случае — в DeleteFile исключение не должно стрельнуть, т.к. функция вызывает системную, возвращающую код ошибки.
Таким образом код содержит потенциально одну проблему, с TStringList.Create, который может стрельнуть только одним исключением: EOutOfMemory, при этом будет утечка в один TStringList
StrList := TStringList.Create;
try
//some code here
finally
StrList.Free;
end;
либо на:
StrList := nil;
try
StrList := TStringList.Create;
//some code here
finally
StrList.Free;
end;
Я лично предпочитаю второй способ, потому что если надо создать несколько объектов — можно все в один try впихнуть.
Во втором же случае — в DeleteFile исключение не должно стрельнуть, т.к. функция вызывает системную, возвращающую код ошибки.
Таким образом код содержит потенциально одну проблему, с TStringList.Create, который может стрельнуть только одним исключением: EOutOfMemory, при этом будет утечка в один TStringList
UFO just landed and posted this here
Стрелять исключениями в деструкторе в делфи — это сразу же стрелять себе в ногу, ибо не отработает TObject.FreeInstance, а соответственно и TObject.CleanupInstance. Грубо говоря имеем сразу же утечку памяти еще до того, как код выйдет за пределы finally.
Кроме того делфя сама создает один блок финализации для автоматически финализируемых типов, и изменить мы это не можем. Поэтому бросать исключения в деструкторе — нельзя.
Кроме того делфя сама создает один блок финализации для автоматически финализируемых типов, и изменить мы это не можем. Поэтому бросать исключения в деструкторе — нельзя.
UFO just landed and posted this here
А, ну да, видимо я вас не так понял, когда вы говорили про общий случай. Я думал вы имели ввиду освобождение объектов в общем случае.
Тогда позвольте мне немного расширить ваше условие:
Но в общем случае рекомендуют использовать один try-finally блок на один ресурс для ресурсов, которые могут создавать исключения на этапе освобождения.
Тогда позвольте мне немного расширить ваше условие:
Но в общем случае рекомендуют использовать один try-finally блок на один ресурс для ресурсов, которые могут создавать исключения на этапе освобождения.
По поводу try..finally. Это был псевдокод, показывающий, что на обеих платформах можно спокойно использовать Free для освобождения объекта.
Если по сути дискуссии — использование того или иного подхода зависит от того, велика ли вероятность ошибки в конструкторе. Ошибка, например, при создании стринглиста, крайне маловероятна (кончилась память? Ничего другого сразу и не придумаешь.).
Предполагать, что ошибка может возникнуть в любом операторе программы, конечно, можно, но отражать это в коде имеет смысл только для самых наиболее вероятных мест.
Если по сути дискуссии — использование того или иного подхода зависит от того, велика ли вероятность ошибки в конструкторе. Ошибка, например, при создании стринглиста, крайне маловероятна (кончилась память? Ничего другого сразу и не придумаешь.).
Предполагать, что ошибка может возникнуть в любом операторе программы, конечно, можно, но отражать это в коде имеет смысл только для самых наиболее вероятных мест.
Простите за не очень позитив, но по-моему, это костыли, на других концах которых приделаны грабли.
Ещё раз прошу прощения.
Ещё раз прошу прощения.
Sign up to leave a comment.
Delphi XE5 + Android: первые впечатления