Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата korvin @ 04.01.12, 08:41

И это плохо, т.к. синтаксически не отражает структуру кода.

т.е.??

Добавлено 04.01.12, 09:22

Цитата korvin @ 29.12.11, 10:38

мне в джаве не хватает(впрочем может я просто не знаю как это сделать) чего-то типа "локального переопределия метода" для класса

Можно хелпером переопределить, но только это будет локально для всего модуля.

  TFoo = class
    procedure Bar;
  end;
 
  TFooHelper = class helper for TFoo
    procedure Bar;
  end;
 
 
procedure TFoo.Bar;
begin
  Writeln('TFoo.Bar');
end;
 
procedure TFooHelper.Bar;
begin
  inherited Bar;
  Writeln('TFooHelper.Bar');
end;

TFoo.Bar
TFooHelper.Bar

Цитата DesweR @ 04.01.12, 06:51

Нет, ты не понял. Задача гарантировать освобождение ресурса при выходе за указанные границы на участке кода.
Вот так нагляднее будет:

Нафига всё это, если в деструкторе освободить можно?

Цитата Повстанець @ 04.01.12, 09:24

Нафига всё это, если в деструкторе освободить можно?

Вот так просто? Ну перепиши пример

Цитата DesweR @ 30.12.11, 07:18

Вот тебе псевдокод, приведи аналогичный на C++, чтобы я почувствовал синтаксическую и семантическую разницу.

Это вот этот, чтоли? Так он логически неверный даже для делфи. Работа фактически завершена не была, а ты рапортуешь о завершении. Странно как то...

Цитата Повстанець @ 04.01.12, 09:37

Странно как то...

Смысл бытия не ищи, целью является демонстрация.

Цитата DesweR @ 04.01.12, 06:51

Цитата D_KEY @ 30.12.11, 07:31

Совершенно разная ситуация. Свой дурацкий finally ты будешь писать каждый раз. Тут же управление ресурсом делегируется отдельному объекту, а твой код уже не думает об этом.

Да где разная? Говорю же, переведи дословно мой пример.

Уже переводил

Цитата

И чтобы там не пропагандировали "наши/ваши" идиомы - семантически и синтаксически это будет выглядеть практически одинаково, а следовательно спорить "наше" краше "вашего" бесполезно (Qraizer истину глаголит).

Судя по тому, что "ваши" уже давно перешли на аналоги RAII в условиях GC(Java со своим try-c-ресурсами это сделала не так давно), а вот ни в С++(новый стандарт же вот недавно вышел), ни в D finally не появилось, говорить о "равенстве" подходов не приходится. Страуструп не ввел finally в язык сознательно, цитату я уже приводил.

Цитата

Нет, ты не понял. Задача гарантировать освобождение ресурса при выходе за указанные границы на участке кода.
Вот так нагляднее будет:

begin
  //код
  //код
  //код
 
  try
    //1: начало работы
    //1: ИСКЛЮЧЕНИЕ!
  finally
    //1: конец работы
  end;
  {1: начало работы
   1: ИСКЛЮЧЕНИЕ!
   1: конец работы}
 
  try
    //2: начало работы
 
    try
      //3: начало работы
      //3: ИСКЛЮЧЕНИЕ!
    finally
      //3: конец работы
    end;
    {1: начало работы
     1: конец работы
     2: начало работы
     3: начало работы
     3: ИСКЛЮЧЕНИЕ!
     3: конец работы
     2: конец работы}
 
    //2: ИСКЛЮЧЕНИЕ!
  finally
    //2: конец работы
  end;
  {1: начало работы
   1: конец работы
   2: начало работы
   3: начало работы
   3: конец работы
   2: ИСКЛЮЧЕНИЕ!
   2: конец работы}
 
  //код
  //код
  //код
end;

Еще раз - это не нужно. Т.к. у тебя нет ни одного обработчика исключений - не нужны и try-блоки. Просто выкини из своего кода все try и finally(т.к. все, что они сделают - сделают владельцы ресурсов).

Цитата

Тут дело даже не в SEH, а в том что единственный тип, для которого можно определять финализацию - это класс, но его экземпляры являются ссылками.

О недостатках этого подхода мы уже говорили. Вот и еще один всплыл.

Цитата D_KEY @ 04.01.12, 09:45

Судя по тому, что "ваши" уже давно перешли на аналоги RAII в условиях GC(Java со своим try-c-ресурсами это сделала не так давно), а вот ни в С++(новый стандарт же вот недавно вышел), ни в D finally не появилось, говорить о "равенстве" подходов не приходится. Страуструп не ввел finally в язык сознательно, цитату я уже приводил.

Ну ну, порождение различных идиом а-ля Scope Guard само за себя говорит

Цитата D_KEY @ 04.01.12, 09:45

Еще раз - это не нужно. Т.к. у тебя нет ни одного обработчика исключений - не нужны и try-блоки.

Не аргумент. Сливаете?

Цитата D_KEY @ 04.01.12, 09:45

О недостатках этого подхода мы уже говорили. Вот и еще один всплыл.

Достоинства и недостатки есть у всего.

Цитата DesweR @ 04.01.12, 09:56

Цитата D_KEY @ 04.01.12, 09:45

Судя по тому, что "ваши" уже давно перешли на аналоги RAII в условиях GC(Java со своим try-c-ресурсами это сделала не так давно), а вот ни в С++(новый стандарт же вот недавно вышел), ни в D finally не появилось, говорить о "равенстве" подходов не приходится. Страуструп не ввел finally в язык сознательно, цитату я уже приводил.

Ну ну, порождение различных идиом а-ля Scope Guard само за себя говорит

Это более общий подход, чем finally, о чем Страуструп и писал.
А о чем говорит появление менеджеров контекста и with, Dispose-паттерна и using/try-с-ресурсами?

Цитата

Цитата D_KEY @ 04.01.12, 09:45

Еще раз - это не нужно. Т.к. у тебя нет ни одного обработчика исключений - не нужны и try-блоки.

Не аргумент. Сливаете?

Аргумент чего?
Ты просишь меня фактически сделать костыль.

Цитата

Цитата D_KEY @ 04.01.12, 09:45

О недостатках этого подхода мы уже говорили. Вот и еще один всплыл.

Достоинства и недостатки есть у всего.

Безусловно. Вопрос в том, стоят ли достоинства недостатков

Сообщение отредактировано: D_KEY - 04.01.12, 10:17

Цитата DesweR @ 04.01.12, 09:41

Смысл бытия не ищи, целью является демонстрация.

Ну ок, ок. В демонстрации говнокода, лишённого практического применения С++ слил.

Цитата D_KEY @ 04.01.12, 09:45

Свой дурацкий finally ты будешь писать каждый раз.

А ты такие штуки, как try...catch...finally никогда не юзал?
И можешь объяснить - почему это finally дурацкий? Да и и чем вообще finally тебя не устраивает?

Цитата Krid @ 04.01.12, 10:57

А ты такие штуки, как try...catch...finally никогда не юзал?
И можешь объяснить - почему это finally дурацкий? Да и и чем вообще finally тебя не устраивает?

Из всех средств управления владения ресурсами finally таки и есть самый дурацкий. В ранних скриптовых/байткодовых языках предполагался как костыль к сборщику мусора. В делфи попал уже из них, но без сборщика мусора.

Цитата Krid @ 04.01.12, 10:57

Цитата D_KEY @ 04.01.12, 09:45

Свой дурацкий finally ты будешь писать каждый раз.

А ты такие штуки, как try...catch...finally никогда не юзал?
И можешь объяснить - почему это finally дурацкий? Да и и чем вообще finally тебя не устраивает?

Приходилось юзать давно в Delphi, в Java(теперь он там тоже не нужен). В остальных языках finally или нет, или же он остался от старых времен.
Можешь привести пример, когда ты обычно используешь finally?

Цитата DesweR @ 04.01.12, 09:56

Не аргумент. Сливаете?

D_KEY имел в виду, что будет

{
  //код
  //код
  //код
 
  {
   //1: начало работы
   //1: ИСКЛЮЧЕНИЕ!
  }//1: конец работы
  /*1: начало работы
  1: ИСКЛЮЧЕНИЕ!
  1: конец работы*/
 
  {
   //2: начало работы
 
   {
     //3: начало работы
     //3: ИСКЛЮЧЕНИЕ!
   } //3: конец работы
   /*1: начало работы
   1: конец работы
   2: начало работы
   3: начало работы
   3: ИСКЛЮЧЕНИЕ!
   3: конец работы
   2: конец работы*/
 
   //2: ИСКЛЮЧЕНИЕ!
  }//2: конец работы
  /* 1: начало работы
  1: конец работы
  2: начало работы
  3: начало работы
  3: конец работы
  2: ИСКЛЮЧЕНИЕ!
  2: конец работы */
 
  //код
  //код
  //код
}

Потому что Концы Работ будут в деструкторах RAII объектов, в конструкторах которых находятся Начала Работ. Да, использовать тут EH явным образом не нужно, равно как не требуется goto для реалиазции if.

Цитата D_KEY @ 04.01.12, 09:45

в D finally не появилось

Закадровый голос с НТВ: Ты не поверишь!
Там вообще всё запущено, что, к огромному сожалению, только разочаровывает в D

Цитата MyNameIsIgor @ 04.01.12, 17:29

Цитата D_KEY @ 04.01.12, 09:45

в D finally не появилось

Закадровый голос с НТВ: Ты не поверишь!
Там вообще всё запущено, что, к огромному сожалению, только разочаровывает в D

Ну там добавили специальные scope(exit/failure/succes) для удобства написания транзакций. Вряд ли это можно назвать костылем, единственное, не ясно, зачем это делать встроенным средством, а не через RAII + лямбды + "макросы".
Относительно же классического RAII и finally там сказано ясно:

Цитата

RAII is for managing resources, which is different from managing state or transactions. try-catch is still needed, as scope doesn't catch exceptions. It's try-finally that becomes redundant.