В пятницу выдался свободный вечер, такой когда срочных дел нет, а несрочные делать лень и хочется чего-то для души. Для души я решил посмотреть какой-нибудь доклад CppCon 2015 которая прошла чуть больше месяца назад. Как правило на видео доклады вживую у меня никогда времени не хватает, но тут все так уж сложилось — прошел месяц, C++-17 уже на носу и конференция должна была быть интересной, но никто еще ничего о ней не писал, а тут еще и вечер свободный.В общем я быстренько ткнул мышкой в первый привлекший внимание заголовок: Andrei Alexandrescu “Declarative Control Flow" и приятно провел вечер. А потом решил поделиться с хабрасообществом вольным пересказом.Давайте вспомним что такое обычный для C++ Explicit Flow Control, напишем транзакционнo стабильную функцию для копирования файла, стабильную в том смысле что она имеет только два исхода: либо завершается успешно, либо по каким-либо причинам неуспешно, но при этом не имеет побочных эффектов, (красивое выражение — successful failure). Задача выглядит тривиальной, тем более если использовать boost::filesystem:
void copy_file_tr(const path& from, const path& to) {
path tmp=to+".deleteme";
try {
copy_file(from, tmp);
rename(tmp, to);
} catch(...) {
::remove(tmp.c_str());
throw;
}
}
void move_file_tr(const path& from, const path& to) {
copy_file_tr(from, to);
try {
remove(from);
} catch(...) {
::remove(to.c_str());
throw;
}
}
Декларативный стиль вместо этого обращает основное внимание на описании целей, при этом детальные инструкции по достижению сведены к необходимому минимуму, исполнение кода правильным образом происходит без непосредственного контроля за исполнением каждого шага. Это могло бы звучать как фантастика, однако такие языки — вокруг нас и мы их используем каждый день не задумываясь. Посмотрите — SQL, make, regex, все они декларативны по своей природе. Что мы можем использовать в C++ чтобы достичь такого эффекта?
RAII и деструкторы имеют декларативную природу поскольку вызываются неявно, а также близкая идиома ScopeGuard. Давайте посмотрим как устроен макрос SCOPE_EXIT с использованием ScopeGuard, это на самом деле довольно старый трюк, достаточно сказать что одноименный макрос присутствует в boost начиная с версии 1.38. И тем не менее, повторение мать учения:
namespace detail {
enum class ScopeGuardOnExit {};
template<typename<Fun> ScopeGuard<Fun> operator+
(ScopeGuardOnExit, Fun&& fn) {
return ScopeGuard<Fun>(std::forward<Fun>(fn));
}
}
#define SCOPE_EXIT auto ANONIMOUS_VARIABLE(SCOPE_EXIT_STATE) = ::detail::ScopeGuardOnExit + (&)[]
}
Тут все достаточно прямолинейно, создается анонимная переменная содержащая ScopeGuard, который содержит лямбда-функцию, определенную непосредственно за вызовом макроса и которая функция будет вызвана в деструкторе этой переменной, который рано или поздно но при выходе из области видимости будет вызван. (В легких кончился воздух, а то бы я еще пару придаточных добавил)
Для полноты картины, вот так выглядят вспомогательные макросы:
#define CONACTENATE_IMPL(s1,s2) s1##s2
#define CONCATENATE(s1,s2) CONCATENATE_IMPL(s1,s2)
#define ANONYMOUS_VARIABLE(str) CONCATENATE(str,__COUNTER__)
void fun() {
char name[] = "/tmp/deleteme.XXXXXX";
auto fd = mkstemp(name);
SCOPE_EXIT { fclose(fd); unlink(name); };
auto buf = malloc(1024*1024);
SCOPE_EXIT { free(buf); };
...
}
class UncaughtExceptionCounter {
int getUncaughtExceptionCount() noexcept;
int exceptionCount_;
public:
UncaughtExceptionCounter()
: exceptionCount_(std::uncaught_exceptions()) {}
bool newUncaughtException() noexcept {
return std::uncaught_exceptions() > exceptionCount_;
}
};
Вот теперь можно нарисовать полноценный шаблон который будет вызываться в случае успеха или неуспеха:
template <typename FunctionType, bool executeOnException>
class ScopeGuardForNewException {
FunctionType function_;
UncaughtExceptionCounter ec_;
public:
explicit ScopeGuardForNewException(const FunctionType& fn)
: function_(fn) {}
explicit ScopeGuardForNewException(FunctionType&& fn)
: function_(std::move(fn)) {}
~ScopeGuardForNewException() noexcept(executeOnException) {
if (executeOnException == ec_.isNewUncaughtException()) {
function_();
}
}
};
Дальше все становится тривиальным, подобно SCOPE_EXIT мы определяем новый макрос:
enum class ScopeGuardOnFail {};
template <typename FunctionType>
ScopeGuardForNewException<
typename std::decay<FunctionType>::type, true>
operator+(detail::ScopeGuardOnFail, FunctionType&& fn) {
return ScopeGuardForNewException<
typename std::decay<FunctionType>::type, true
>(std::forward<FunctionType>(fn));
}
#define SCOPE_FAIL auto ANONYMOUS_VARIABLE(SCOPE_FAIL_STATE) = ::detail::ScopeGuardOnFail() + [&]() noexcept
Посмотрим как теперь будут выглядеть исходные примеры:
void copy_file_tr(const path& from, const path& to) {
bf::path t = to.native() + ".deleteme";
SCOPE_FAIL { ::remove(t.c_str()); };
bf::copy_file(from, t);
bf::rename(t, to);
}
void move_file_tr(const path& from, const path& to) {
bf::copy_file_transact(from, to);
SCOPE_FAIL { ::remove(to.c_str()); };
bf::remove(from);
}
int string2int(const string& s) {
int r;
SCOPE_SUCCESS { assert(int2string(r) == s); };
...
return r;
}
Заключение от первого лица
Все это наводит на определенные мысли о том что нас может ждать в недалеком будущем. Мне прежде всего бросилось в глаза то что все ссылки в докладе далеко не новы. Например, SCOPE_EXIT присутствует в boost.1.38, то есть уже почти десять лет, а статья самого Александреску о ScopeGuard вышла в Dr.Dobbs аж в 2000м году. Хочу напомнить что Александреску имеет репутацию провидца и пророка, так созданная им как демонстрация концепции библиотека Loki легла в основу boost::mpl, а потом почти полностью вошла в новый стандарт и еще задолго до того фактически задала идиомы метапрограммирования. С другой стороны, сам Александреску последнее время в основном занимается развитием языка D где все три упомянутые конструкции — scope exit, scope success and scope failure являются частью синтаксиса языка и давно заняли в нем прочное место.Еще один любопытный момент — доклад Эрика Ниблера на той же самой конференции называется Ranges for the Standard Library. Хочу напомнить что ranges — еще одна стандартная концепция языка D, дальнейшее развитие концепции итераторов. Более того, сам доклад — фактически перевод (с D на C++) замечательной статьи H.S.Teoh Component programming with ranges.
Таким образом, похоже что C++ начал активно включать в себя концепции других языков, которые впрочем он сам же и инициировал. В любом случае, грядущий C++-17 похоже не будет рутинным обновлением. Учитывая уроки истории, семнадцатый год скучным не бывает, запасаемся попкорном, ананасами и рябчиками.
Литература
Здесь просто собраны в одном месте ссылки уже включенные в пост.- Оригинальный аудио доклад
- Ссылка на материалы CppCon 2015
- Слайды к докладу Александреску
- Ссылка на оригинальную статью о ScopeGuard 2000г
- Документация по boost::ScopeExit
- Предложение Herb Sutter по изменению uncaught_exception()
- Оригинальная статья по ranges в D, кому интересно, хорошее неформальное введение в один из аспектов этого языка
Комментарии (19)
beeruser
24.11.2015 11:35+5К слову говоря, файловые операции весьма условно могут быть «транзакционно стабильными».
То что файл закрылся без ошибок, не означает что он вообще будет записан.
https://fgiesen.wordpress.com/2015/10/25/reading-and-writing-are-less-symmetric-than-you-probably-think/
tangro
24.11.2015 11:46Я, может быть, торможу, но вся статья ведь построена на предположении, что мы ловим «catch(...)» и вообще никак не обрабатываем определённые типы исключений — а где это вы такое в нормальном продакшн-коде видели?
AMDmi3
24.11.2015 14:01Тормозите, исключения прокидываются на уровень выше. Плохим стилем же обычно считается безусловное игнорирование исключений (catch(...){})
tangro
24.11.2015 16:48Ну, если они прокидываются, то мы всё-равно приходим к необходимости написания ифа или свича в зависимости от их типа, плюс обработки того самого catch(...). В итоге у нас будет весь тот же самый код, только расположенный чуть выше и со странным никому не известным макросом вместо всем известного и входящего в стандарт try\catch. И в чём выигрыш?
degs
24.11.2015 18:45Разница в акцентах использования. Если try/catch в каком-то смысле эквивалентно проверке if(result != 0)/else, то scope задает в начале блока действия которые надо выполнить при любом выходе, успешном выходе и/или неуспешном выходе из области видимости. Просто еще одна абстракция на ступеньку выше. Однако я поглядел быстренько на D код, да, там этот стиль используется очень широко и действительно сильно меняет вид кода.
Макросы конечно неуклюжи и вряд ли будут использоваться в таком виде. Как я понимаю идея доклада — то что в C++ уже сейчас тоже возможен такой стиль написания и при внесении небольших изменений в синтаксис языка это станет нативной фичей.
А то что стандарт теперь прямо рекомендует избегать чрезмерного использования try/catch вас не удивляет? Еще совсем ведь недавно даже явная спецификация типов исключений была рекомендованным стандартом и тоже ее отмену многие в штыки встречали.
BalinTomsk
24.11.2015 18:48-2В нормальном продакшине и throw под запретом. Мы же не на каком-то богохульном java пишем. throw только для использования внутри драйверов при обработке аппаратных исключений.
degs
24.11.2015 19:09throw — совершенно нормальный и очень удобный механизм перехвата ошибок из глубины вложенных функций, альтернатива ему — бесконечная лента проверок возвращаемого значения которая масштабируется гораздо хуже, от слова совсем. В продакшне бывает под запретом что угодно, но как правило это волевое решение менеджера, который либо вообще далек от написания кода, либо прочитал лет… дцать назад книжку где ему так посоветовали. Я бы не стал называть «нормальной» команду где исключения под запретом, хотя легко могу себе такое представить.
BalinTomsk
24.11.2015 23:55Я работал в нескольких компаниях из топ 100 — ни у кого там даже в мыслях нету писать в предложенном вами стиле.
И это не капризы менеджеров.
Да, Гугль тоже можно причислить к ненормальным.Lol4t0
25.11.2015 00:36Гугль — это
1. легаси
2. максимальное упрощение, идущее на пользу в масштабах корпорации
Для того, чтобы равняться на Гугль, надо быть гуглем
degs
25.11.2015 05:03Естественно, это не библиотека и к использованию в продакшне не предназначено. Это — концепция, которая как я предполагаю будет где-то обкатана, в том же бусте например и потом предложена к включению в стандарт.
Да, Гугль тоже можно причислить к ненормальным
я наверное что-то не понял, это здесь вообще к чему?BalinTomsk
25.11.2015 05:28Потому что это нерабочая концепция. Может в виде учебных примеров и красиво а в жизни малоприменимо.
Microsoft отказался примерно к 2005 году от такого стиля — и вот почему.
Я когда extended stored procedures отлаживал под MSSQL2000 — у меня шторма исключений в дебагере пролетали, к счастью в MSSQL2005 от этого отказались и на курсах Microsoft настоятельно таким стилем не рекомендовали пользоватся.
Забуду я где оттрайкетчить вызов из такой библиотеки и упадет мой сервер в самом неожиданном месте.degs
25.11.2015 06:26Не обижайтесь только, вы по-моему не поняли концепции. Забудьте про макросы, они используются только потому что в текущей версии C++ без них не обойтись. Пусть у нас будут, как в D, языковые конструкции scope exit, skope success и scope fail. С try/catch они не связаны напрямую вообще никак, но пусть у вас в теле некоторой функции определены три оператора:
scope exit {… }
scope success {… }
scope fail {… }
Эта функция так или иначе когда-нибудь завершится, если это будет нормальный выход, то будут вызваны первые два функтора; если будет выброшено исключение, то оно будет где-нибудь поймано и тогда в нем будут вызваны первый и третий функтор. Александреску утверждает что это мощная концепция которая будет очень к месту в C++ и я с ним полностью согласен, не в том смысле что она заменит собой все остальное, а в том что будет еще один полезный архитектурный элемент.
А насчет того что посоветовала Microsoft в 2005 году… Этого стиля тогда просто не было и быть не могло.
Во-первых C++ в 2005-м был совсем другим и я сомневаюсь что кто-то мог тогда дать осмысленный совет для 2015. А во-вторых, мы с Вами примерно ровесники (и похоже даже дважды земляки), я например помню как они яростно боролись с TCP/IP, потом с std::string и еще чем-то там из std::, потом еще с чем-то..., короче они не пророки, в этой области по крайней мере, как впрочем и ни одна из крупных современных компаний. В общем совет от Microsoft 2005 года сегодня на путеводную звезду никак не тянет.
Gorthauer87
24.11.2015 12:09А где здесь декларативное программирование? Слова scope, control flow как-то не вяжутся с ним. Да и потом, опять кучи макросов, которые выглядят громоздко.
Lol4t0
25.11.2015 00:12Я может чего-то не понимаю, и вообще статью не читал, но SOLID-ный дизайн с использовнием RAII выглядит вот так
struct Temporary { ~Temporary() { remove(path); } const ::path path; }; void copy_file_tr(const path& from, const path& to) { Temporary tmp {to+".deleteme"}; copy_file(from, tmp.path); rename(tmp.path, to); }
При этом, естественно, и с move_file все сразу становится прощеdegs
25.11.2015 05:20Ну так это оно и есть, если вы еще не заметили все метапрограммирование сводится к тому чтобы вместо таких вот классов, создаваемых специально для каждого случая предоставить готовый универсальный шаблон.
Раз уж вы не читали, я специально для вас скажу суть в двух предложениях:
— В узкотехническом смысле, вдобавок к макросу SCOPE_EXIT, который известен уже 15 лет минимум, скоро можно будет добавить еще два — SCOPE_SUCCESS и SCOPE_FAIL используя новую функцию int uncaught_exceptions(), которой еще правда нет, но появится в C++17.
— В широком архитектурном смысле, использование этих трех конструкций позволяет писать на C++ в декларативном стиле, и приведены иллюстрации как это может выглядеть.
На самом деле это все.Lol4t0
25.11.2015 10:29+1Универсальный шаблон и так уже есть — unique_ptr со своим Deleter. Ну то есть технически вы можете сделать
Но даже это не нужно, потому чтоTemporary — вполне самостоятельный класс, и совершенно непонятно, почему это не нужно его выделить?std::unique_ptr<const char, decltype(remove1)*> autodelete(tmp.c_str(), remove);
А уж использовать ужасные С-ные SCOPE* вместо RAII просто дикость какая-то на мой взгляд
pavelsh
У меня ощущение, что go произвел на Александреску впечатление.
Тут и defer-ы появляются и try-catch критикуются.
aspcartman
Может, наоборот, учитывая время выхода статей? :)
NeoCode
Эти defer'ы реализованы в языке D вместе с исключениями (поэтому в отличие от одного defer в Go, в D целых три ключевых слова — scope(exit), scope(success) и scope(failure) — для общего случая, выхода без исключения и выхода по исключению, что видимо и позаимствовано в Boost.ScopeExit и здесь). А сама концепция подозреваю что более древняя чем реализации Go, D и Boost, наверняка в каких-нибудь теоретических трудах есть.