Использования языков через ini

[Stilet]

Ins

Если она тебя смущает ничего не мешает тебе использовать метод Free.

[Ins]

Достаточно простого Free

Если она тебя смущает ничего не мешает тебе использовать метод Free.

Так сказал, как будто бы одно и то же Разница между i := nil и i.Free в том, что первое - это НЕ ПРАВИЛЬНО, и приводит к утечке ресурсов, а второе - это ПРАВИЛЬНО. Допускаю, что есть люди для которых эта разница не существенна...

[GunSmoker]

Сообщение от Stilet

Обосновывай свои претензии.

Обосновываю:

i := nil;

Причина: очевидна.

i:=TIniFile.Create(ExtractFilePath(ParamStr(0))+'File1.ini');
// где try?

Причина: если в блоке кода ниже что-то пойдёт не так - получаем утечку памяти.

Для примера этого вполне достаточно.

Согласен. Я бы промолчал, если бы дело было только в отсутствии try. Но i := nil?!

Человек сам в состоянии догодаться что try..except нужны.... иначе догодается отладчик.. =)

Во-первых, try/finally, а не try/except, а во-вторых, человек сам не догадается.

[Stilet]

Так сказал, как будто бы одно и то же

Нет. Это не одно и то же, но тем не менее в некоторых ситуациях я не использую Деструкторы.

Причина: очевидна.

Ты будешь удивлен но Free не всегда верный способ. На нем тоже можно проколоться.

если в блоке кода ниже что-то пойдёт не так - получаем утечку памяти.

Если в блоке ниже что-то пойдет не так это свидетельство того что программу нужно поправить чтоб исключить это твое "не так", иначе разленившийся программист будет тыкать try везде где попало абы заткнуть рот операционке - мол "хавай и не вякай", а проблема не решена. try это тоже палка о двух концах, если программист понадеялся на перехват исключения, то результат работы программы может в некоторых ситуациях быть оч. пагубным (например испортить базу данных) мне доводилось видать чужую писанину где авторы не давали откат при ошибках на клиенте, таким образом портя данные в базах, а клиенты долго думали "Чего ж неправильно программа пишет?" Звонили в службо поддержки, им обьясняли мол "раз вы ошибку на экране не видите то сами виноваты".

[Ins]

но тем не менее в некоторых ситуациях я не использую Деструкторы.

Ситуаций, где явно не нужно вызывать Free, не так уж и много. По сути все сводится к тому, что если за уничтожение объекта отвечает кто-то другой, то явный Free может быть не нужен. Ну а присвоение nil объектной ссылке НИКОГДА не приведет к уничтожению объекта, разве что только в том случае, если мы присваиваем объектному свойству, сеттер которого это предусматривает. Присвоение nil - это для интерфейсных ссылок работает, но не для объектных.

Некоторые ситуации, даже если они и гипотетически возможны, нисколько не оправдывают подобный код ЗДЕСЬ

Ты будешь удивлен но Free не всегда верный способ. На нем тоже можно проколоться.

Расшифруй, особливо в применении к ДАННОМУ случаю

Если в блоке ниже что-то пойдет не так это свидетельство того что программу нужно поправить чтоб исключить это твое "не так"

Не все исключения - это ошибки в программе. Исключение может быть частью протокола между вызываемым и вызывающим кодом, так же, как, скажем, возвращаемое значение или out-параметры. Обработка таких исключений - это повседневная задача программиста, ну а try..finally - это вообще отдельная история, которая, собственно, даже к обработке исключений относится посредственно. Это гарантия освобождения ресурсов. Блок finally получает управление не только при исключении, но и при Exit

[Stilet]

нисколько не оправдывают подобный код ЗДЕСЬ

Ладно, пусть так. )
Спорить не буду.

[GunSmoker]

Если в блоке ниже что-то пойдет не так это свидетельство того что программу нужно поправить чтоб исключить это твое "не так", иначе разленившийся программист будет тыкать try везде где попало абы заткнуть рот операционке - мол "хавай и не вякай", а проблема не решена. try это тоже палка о двух концах, если программист понадеялся на перехват исключения, то результат работы программы может в некоторых ситуациях быть оч. пагубным (например испортить базу данных) мне доводилось видать чужую писанину где авторы не давали откат при ошибках на клиенте, таким образом портя данные в базах, а клиенты долго думали "Чего ж неправильно программа пишет?" Звонили в службо поддержки, им обьясняли мол "раз вы ошибку на экране не видите то сами виноваты".

Этот бред вы мне сейчас рассказываете? Возвращайтесь, пожалуйста, к Паскалю в 80-е, где не было исключений, но не надо учить этому новичков.

Stilet, я не лично к вам прикапываюсь, а к тому, что вы иногда пишете.

[Stilet]

но не надо учить этому новичков.

Не буду разводить холливар, просто скажу "Не веришь - не надо".
Не дай боже тебе напороться на подобные ошибки со стороны других программистов, когда ты сидишь и думаешь где же ты в вводе данных ошибся, когда на самом деле не твоя вина.

а к тому, что вы иногда пишете.

Эх.. Тебя бы к нам в контору, понавидался бы ты такого...

[ZvEr_HaCkEr]

как я понял из беседы на так исправить надо?

procedure TForm1.EnClick(Sender: TObject);
var
 i:tinifile;
 k:integer;
begin
i:=tinifile.Create(extractfilepath(paramstr(0))+'sources/languages/En.ini');
try
for k := 0 to componentcount - 1 do begin
 if components[k] is Tmenuitem then
tmenuitem(components[k]).Caption:=i.ReadString('Menu',tmenuitem(components[k]).Name,tmenuitem(components[k]).Caption);
end;
finally
i.Free ;
end;
end;

[GunSmoker]

Да, правильно.

Надеюсь, что понятно, почему так, а то мы что-то между собой увлеклись...