Чому Java / C # не може реалізувати RAII?

Питання: Чому Java / C # не може реалізувати RAII?

Пояснення: Я знаю, що сміттєзбірник не є детермінованим. Таким чином, з поточними особливостями мови неможливо автоматично викликати метод об'єкта Dispose () при виході з області дії. Але чи можна додати таку детерміновану ознаку?

Моє розуміння:

Я вважаю, що реалізація RAII повинна відповідати двом вимогам:
1. Термін експлуатації ресурсу повинен бути пов'язаний із сферою застосування.
2. Неявне. Вивільнення ресурсу повинно відбуватися без явного твердження програміста. Аналогічно сміттєзбірнику, що звільняє пам'ять без явного твердження. "Неявність" має виникати лише в точці використання класу. Звичайно, автор бібліотеки класів повинен явно реалізувати деструктор або метод Dispose ().

Java / C # задовольняють пункт 1. У C # ресурс, що реалізує IDisposable, може бути прив’язаний до області "використання":

void test()
{
    using(Resource r = new Resource())
    {
        r.foo();
    }//resource released on scope exit
}

Це не задовольняє пункт 2. Програміст повинен явно прив'язати об'єкт до спеціальної області "використання". Програмісти можуть (і робити) забути явно прив’язати ресурс до сфери, створюючи витік.

Насправді блоки "використання" перетворюються компілятором для спроби остаточного розпорядження () кодом. Він має такий самий чіткий характер, як шаблон спроби остаточного розпорядження (). Без неявного випуску гачком сфери є синтаксичний цукор.

void test()
{
    //Programmer forgot (or was not aware of the need) to explicitly
    //bind Resource to a scope.
    Resource r = new Resource(); 
    r.foo();
}//resource leaked!!!

Я вважаю, що варто створити мовну функцію в Java / C #, щоб дозволити спеціальні об'єкти, які підключені до стека за допомогою смарт-покажчика. Ця функція дозволить вам позначити клас як обмежений діапазон, щоб він завжди створювався гаком до стеку. Можуть бути варіанти для різних типів смарт-покажчиків.

class Resource - ScopeBound
{
    /* class details */

    void Dispose()
    {
        //free resource
    }
}

void test()
{
    //class Resource was flagged as ScopeBound so the tie to the stack is implicit.
    Resource r = new Resource(); //r is a smart-pointer
    r.foo();
}//resource released on scope exit.

Я думаю, що імпліцитність "варта того". Так само, як імпліцитність збирання сміття "варта". Явне використання блоків освіжає очі, але не дає семантичної переваги перед спробою остаточно-розпорядитися ().

Чи недоцільно реалізувати таку функцію на мовах Java / C #? Чи можна його ввести, не порушуючи старий код?

Таке розширення мови було б значно складніше та інвазивніше, ніж ви думаєте. Ви не можете просто додати

якщо час життя змінної типу, пов'язаного зі стеком, закінчується, викликайте Disposeоб'єкт, на який він посилається

до відповідного розділу мовної специфікації, і це потрібно зробити. Я проігнорую проблему тимчасових значень ( new Resource().doSomething()), яку можна вирішити трохи більш загальним формулюванням, це не найсерйозніша проблема. Наприклад, цей код буде порушений (і подібне може бути взагалі неможливо зробити):

File openSavegame(string id) {
    string path = ... id ...;
    File f = new File(path);
    // do something, perhaps logging
    return f;
} // f goes out of scope, caller receives a closed file

Тепер вам потрібні визначені користувачем конструктори копій (або переміщення конструкторів) і почніть викликати їх скрізь. Це не лише несе наслідки для продуктивності, але також робить ці речі ефективно типовими типами, тоді як майже всі інші об'єкти є типовими. У випадку Java це радикальне відхилення від того, як працюють об’єкти. У C # менше (вже є structs, але для них не визначені користувачем конструктори копій AFAIK), але він все ще робить ці об'єкти RAII більш спеціальними. Крім того, обмежена версія лінійних типів (пор. Іржа) також може вирішити проблему ціною заборони псевдоніму, включаючи передачу параметрів (якщо ви не хочете ввести ще більшу складність, прийнявши іржаві позикові позики та перевірку позик).

Це можна зробити технічно, але ви закінчите категорію речей, які сильно відрізняються від усього іншого в мові. Це майже завжди погана ідея, що має наслідки для виконавців (більше кращих випадків, більше часу / витрат у кожному відділі) та користувачів (більше понять для вивчення, більше можливості помилок). Додаткових зручностей не варто.

Найбільша складність у здійсненні чогось подібного для Java або C # - це визначення способу роботи передачі ресурсів. Вам знадобиться якийсь спосіб продовжити термін служби ресурсу поза рамками. Поміркуйте:

class IWrapAResource
{
    private readonly Resource resource;
    public IWrapAResource()
    {
        // Where Resource is scope bound
        Resource builder = new Resource(args, args, args);

        this.resource = builder;
    } // Uh oh, resource is destroyed
} // Crap, there's no scope for IWrapAResource we can bind to!

Найгірше те, що це може бути не очевидно для виконавця IWrapAResource:

class IWrapSomething<T>
{
    private readonly T resource; // What happens if T is Resource?
    public IWrapSomething(T input)
    {
        this.resource = input;
    }
}

Щось на зразок usingвисловлювання C #, ймовірно, настільки ж близьке, як ви збираєтеся прийти до семантики RAII, не вдаючись до посилальних підрахунків ресурсів або примушуючи семантику значення скрізь, як C або C ++. Оскільки у Java та C # є неявна обмін ресурсами, якими керує сміттєзбірник, мінімум, який потрібно програмісту, - це вибрати область, до якої прив’язаний ресурс, а саме це usingвже робиться.

Причина, по якій RAII не може працювати на такій мові, як C #, але вона працює в C ++, полягає в тому, що в C ++ ви можете вирішити, чи об’єкт справді тимчасовий (виділивши його на стек) чи довговічний (за виділення його на купу за допомогою newта використання покажчиків).

Отже, в C ++ ви можете зробити щось подібне:

void f()
{
    Foo f1;
    Foo* f2 = new Foo();
    Foo::someStaticField = f2;

    // f1 is destroyed here, the object pointed to by f2 isn't
}

У C # ви не можете розмежовувати два випадки, тому компілятор не мав би поняття, чи доопрацьовувати об’єкт чи ні.

Що ви можете зробити, це ввести якийсь спеціальний тип локальної змінної, який ви не можете помістити в поля тощо. Це саме те, що робить C ++ / CLI. У C ++ / CLI ви пишете такий код:

void f()
{
    Foo f1;
    Foo^ f2 = gcnew Foo();
    Foo::someStaticField = f2;

    // f1 is disposed here, the object pointed to by f2 isn't
}

Це компілюється в основному той же IL, що і наступний C #:

void f()
{
    using (Foo f1 = new Foo())
    {
        Foo f2 = new Foo();
        Foo.someStaticField = f2;
    }
    // f1 is disposed here, the object pointed to by f2 isn't
}

На закінчення, якщо б я здогадався, чому дизайнери C # не додали RAII, це тому, що вони вважали, що мати два різних типи локальних змінних не варто, головним чином тому, що для мови з GC детермінована доопрацювання не корисна, що часто.

* _{Не без еквівалента &оператора, який у C ++ / CLI є %. Хоча це є "небезпечним" в тому сенсі, що після закінчення методу, поле посилається на розміщений об'єкт.}

Якщо те, що вас турбує з usingблоками, - це їх явність, можливо, ми можемо зробити невеликий крок до меншої чіткості, а не змінювати специфікацію C #. Розглянемо цей код:

public void ReadFile ()
{
  string filename = "myFile.dat";
  local Stream file = File.Open(filename);
  file.Read(blah blah blah);
}

Бачите localключове слово, яке я додав? Все, що це робиться, - це додати трохи більше синтаксичного цукру, як usingі сказати компілятору викликати Disposeв finallyблок в кінці області змінної. Це все. Це абсолютно рівнозначно:

public void ReadFile ()
{
  string filename = "myFile.dat";
  using (Stream file = File.Open(filename))
  {
      file.Read(blah blah blah);
  }
}

але з неявним обсягом, а не з явним. Це простіше, ніж інші пропозиції, оскільки мені не доведеться визначати клас як обмежений діапазон. Просто чистіший, неявніший синтаксичний цукор.

Тут можуть виникнути проблеми із складно вирішуваними сферами, хоча я зараз не бачу цього, і я вдячний за всіх, хто може його знайти.

Для прикладу того, як RAII працює на мові, зібраній зі сміттям, перевірте withключове слово в Python . Замість того, щоб покладатися на детерміновано знищені об'єкти, це дозволить вам пов’язати __enter__()та __exit__()методи із заданою лексичною сферою. Поширений приклад:

with open('output.txt', 'w') as f:
    f.write('Hi there!')

Як і у стилі RAII C ++, файл закриється при виході з цього блоку, незалежно від того, чи це "нормальний" вихід, a break, негайний returnвиняток.

Зауважте, що open()виклик - це звичайна функція відкриття файлів. щоб зробити цю роботу, повернутий об’єкт файлу включає два способи:

def __enter__(self):
  return self
def __exit__(self):
  self.close()

Це поширена ідіома в Python: об'єкти, пов'язані з ресурсом, зазвичай включають ці два методи.

Зауважте, що об’єкт файлу все ще може залишатися виділеним після __exit__()виклику, важливо те, що він закритий.