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

Цитата Qraizer @ 30.12.11, 20:08

Цитата D_KEY @ 30.12.11, 10:08

finally не является идиомой освобождения ресурсов. Это "идиома" выполнения произвольного кода после блока try в не зависимости от того, произошло ли исключение.
RAII же напрямую не связан с исключениями - это идиома владения ресурсами и автоматического их освобождения в отсутствии владельца. В частности, она бы была полезна и в С, без механизма исключений.

А это не важно. Есть некие идиомы, и (отдельно от них) есть некие средства реализации чего бы то ни было. Вот в частности решили применить некую пару средств реализации для реализации некой идиомы. Спорить, какое из двух средств подходит лучше - можно, но это и будет холивар. Если же трезво оценивать плюсы и минусы каждого решения, то своё мнение я сказал.

На мой взгляд тут именно разные идиомы.
Вот, например, у Страуструпа в D&E, где он описывает, как появилась идиома RAII(я думаю, что мне не надо объяснять, что к этому времени в языке уже было все, чтобы эта идиома работала - никаких дополнительных средств вводить не потребовалось), есть такие строки:

Цитата

Можно было бы слегка сократить код(это он о том, что без finally нужно вызывать закрытие файла дважды - в catch и после всего блока обработки), предоставив в распоряжение программиста некоторый механизм финальной обработки(finally ). Это позволило бы уйти от дублирования кода освобождения ресурса ... но никак не решило бы принципиальную проблему: для написания отказоустойчивого кода требуется специальная и более сложная, чем обычно, техника.
(ну а дальше, собственно, следует указание того, что конструкторы и деструкторы уже чудесно справляются с задачей такого управления ресурсами, и описание техники RAII)

Т.о., не вводя в язык никаких специальных механизмов, удалось обеспечить безопасный в плане работы с ресурсами код. Как с исключениями, так и без.

D_KEY, ты об инструменте, предоставляемым языком. Я - не только о нём, но и о предоставляемым ОС и поддерживаемым языком в качестве расширения. Естественно, не каждой реализацией и не на каждой платформе, однако суть та же - исполнение пользовательского кода очистки безотносительно к тому, каким именно образом поток исполнения покидает scope, в области видимости которого наличествует локальное владение неким общим ресурсом.

Цитата [S]mike @ 30.12.11, 15:02

Правда операционные системы - только на C.

Глупость.

Добавлено 31.12.11, 07:23

Цитата [S]mike @ 30.12.11, 20:16

C++? Я его тоже имел ввиду. Чистый Ассемблер? Извращение. Эксперименты на шарпе вроде Singularity скорее исключение, чем правило.

Малое количество и фактически никакая распространенность операционных систем на не-Си вовсе не свидетельствует, что ОС можно и нужно пиисать только на Си. Когда ОС не на ассеьблере считались дикостью и/или баловством, экспериментами...

Цитата korvin @ 31.12.11, 07:17

Малое количество и фактически никакая распространенность операционных систем на не-Си вовсе не свидетельствует, что ОС можно и нужно пиисать только на Си.

Ну на чем там энтузиасты ОС разрабатывают? Просвети, плз

Джастфорфанить можно на чем угодно конечно, только толку?

Цитата [S]mike @ 30.12.11, 15:02

Skype

Не нужен. По идеологическим соображениям.

Цитата [S]mike @ 30.12.11, 15:02

Total Commander

Не нужен. Ибо Far.

Цитата korvin @ 31.12.11, 07:17

Когда ОС не на ассеьблере считались дикостью и/или баловством, экспериментами...

На сколько я понимаю, основная проблема использовать не C в ядре ОС вовсе не идеологическая, а сугубо практическая - управление памятью. Современные языки же сплошь с GC и прочими наворотами, неявно управляющими памятью.
А в ядре мы можем находиться в такой ситуации, что страничный отказ не может быть обработан. ЕМНИП, даже у автором симбиана была в этом моменте проблема с плюсами. Потому некая прослойка в виде C будет обязательно. И не хилая такая прослойка.

Цитата [S]mike @ 31.12.11, 08:32

Ну на чем там энтузиасты ОС разрабатывают? Просвети, плз

Кому что нравится, на том и разрабатывают, вплоть до создания собственных языков под это дело. Из известных мне, навскидку: Limbo, Oberon, Lisp, Haskell для Inferno, Oberon, Losak и House, соответственно

Добавлено 31.12.11, 11:04

Цитата MyNameIsIgor @ 31.12.11, 08:51

На сколько я понимаю, основная проблема использовать не C в ядре ОС вовсе не идеологическая, а сугубо практическая - управление памятью. Современные языки же сплошь с GC и прочими наворотами, неявно управляющими памятью.
А в ядре мы можем находиться в такой ситуации, что страничный отказ не может быть обработан. ЕМНИП, даже у автором симбиана была в этом моменте проблема с плюсами. Потому некая прослойка в виде C будет обязательно. И не хилая такая прослойка.

Dis, ЕМНИП, весьма компактна.

Сообщение отредактировано: korvin - 31.12.11, 11:05

Цитата Qraizer @ 30.12.11, 22:07

однако суть та же - исполнение пользовательского кода очистки безотносительно к тому, каким именно образом поток исполнения покидает scope, в области видимости которого наличествует локальное владение неким общим ресурсом.

Так в том и дело, что R AII ничего не говорит о выполнении произвольного кода, а finally, в свою очередь ничего не говорит о ресурсах
А если учесть, что выполнение произвольного кода нам и не нужно, то не нужен и finally - достаточно RAII и его эквивалентов. И развитие языков это подтверждает.

Цитата MyNameIsIgor @ 31.12.11, 08:51

Цитата ([S]mike @ Вчера, 18:02)
Skype

Не нужен. По идеологическим соображениям.

Это как? Какая у него альтернатива?

Цитата Polinom2686 @ 31.12.11, 15:10

Цитата MyNameIsIgor @ 31.12.11, 08:51

Не нужен. По идеологическим соображениям.

Это как? Какая у него альтернатива?

Если пишут "по идеологическим соображениям", наличие или отсутствие альтернатив значения не имеет.

D_KEY, не буду спорить. Но согласись, что найти общий знаменатель для них можно. Хоть и не наилучший для кадного, но-таки удовлетворяющий каждого. Вот я как раз об этом.

Цитата IL_Agent @ 28.12.11, 11:44

std::string ? Хранит или не хранит ?

Хранит

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

Гарантированное уничтожение объектов не связано с обработкой исключений. Деструктор в любом случае должен вызваться, даже если я в проекте вообще исключения не использую(а такой, представь себе, вполне реально).

Эмм.. А я про что?

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

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

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

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

Т.е. тот же код по сути должен выглядеть так:

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

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;

Добавлено 04.01.12, 07:12

Цитата Qraizer @ 30.12.11, 09:49

Очень жаль, что SEH в Дельфи является частью языка, а не его расширением, ибо это означает отсутствие альтернативы.

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

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

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

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(1) не произойдет выход из процедуры после отработки кода в finally(1) без отработки кода в try(2) и ниже?

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

А разве при возникновении исключения в try(1) не произойдет выход из процедуры после отработки кода в finally(1) без отработки кода в try(2) и ниже?

Да, там так и есть.

Цитата DesweR @ 04.01.12, 08:37

Да, там так и есть.

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