У чому полягає концептуальна відмінність нарешті від деструктора?

По-перше, я добре знаю, чому в C ++ немає конструкції "нарешті"? але тривале обговорення коментарів щодо іншого питання, здається, вимагає окремого питання.

Окрім питання, що finallyв C # та Java в основному можуть існувати лише один раз (== 1) на область дії, і одна область може мати декілька деструкторів C ++ (== n), я думаю, що вони по суті одне і те ж. (З деякими технічними відмінностями.)

Однак інший користувач стверджував :

... Я намагався сказати, що dtor є за своєю суттю інструментом для (Release sematics) і, нарешті, по суті є інструментом для (семантика фіксації). Якщо ви не бачите чому: подумайте, чому виправдано кидати винятки один на одного, нарешті, блоками, і чому це не для деструкторів. (У певному сенсі це річ з даними та контролем. Деструктори - для випуску даних, нарешті, для звільнення контролю. Вони різні; шкода, що C ++ пов'язує їх разом.)

Хтось може це очистити?

• Транзакція ( try)
• Вихід / відповідь про помилку ( catch)
• Зовнішня помилка ( throw)
• Помилка програміста ( assert)
• Відкат (найближчим моментом можуть бути охоронці сфери застосування на мовах, які підтримують їх на місцях)
• Вивільнення ресурсів (деструктори)
• Різний потік управління, незалежний від транзакцій ( finally)

Неможливо придумати кращий опис, finallyніж незалежний від транзакцій незалежний від управління потік. Це не обов'язково відображати так безпосередньо будь-яку концепцію високого рівня в контексті мислення, пов'язаного з трансакціями та відновленням помилок, особливо на теоретичній мові, яка має і деструктори, і finally.

Найбільше мені не вистачає мовної функції, яка безпосередньо представляє концепцію відкочування зовнішніх побічних ефектів. Охоронці сфери застосування на таких мовах, як D - це найближче, що я можу придумати, що є близьким до представлення цієї концепції. З точки зору потоку управління, відкат у межах певної функції повинен відрізняти винятковий шлях від звичайного, одночасно автоматизуючи відкат неявно будь-яких побічних ефектів, викликаних функцією, якщо транзакція не вдасться, але не тоді, коли транзакція проходить успішно . Це досить просто зробити з деструкторами, якщо ми, скажімо, succeededв кінці нашого блоку спробу встановимо булеве значення, яке має значення true, щоб запобігти логіці відкату в деструкторі. Але це досить крутий спосіб зробити це.

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

У такий спосіб вони є - так само, як Ferrari і транзит можуть бути використані для того, щоб спустити по магазинах пінту молока, хоча вони розроблені для різних цілей.

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

Це було б не дуже добре, і навіть незважаючи на те, що .NET представив IDispose як ручний керуючий інструмент, а використання блоків як спроби зробити це ручне управління трохи простішим, все-таки це не те, що ви хотіли б зробити на практиці .

З моєї точки зору, головна відмінність полягає в тому, що деструктор c ++ - це неявний механізм (автоматично викликається) для звільнення виділених ресурсів, тоді як спроба ... нарешті може бути використана як явний механізм для цього.

У програмах c ++ програміст відповідає за вивільнення виділених ресурсів. Зазвичай це реалізується в деструкторі класу і робиться негайно, коли змінна виходить за межі області або коли викликається видалення.

Коли в c ++ створюється локальна змінна класу без використання newресурсів цих екземплярів, вивільнені неявним деструктором, коли є виняток.

// c++
void test() {
    MyClass myClass(someParameter);
    // if there is an exception the destructor of MyClass is called automatically
    // this does not work with
    // MyClass* pMyClass = new MyClass(someParameter);

} // on test() exit the destructor of myClass is implicitly called

У java, c # та інших системах з автоматичним управлінням пам'яттю система збору сміття приймає рішення про знищення екземпляра класу.

// c#
void test() {
    MyClass myClass = new MyClass(someParameter);
    // if there is an exception myClass is NOT destroyed so there may be memory/resource leakes

    myClass.destroy(); // this is never called
}

Для цього немає неявного механізму, тому вам доведеться це явно запрограмувати, використовуючи спробувати остаточно

// c#
void test() {
    MyClass myClass = null;

    try {
        myClass = new MyClass(someParameter);
        ...
    } finally {
        // explicit memory management
        // even if there is an exception myClass resources are freed
        myClass.destroy();
    }

    myClass.destroy(); // this is never called
}

Радий, що ви опублікували це як питання. :)

Я намагався сказати, що деструктори і finallyконцептуально різні:

• Деструктори для випуску ресурсів ( даних )
• finallyпризначений для повернення абоненту ( контроль )

Розглянемо, скажімо, цей гіпотетичний псевдокод:

try {
    bar();
} finally {
    logfile.print("bar has exited...");
}

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

• Ні річ не бути «придбала» або «створив»
• Якщо не надрукувати файл журналу, це не призведе до витоку ресурсів, пошкодження даних тощо (якщо припустити, що файл журналу тут не повертається в програму в іншому місці)
• Це правомірно logfile.printвідмовити, тоді як руйнування (концептуально) не може зазнати збою

Ось ще один приклад, цього разу, як у Javascript:

var mo_document = document, mo;
function observe(mutations) {
    mo.disconnect();  // stop observing changes to prevent re-entrance
    try {
        /* modify stuff */
    } finally {
        mo.observe(mo_document);  // continue observing (conceptually, this can fail)
    }
}
mo = new MutationObserver(observe);
return observe();

У наведеному вище прикладі, знову ж таки, немає ресурсів для звільнення.
Насправді, finallyблок отримання внутрішніх ресурсів для досягнення своєї мети, яка потенційно може потерпіти невдачу. Отже, не має сенсу використовувати деструктор (якщо у Javascript був такий).

З іншого боку, у цьому прикладі:

b = get_data();
try {
    a.write(b);
} finally {
    free(b);
}

finallyзнищує ресурс, b. Це проблема даних. Проблема полягає не в чистому поверненні контролю абоненту, а в уникненні витоків ресурсів.
Відмова не є варіантом, і не повинен (концептуально) ніколи виникати.
Кожен реліз bобов'язково поєднується з придбанням, і є сенс використовувати RAII.

Іншими словами, тільки тому, що ви можете використовувати або для імітації, або це не означає, що обидві є однією і тією ж проблемою, або що обидва є відповідними рішеннями для обох проблем.

k3b відповідь дійсно добре це фразує:

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

Щодо "ресурсів", то я хотів би посилатися на Джона Калба: RAII повинен означати, що Придбання відповідальності - це ініціалізація .

У будь-якому випадку, що стосується неявних та явних, то, здається, це насправді:

• D'tor - це інструмент для визначення того, які операції повинні відбуватися - неявно - коли закінчується термін експлуатації об'єкта (який часто збігається з кінцем області дії)
• Нарешті-блок є інструментом, щоб чітко визначити, які операції повинні відбуватися в кінці області дії.
• Крім того, технічно вам завжди дозволено кидати нарешті, але дивіться нижче.

Я думаю, що це все для концептуальної частини, ...

... зараз є ІМХО кілька цікавих деталей:

• try / catch / нарешті не вистачає в тому, що немає faultблоку для запуску коду, який повинен запускатися лише у випадку виняткового виходу з області застосування.
• Деструктори можуть бути використані, щоб нарешті побудувати техніку - дивіться SCOPE_EXIT, SCOPE_FAILі SCOPE_SUCCESS в бібліотеці глупоти . Див. Андрія Олександреску: Поводження з помилками в C ++ / Деклараційному контрольному потоці (проведено в NDC 2014 )
• SCOPE_EXIT може реплікувати, нарешті, лише настільки багато, оскільки технічно прекрасно викинути нарешті, поки він просто не працює надійно від деструктора.
• Однак мені здається, що люди, як правило, вважають, що кидання зсередини нарешті є поганою ідеєю .

Я також не думаю, що c'tor / d'tor потрібно концептуально «придбати» або «створити» що-небудь, крім відповідальності за виконання деякого коду в деструкторі. Що, нарешті, також робить: запустіть якийсь код.

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

(Плюс, я зовсім не переконаний, що "добрий" код повинен вийти зрештою - можливо, це ще одне ціле питання до себе.)