Сборщик мусора и размещение объектов в стеке - Философия программирования

Здравствуйте, Константин Л., Вы писали:

C>>>>Ты подумай, однако. "Стековые" объекты нельзя просто так класть в ref-классы, так как они уничтожаются в недетерминированое время.
КЛ>>>Так подумать над этой проблемой, или над тем, что слаще?
C>>То есть?
КЛ>Сначала ты с пафосом предлагал "дойти" до мысли, что это просто не нужно. Потом начал упирать на то, что это нереализуемо.
Не "не нужно", а "невозможно сделать правильно". А если делать только в тех случаях, когда _можно_ сделать правильно — получим или полный С++ или аналог using()'а.

КЛ>>>А вот волшебники взяли и заимплементили такую фичу в c++\cli

C>>Это вполне понятно, так как C++/CLI уже включает в себя все механизмы обычного С++ для управления памятью. А ты попробуй придумать как добиться того же, не повторяя половину С++.
КЛ>для этого не нужно ничего повторять.
Ну покажи как ты будешь стековые объекты с детерминированым деструкторами и ref-классы совмещать (без финализаторов — это хак).

Здравствуйте, Константин Л., Вы писали:

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

C>>Здравствуйте, Константин Л., Вы писали:

C>>>>А ты дальше подумай — что делать, если эта структура будет полем класса, уничтожение которого недетерминировано?
КЛ>>>И что? Если ее создали на стеке — ведет себя как стековый объект. Если нет — ну нет так нет. В C++\CLI именно так и работает.
C>>Осталось сделать следующий шаг, и понять, что стековые объекты не нужны — достаточно паттерна Disposable и сахара в виде using().

КЛ>Шаг к чему? К дао? Достаточно понять, что using менее сладок нежели стековые объекты.

Особенно сладки стековые объекты в С++, когда идёт отмотка стека из-за исключения и тут из деструктора вылетает новое исключение

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

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

C>>>ИМХО, совсем не оправдывает введение еще одной сущности.
FR>>А что для Вальтера лишняя сущность!

C>Ну да, после трех сортов константности от таких людей чего угодно можно ждать.

Угу если еще учесть что есть scope(exit) и т. п.

C>В _таком_ виде scope просто является другой записью using'а — я не против. Но зачем делать scope-классы — это уже мне не очень понятно.

Я одно хорошее примение вижу — гарантированный RAI объект который нельзя использовать в других целях

C>Там же целая гора проблем сразу возникает: как работает наследование, что произойдет при наследовании от обычного класса, и т.д.

Ну scope как вирус если определяешь то все потомки будут scope.
А наследоватся можно от любого класса.

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

_>Здравствуйте, Константин Л., Вы писали:

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

C>>>Здравствуйте, Константин Л., Вы писали:

C>>>>>А ты дальше подумай — что делать, если эта структура будет полем класса, уничтожение которого недетерминировано?
КЛ>>>>И что? Если ее создали на стеке — ведет себя как стековый объект. Если нет — ну нет так нет. В C++\CLI именно так и работает.
C>>>Осталось сделать следующий шаг, и понять, что стековые объекты не нужны — достаточно паттерна Disposable и сахара в виде using().

КЛ>>Шаг к чему? К дао? Достаточно понять, что using менее сладок нежели стековые объекты.

_>Особенно сладки стековые объекты в С++, когда идёт отмотка стека из-за исключения и тут из деструктора вылетает новое исключение

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

list1.push(v1);
try
{
  list2.push(v2);
}
catch (...)
{
  try
  {
    list1.pop();
  }
  catch (...)
  {
    //!!! <--------------
  }
}

В точке //!!! остаётся только убить себя об стену или выпить йада, ничего лучше придумать нельзя. Т.ч. возможное завершение программы на С++ при вылете исключения из конструктора есть вполне удобная вещь — автоматизация убивания об стену.

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

FR>Угу если еще учесть что есть scope(exit) и т. п.

scope(exit) — это тоже вполне нормальная идея, согласен.

C>>В _таком_ виде scope просто является другой записью using'а — я не против. Но зачем делать scope-классы — это уже мне не очень понятно.
FR>Я одно хорошее примение вижу — гарантированный RAI объект который нельзя использовать в других целях
RAII очень ограниченый получается — если мы не можем сохранять его в поля класса.

C>>Там же целая гора проблем сразу возникает: как работает наследование, что произойдет при наследовании от обычного класса, и т.д.
FR>Ну scope как вирус если определяешь то все потомки будут scope.
FR>А наследоватся можно от любого класса.
Ооо...

class Base
{
   Base()
   {
      someExternalVariable=this;
   }
};

scope class Derived : public Base
{
   Derived() : Base() //???
   {
   }
}

И вот таких шуток, если подумать, можно найти еще несколько штук.

Нет, при желании их можно решить — но это куча сложности добавится на пустом месте.

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

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

_>>Здравствуйте, Константин Л., Вы писали:

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

C>>>>Здравствуйте, Константин Л., Вы писали:

C>>>>>>А ты дальше подумай — что делать, если эта структура будет полем класса, уничтожение которого недетерминировано?
КЛ>>>>>И что? Если ее создали на стеке — ведет себя как стековый объект. Если нет — ну нет так нет. В C++\CLI именно так и работает.
C>>>>Осталось сделать следующий шаг, и понять, что стековые объекты не нужны — достаточно паттерна Disposable и сахара в виде using().

КЛ>>>Шаг к чему? К дао? Достаточно понять, что using менее сладок нежели стековые объекты.

_>>Особенно сладки стековые объекты в С++, когда идёт отмотка стека из-за исключения и тут из деструктора вылетает новое исключение

R>Если освобождения ресурсов/откаты действий могут не проходить, то в принципе нельзя добиться никакой осмысленной семантики, в частности консистентности нетривиальных данных.
R>Например, хотим добавить значения в 2 списка:

R>

R>list1.push(v1);
R>try
R>{
R>  list2.push(v2);
R>}
R>catch (...)
R>{
R>  try
R>  {
R>    list1.pop();
R>  }
R>  catch (...)
R>  {
R>    //!!! <--------------
R>  }
R>}
R>

R>В точке //!!! остаётся только убить себя об стену или выпить йада, ничего лучше придумать нельзя. Т.ч. возможное завершение программы на С++ при вылете исключения из конструктора есть вполне удобная вещь — автоматизация убивания об стену.

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

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

C>И вот таких шуток, если подумать, можно найти еще несколько штук.

Проверил:

import std.stdio;

class Base
{   
   static Base someExternalVariable;
    
    this()
    {
        writefln("Base constructor"); 
        someExternalVariable=this;
    }
   
   ~this()
    {    
        writefln("Base destructor ");
    }
    
    void Test()
    {
        writefln("Test");
    }
   
}

scope class Derived : Base
{
   this()
   {
       super();
   }
}


void main()
{
    {
    scope sc = new Derived();
    }
    
    writefln("end");
    
    Base.someExternalVariable.Test();
}

Словил AV

C>Нет, при желании их можно решить — но это куча сложности добавится на пустом месте.

Да тут недоработка.

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

R>>В точке //!!! остаётся только убить себя об стену или выпить йада, ничего лучше придумать нельзя. Т.ч. возможное завершение программы на С++ при вылете исключения из конструктора есть вполне удобная вещь — автоматизация убивания об стену.

_>Ага, мы убили себя, даже не залогировав ошибку, потому что логер доступен только выше по стэку. Не хотел бы я такое отлавливать.

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

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

C>Здравствуйте, Константин Л., Вы писали:

C>>>>>Ты подумай, однако. "Стековые" объекты нельзя просто так класть в ref-классы, так как они уничтожаются в недетерминированое время.
КЛ>>>>Так подумать над этой проблемой, или над тем, что слаще?
C>>>То есть?
КЛ>>Сначала ты с пафосом предлагал "дойти" до мысли, что это просто не нужно. Потом начал упирать на то, что это нереализуемо.
C>Не "не нужно", а "невозможно сделать правильно". А если делать только в тех случаях, когда _можно_ сделать правильно — получим или полный С++ или аналог using()'а.

Что значит полный с++? Что-то я не догоняю.

КЛ>>>>А вот волшебники взяли и заимплементили такую фичу в c++\cli

C>>>Это вполне понятно, так как C++/CLI уже включает в себя все механизмы обычного С++ для управления памятью. А ты попробуй придумать как добиться того же, не повторяя половину С++.
КЛ>>для этого не нужно ничего повторять.
C>Ну покажи как ты будешь стековые объекты с детерминированым деструкторами и ref-классы совмещать (без финализаторов — это хак).

С финализатором как раз просто, а вот что делать в случае, когда объект реализует IDisposable. Что делать что делать. В финализаторе звать dtor автоматом (пусть компайлер зовет). В Dispose звать ручками. Тогда получится некий аналог IDisposable. Но я этого не отрицаю. Просто синтаксический сахарок.

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

[]

_>Особенно сладки стековые объекты в С++, когда идёт отмотка стека из-за исключения и тут из деструктора вылетает новое исключение

А ты возьми за правило, что деструкторы не должны кидать исключений. И вообще, пост твой не в тему.

Здравствуйте, Константин Л., Вы писали:

КЛ>>>Сначала ты с пафосом предлагал "дойти" до мысли, что это просто не нужно. Потом начал упирать на то, что это нереализуемо.
C>>Не "не нужно", а "невозможно сделать правильно". А если делать только в тех случаях, когда _можно_ сделать правильно — получим или полный С++ или аналог using()'а.
КЛ>Что значит полный с++? Что-то я не догоняю.
Фича стековых объектов — детерминированое уничтожение. Чтобы стековые объекты были чем-то большим, чем записаный по-другому using(), нужно уметь эти объекты передавать по значению. А это потребует семантики оператора присваивания и копирующего конструктора. А это, в свою очередь, привлечет другие проблемы (например, захочется иметь ссылки на стековые объекты).

И если их попробовать решить — С++ и получим.

C>>Ну покажи как ты будешь стековые объекты с детерминированым деструкторами и ref-классы совмещать (без финализаторов — это хак).
КЛ>С финализатором как раз просто, а вот что делать в случае, когда объект реализует IDisposable. Что делать что делать. В финализаторе звать dtor автоматом (пусть компайлер зовет). В Dispose звать ручками. Тогда получится некий аналог IDisposable. Но я этого не отрицаю. Просто синтаксический сахарок.
И стоит ради такого сахара вводить еще одну фундаментальную сущность языка?

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, anton_t, Вы писали:

КЛ>[]

_>>Особенно сладки стековые объекты в С++, когда идёт отмотка стека из-за исключения и тут из деструктора вылетает новое исключение

КЛ>А ты возьми за правило, что деструкторы не должны кидать исключений. И вообще, пост твой не в тему.

Действительно, прелести С++ это отдельный разговор

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

R>Помедитируй над этим С++ кодом, и почувствуй какой бред ты говоришь.

R>

R>string f(string s)
R>{
R>  string s2 = f2();
R>  return s + s2 + "!";
R>}
R>

Помедитировал. Беру свои слова обратно. Для задач вроде этой С++ отлично подходит.