Чому в C ++ немає конструкції "нарешті"?

Поводження з винятками в C ++ обмежується спробою / кидати / ловити. На відміну від Object Pascal, Java, C # і Python, навіть у C ++ 11, finallyконструкція не була реалізована.

Я бачив дуже багато літератури на C ++, яка обговорювала "безпечний код для виключення". Ліппман пише, що безпечний код для виключення є важливою, але складною, важкою темою, що виходить за межі його Праймера - що, мабуть, означає, що безпечний код не є основним для C ++. Герб Саттер присвячує 10 глав цій темі у своєму винятковому С ++!

І все ж мені здається, що багато проблем, які виникали при спробі написання "безпечного коду для виключення", можна було б досить добре вирішити, якби finallyконструкція була реалізована, що дозволяє програмісту переконатися, що навіть у випадку винятку програма може бути відновлена до безпечного, стабільного, негерметичного стану, близького до точки розподілу ресурсів та потенційно проблемного коду. Як дуже досвідчений програміст Delphi і C #, я використовую спробу., Нарешті, досить широко блокується в моєму коді, як і більшість програмістів на цих мовах.

Розглядаючи всі "дзвіночки", застосовані в C ++ 11, я з подивом виявив, що "нарешті" все ще не було.

Отже, чому finallyконструкція ніколи не була реалізована в C ++? Це дійсно не дуже складна або передова концепція, щоб зрозуміти, і йде довгий шлях до допомоги програмісту написати «код безпечного виключення».

Як деякий додатковий коментар до відповіді @ Nemanja (який, оскільки він цитує Stroustrup, насправді настільки ж хороший відповідь, як ви можете отримати):

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

Мовою, яка використовує try/ finally, код може виглядати приблизно так:

database.Open();
try {
    database.DoRiskyOperation();
} finally {
    database.Close();
}

Простий і прямолінійний. Однак є кілька недоліків:

• Якщо мова не має детермінованих деструкторів, я завжди повинен писати finallyблок, інакше я просочую ресурси.
• Якщо DoRiskyOperationбільш ніж один виклик методу - якщо я маю зробити якусь обробку в tryблоці - то Closeоперація може закінчитися пристойним бітом від Openоперації. Я не можу написати прибирання поруч із моїм придбанням.
• Якщо у мене є кілька ресурсів, які потрібно придбати, а потім звільнити безпечним для винятку способом, я можу закінчитись декількома шарами try/ finallyблоками.

Підхід C ++ виглядатиме так:

ScopedDatabaseConnection scoped_connection(database);
database.DoRiskyOperation();

Це повністю вирішує всі недоліки finallyпідходу. У нього є кілька своїх недоліків, але вони відносно незначні:

• Є хороший шанс, що вам потрібно написати ScopedDatabaseConnectionклас самостійно. Однак це дуже проста реалізація - лише 4 або 5 рядків коду.
• Це передбачає створення додаткової локальної змінної - яку ви, мабуть, не шануєте, грунтуючись на вашому коментарі про те, що "постійно створювати та знищувати класи, щоб покластися на їх деструкторів, щоб очистити ваш безлад дуже поганий", - але хороший компілятор оптимізує будь-яка додаткова робота, яка включає додаткову локальну змінну. Хороший дизайн C ++ багато в чому покладається на подібні оптимізації.

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

Нарешті, оскільки RAII є настільки усталеною ідіомою в C ++, і щоб звільнити розробників частину тягаря написання численних Scoped...класів, існують такі бібліотеки, як ScopeGuard та Boost.ScopeExit, які полегшують подібний спосіб детермінованого очищення.

З Чому C ++ не забезпечує "нарешті" конструкцію? у стилі та техніці FAQ Bjarne Stroustrup C ++ :

Оскільки C ++ підтримує альтернативу, яка майже завжди є кращою: методика "отримання ресурсів - ініціалізація" (TC ++ PL3, розділ 14.4). Основна ідея - представити ресурс локальним об'єктом, щоб деструктор локального об'єкта звільнив ресурс. Таким чином, програміст не може забути випустити ресурс.

Причина, якої немає у C ++, finallyполягає в тому, що вона не потрібна в C ++. finallyвикористовується для виконання деякого коду незалежно від того, стався виняток чи ні, який майже завжди є певним кодом очищення. У C ++ цей код очищення повинен бути в деструкторі відповідного класу, і деструктор завжди буде викликатися, як і finallyблок. Ідіома використання деструктора для очищення називається RAII .

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

Причина безпеки винятків обговорюється більше у спільноті C ++, ймовірно, також випливає з того, що в C ++ ви повинні бути більш обізнані про те, що може піти не так, оскільки в мові менше мереж безпеки.

Інші обговорили RAII як рішення. Це абсолютно вдале рішення. Але це насправді не стосується того, чому вони не додали finallyтак добре, оскільки це дуже бажана річ. Відповідь на це є більш важливим для проектування та розробки C ++: протягом усього розвитку C ++ ті, хто бере участь, наполегливо чинили опір впровадженню конструктивних особливостей, які можна досягти за допомогою інших функцій без величезної суєти, особливо коли це вимагає введення нових ключових слів, які можуть зробити старіший код несумісним. Оскільки RAII надає високофункціональну альтернативу, finallyі ви фактично можете передати свій власний finallyC ++ 11, заклик до нього мало.

Все, що вам потрібно зробити, це створити клас, Finallyякий викликає функцію, передану його конструктору, в його деструкторі. Тоді ви можете зробити це:

try
{
    Finally atEnd([&] () { database.close(); });

    database.doRisky();
}

Більшість нативних програмістів на C ++, як правило, віддадуть перевагу чітко розробленим об'єктам RAII.

Ви можете використовувати шаблон "пастки" - навіть якщо ви не хочете використовувати блок "пробувати / ловити".

Помістіть простий об’єкт у необхідному обсязі. У цьому об’єкті деструктор вклав вашу логіку "остаточного". Незважаючи ні на що, коли стек буде розкручений, викличе деструктор об'єкта, і ви отримаєте ваші цукерки.

Що ж, ви можете сортувати власний finallyролик, використовуючи Lambdas, який отримав би наступне для складання штрафу (використовуючи приклад без RAII, звичайно, не найприємніший фрагмент коду):

{
    FILE *file = fopen("test","w");

    finally close_the_file([&]{
        cout << "We're closing the file in a pseudo-finally clause." << endl;
        fclose(file);
    });
}

Дивіться цю статтю .

Я не впевнений, що згоден з твердженнями про те, що RAII - це супернабір finally. Ахілесова п'ята RAII проста: винятки. RAII реалізується з деструкторами, і викидати з деструктора завжди неправильно в C ++. Це означає, що ви не можете використовувати RAII, коли вам потрібен код очищення. Якби вони finallyбули реалізовані, з іншого боку, немає підстав вважати, що не було б законним викидати з finallyблоку.

Розглянемо такий шлях коду:

void foo() {
    try {
        ... stuff ...
        complex_cleanup();
    } catch (A& a) {
        handle_a(a);
        complex_cleanup();
        throw;
    } catch (B& b) {
        handle_b(b);
        complex_cleanup();
        throw;
    } catch (...) {
        handle_generic();
        complex_cleanup();
        throw;
    }
}

Якби ми мали, finallyми могли б написати:

void foo() {
    try {
        ... stuff ...
    } catch (A& a) {
        handle_a(a);
        throw;
    } catch (B& b) {
        handle_b(b);
        throw;
    } catch (...) {
        handle_generic();
        throw;
    } finally {
        complex_cleanup();
    }
}

Але я не можу знайти рівнозначну поведінку за допомогою RAII.

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