Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, drol, Вы писали:

D>>Да ну... Например, если файловый дескриптор на самом деле указывает на сетевой ресурс, то во-первых и сбой возможен, а во-вторых нормальная информация о сбое вполне себе реально необходима.

А>Кто мешает использовать в этом случае обработчики завершения?

D>>Итого:

D>>Подход с деструкторами-очистителями в C++ очень сильно ограничен, и нормально покрывает только самые простые (и по-большей части чисто технические) случаи, типа каких-нибудь smart pointer'ов. Любая очистка требующая новых ресурсов/допускающая отказы, сразу же вызывает тот жуткий код, который Вы напишете в ответ на вопрос из 1-го абзаца

А>Так этих "самых простых" случаев — 95%, в оставшихся 5-ти используйте обработчики завершения, блоки try catch

А>Java
А>

А>r1.open();
А>try {
А>  r2.open();//вдруг при инициализации r2 возникнет исключение - надо закрыть r1
А>  try {
А>    r3.open();//вдруг при инициализации r3 возникнет исключение - надо закрыть r1 и r2
А>    try {
А>      //наконец-то делаем то, что хотели
А>      ......
А>    }
А>    finally {
А>      r3.close();
А>    }
А>  }
А>  finally {
А>    r2.close();
А>  }
А>}
А>finally {
А>  r1.close();
А>}
А>

А>ужасно выглядит!

А>c++
А>

А>{
А>  r1.open();
А>  r2.open();
А>  r3.open();
А>  //делаем то, что хотим!!!
А>  ............
А>  //метод close автоматически вызовется в деструкторах
А>}
А>

А что, при инициализации r1, r2, r3 в С++ не может возникнуть исключений? Если приводить код, то, может, будем его одинаковым приводить?

M>>Разве в С++ не требуется проверки, правильно инициализировался объект или нет?
V>Зависит от архитектуры класса. Можно просто исключение кинуть из конструктора. И тогда !ЧУДО! деструкторы всех уже сконструированных членов автоматически позовутся. Безо всяких catch-finally вообще!

А разве в Яве не так же? И вообще приведенный код не равнозначен, имхо.

M>А разве в Яве не так же? И вообще приведенный код не равнозначен, имхо.
В Яве разве вообще есть понятие автоматически вызываемого деструктора?

Здравствуйте, Vamp, Вы писали:

V>Можно просто исключение кинуть из конструктора. И тогда !ЧУДО! деструкторы всех уже сконструированных членов автоматически позовутся. Безо всяких catch-finally вообще!

Ага. А если эти самые деструкторы тоже начнут кидать исключения, то мы тут же получим чудо-terminate()

D>Ага. А если эти самые деструкторы тоже начнут кидать исключения, то мы тут же получим чудо-terminate()
Уже обсуждали. Не начнут.

Здравствуйте, Mamut, Вы писали:

M>А что, при инициализации r1, r2, r3 в С++ не может возникнуть исключений? Если приводить код, то, может, будем его одинаковым приводить?

Да ладно. Не придирайтесь Что имел ввиду автор — вполне понятно.

Здравствуйте, shrecher, Вы писали:

S>Это к вопросу не относится. На самом деле, я хотел сказать, что overhead от memory barrier и подщета счетчика ссылок минимальный.
Сотня тактов. Подумаешь фигня какая...

Здравствуйте, SE, Вы писали:

SE>Про деструкторы. В той же спецификации С# так прямо и написано — по возможности не используйте деструкторы.
В C# нет деструкторов.
Там есть финалайзеры. Это совсем другое.
Еще там есть костыль ака IDisposable который применяется для заменя деструкторов когда нужна детерминированная финализация.

Здравствуйте, Mamut, Вы писали:

M>А что, при инициализации r1, r2, r3 в С++ не может возникнуть исключений? Если приводить код, то, может, будем его одинаковым приводить?

Если в С++ при вызове r2.open() возникнет исключение, то деструктор r1 выполнит все действия по очистке, т.е. r1.close() вызывать не нужно. Так что код выглядит одинаковым.

Здравствуйте, Vamp, Вы писали:

D>>Ага. А если эти самые деструкторы тоже начнут кидать исключения, то мы тут же получим чудо-terminate()
V>Уже обсуждали.

Обсуждали. Но в свете "!ЧУДО!...Безо всяких catch-finally вообще!", видимо осознание ещё неполно

V>Не начнут.

Так вот. Как мы установили выше по треду, в связи с ограничениями на содержимое, деструкторы C++ могут являться реализацией концепции "очистителя ресурсов" в основном только для чисто технических вещей а-ля smart pointer'ы. А так как Java не нуждается в оных мутантах, то оверхэда в виде try/catch/finally аналогичный java-код содержать не будет. Более того, во всех остальных ситуациях преимущество на стороне managed-языков, так как они располагают try/finally, а на C++ придётся плясать исключительно с try/catch...

*Когда код-то напишете ?

Здравствуйте, WolfHound, Вы писали:

WH>В C# нет деструкторов.
WH>Там есть финалайзеры. Это совсем другое.

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

Так что не финалайзеры "это совсем другое", а менеджеры памяти C++ и .NET отличаются

WH>Еще там есть костыль ака IDisposable который применяется для заменя деструкторов когда нужна детерминированная финализация.

И исходя из вышесказанного, IDisposable никоим образом не может применяться для замены деструкторов

Здравствуйте, drol, Вы писали:

D>А вот на мой взгляд, финалайзеры вполне себе деструкторы. Также запускаются из внутреннего контекста менеджера памяти, создавая возможность для нездорового поведения. Также сильно ограничены в содержимом. И даже механизмы вызова практически идентичен, бо дёргаются менеджером памяти в процессе освобождения этой самой памяти.

Хотя (насколько я помню) стандарт С++ и не определяет точного момента вызова деструктора, но все же это где-то в районе выхода из блока/метода.

В С# финалайзер вызывается при следующей сборке мусора данного поколения. А это может быть и через 2 миллисикунды, и через два дня и через 2 недели — зависит от использования. Закрыть соединение с базой "послезавтра" — не ахти как результат.
Т.е. финалайзер это нужная и полезная вещь, но это последний рубеж обороны и не заменяет явного освобождения ресурсов.

Здравствуйте, codelord, Вы писали:

C>Только вот когда дело касается эффективности, то все эти штучки дрючки на ( ...-машинах )
C>нервно курят ( лучше со-ут ). И разные это вещи каждому свое которые не корректно сравнивать ( С++ компилируемый язык, точка ). Мне нравится когда код работает с максимальной эффективностью очень быстро.
C>и это не для интерпретаторов на ( ...-машинах )

Ха! А Java — дваждыкомпилируемый язык, она круче!
А с hotspot — вообще многократно рекомпилируемый!!


З.Ы. А если серьезно — изучи вопрос. Джава — компилируемый язык, только окончательная компиляция в машкоды происходит в процессе работы приложения.

Здравствуйте, codelord, Вы писали:

C>Да ну нах, что за чушь.
C>Соберите объектник слинкуйте и запустите хоть где нибудь без Java интерпретатора в кучу мегов
Excelsior JET. Минимальное приложение (в виде автономного exe-шника) на Java — около 500Кб. Минимальное приложение с GUI (SWT) — около мегабайта.

Что я делаю не так?

Здравствуйте, Юрий Жмеренецкий, Вы писали:

D>>И вместо того чтобы дёргать какие-то там деструкторы вне нормального контекста исполнения программы (как поступает C++), managed-языки и -среды предоставляют набор вполне удобных механизмов — try/catch/finally/using — для нормального детерминированного управления объектом.

ЮЖ>Где-то я все это уже слышал...

Давайте проверим Вашу память.

Итак, что же тут понаписал peter koch... Похоже пытался портировать свой код на Java. А так как, насколько я могу судить по этому фрагменту, толком ни Java, ни С++ не знает, то получилась, разумеется, ерунда.

Возник какой-то did_initialise_properly(), тогда как никаких проблем захватить ресурс в конструкторе, аналогично C++ оригиналу, нет.
Куда-то потеряли terminate(), который, скорее всего, случится если деструктор class_with_possible_ressource бросит исключение.

Итого, правильный прямой порт:

void func() 
{
  class_with_possible_ressource cwpr = new class_with_possible_ressource();
  try
  {
       dosomethingwith(cwpr);
  }
  finally
  {
     if (cwpr instanceof Closeable) {
       try {
          ((Closeable)cwpr).close();
       } catch {
          terminate();
       }
     }
  }
}

Теперь рассмотрим нормальный порт, в стиле действительно Java, где не боятся исключений:

void func() 
{
  class_with_possible_ressource cwpr = new class_with_possible_ressource();
  try
  {
       dosomethingwith(cwpr);
  }
  finally
  {
     if (cwpr instanceof Closeable) {
       ((Closeable)cwpr).close();
     }
  }
}

*В большинстве случаев даже кастить не надо будет, интерфейс обычно явно сразу поддерживается... Ну да ладно...

А как будет выглядеть аналог на C++, да в свете выводов о реальной нише деструкторов http://www.rsdn.ru/forum/message/3047345.1.aspx

Автор: drol
Дата: 04.08.08

и http://www.rsdn.ru/forum/message/3048703.aspx

Автор: drol
Дата: 05.08.08

?

Ну и напоследок, я всё-таки соглашусь с koch'ом: в Java сделано неудобно И посему C# рулит

void func() 
{
  using(var cwpr = new class_with_possible_ressource()) 
    dosomethingwith(cwpr);
}

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, SE, Вы писали:

WH>В C# нет деструкторов.
WH>Там есть финалайзеры. Это совсем другое.

Так, а вот тут поподробней.
Вот что первое на глаза попалось: С# 3.0 Specification

1.6.7.6 Destructors
A destructor is a member that implements the actions required to destruct an instance of a class. Destructors cannot have parameters, they cannot have accessibility modifiers, and they cannot be invoked explicitly. The destructor for an instance is invoked automatically during garbage collection.
The garbage collector is allowed wide latitude in deciding when to collect objects and run destructors. Specifically, the timing of destructor invocations is not deterministic, and destructors may be executed on any thread. For these and other reasons, classes should implement destructors only when no other solutions are feasible.
The using statement provides a better approach to object destruction.

И это только один абзац. А вот слово Finalizer не было найдено ни разу, кроме как часть имени функции. Так что в С# надо говорить — деструкторы. А вот в CLR таки да это же самое обозвано финалайзерами

WH>Еще там есть костыль ака IDisposable который применяется для заменя деструкторов когда нужна детерминированная финализация.
Да, костыль, но зато какой удобный

P.S. Я не нудный, я — скрупулезный

Здравствуйте, MasterZiv, Вы писали:

>> MZ>Да думать надо, когда пишешь.

>> Наоборот! Надо делать так, чтобы *не приходилось думать о такой ерунде*.

MZ>Для того, чтобы не надо было думать, это всё должно быть в языке, а не
MZ>в каком-то редакторе. У редактора нет ни спецификации, ни стандарта,

Вы совершенно правы. У редактора, Word'а например, действительно ничего нет. Но зачем Вы пишете программы в Word'е ??? Это ведь страшно неудобно Программы надо разрабатывать в нормальных IDE, которые и спецификации, и стандарт отлично знают.

MZ>Но я бы даже сказал больше, что не думать вообще очень вредно.

А я Вам ещё раз повторю: о всякой ерунде думать не надо.

MZ>НАДО ДУМАТЬ !

Да, думать надо. Думать об архитектуре, о дизайне, о usability и т.д. А вот о приоритетах операций думать не надо. Более того, надо стараться, чтобы не требовалось думать о как можно большем количестве вещей. Например, возвращаясь к теме топика, о костылях из smart pointer'ов...

MZ>И надо иметь красивый сложный и мощный язык.

Свят-свят-свят... Надо иметь простой, удобный, выразительный, и в тоже время строгий язык. А ещё лучше несколько языков для единого managed runtime'а. Бо задачи бывают сильно и сильно разные.

MZ>А если человек не в состоянии уяснить приоритет операций в языке,

Вы обижаете (не будем тыкать пальцем ). Он профессионал (и, скорее всего, сильно поболее Вас). Просто был очень уставший...

MZ>на котором он программирует, или хотя бы заглянуть в справочник
MZ>в сложных случаях,

Зачем ? Скобки решают проблему автоматически и без всяких заглядываний.

MZ>его надо увольнять на фиг.

Гы! Да он Вас сам уволит на раз

MZ>Я думаю, что тему надо прекратить, агитировать С++-ников за то,
MZ>какая хорошая Java — бессмысленно,

Вы меня обижаете. Я правоверный .NET-чик, как я могу агитировать в пользу застрявшей в каменном веке Java ???

MZ>а на изначально поставленные
MZ>вопросы уже ответили.

В принципе — да. Однако ещё не все участники дискуссии осознали всю глубину ответов

Здравствуйте, SE, Вы писали:


SE>Вот что первое на глаза попалось: С# 3.0 Specification

SE>

SE>1.6.7.6 Destructors

Да, сначала называлось так, потом переименовали в finalizer и стандартизировали в Ecma-334. В C# 3.0 произошла регрессия к destructor, но процесс стандартизации эта версия спецификации еще не прошла.

Здравствуйте, Cyberax, Вы писали:

C>>Соберите объектник слинкуйте и запустите хоть где нибудь без Java интерпретатора в кучу мегов
C>Excelsior JET. Минимальное приложение (в виде автономного exe-шника) на Java — около 500Кб. Минимальное приложение с GUI (SWT) — около мегабайта.

И это, по-твоему, маленький размер? А, ну да, в 640к помещается
Печально, это на самом деле.

Здравствуйте, Mamut, Вы писали:

M>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, drol, Вы писали:

D>>>Да ну... Например, если файловый дескриптор на самом деле указывает на сетевой ресурс, то во-первых и сбой возможен, а во-вторых нормальная информация о сбое вполне себе реально необходима.

А>>Кто мешает использовать в этом случае обработчики завершения?

D>>>Итого:

D>>>Подход с деструкторами-очистителями в C++ очень сильно ограничен, и нормально покрывает только самые простые (и по-большей части чисто технические) случаи, типа каких-нибудь smart pointer'ов. Любая очистка требующая новых ресурсов/допускающая отказы, сразу же вызывает тот жуткий код, который Вы напишете в ответ на вопрос из 1-го абзаца

А>>Так этих "самых простых" случаев — 95%, в оставшихся 5-ти используйте обработчики завершения, блоки try catch

А>>Java
А>>

А>>r1.open();
А>>try {
А>>  r2.open();//вдруг при инициализации r2 возникнет исключение - надо закрыть r1
А>>  try {
А>>    r3.open();//вдруг при инициализации r3 возникнет исключение - надо закрыть r1 и r2
А>>    try {
А>>      //наконец-то делаем то, что хотели
А>>      ......
А>>    }
А>>    finally {
А>>      r3.close();
А>>    }
А>>  }
А>>  finally {
А>>    r2.close();
А>>  }
А>>}
А>>finally {
А>>  r1.close();
А>>}
А>>

А>>ужасно выглядит!

А>>c++
А>>

А>>{
А>>  r1.open();
А>>  r2.open();
А>>  r3.open();
А>>  //делаем то, что хотим!!!
А>>  ............
А>>  //метод close автоматически вызовется в деструкторах
А>>}
А>>

M>А что, при инициализации r1, r2, r3 в С++ не может возникнуть исключений? Если приводить код, то, может, будем его одинаковым приводить?

да, могу возникнуть, и возникнут! но это нас не касается
читайте здесь

Автор: jazzer
Дата: 04.08.08