В пятницу выдался свободный вечер, такой когда срочных дел нет, а несрочные делать лень и хочется чего-то для души. Для души я решил посмотреть какой-нибудь доклад 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, кому интересно, хорошее неформальное введение в один из аспектов этого языка
