Здравствуйте, nen777w, Вы писали:

N>"Страх рождает гнев, гнев рождает ненависть."(С) не помню кто

дюна. кстати в звёздных войнах очень похожее

Здравствуйте, Evgeny.Panasyuk, Вы писали:

BFE>>С Guard более-менее понятно, а вот одно копирование лямбды будет так или иначе(в момент создания Guard).
EP>Там будет одно перемещение.
точно. С перемещением параметров, что указаны в квадратных скобках.

BFE>>Видимо надо завести ещё один Guard для указателя на функтор...

EP>Думаю одно перемещение не настолько страшно, тем более после инлайнинга оно скорей всего испарится.
Не уверен про инлайнинг, но, пожалуй, соглашусь.

EP>Да и теряется возможно обернуть всё это в удобный макрос:


EP>Это был такой тонкий намёк на то что на дворе уже C++14
Да ладно! Я только сегодня понял, что оператор --> можно переопределить:

struct Aux2
{
    const Aux2& operator--(int) const
    {
        return *this;
    }

    template<typename F>
    Guard<typename std::decay<F>::type> operator>(F &&f) const
    {
        return { std::forward<F>(f) };
    }
};

const Aux2 make_at_scope_exit{};

И вместо неясной мультипликации получаем интересный и понятный синтаксис:

        const auto&& guard = make_at_scope_exit7-->[&] { std::cout << "x=" << x << ": guard\n"; };

Здравствуйте, B0FEE664, Вы писали:

EP>>Да и теряется возможно обернуть всё это в удобный макрос:
BFE>

Это же действительно удобно. Не понимаю зачем отказываться от макросов там где они реально упрощают код.

EP>>Это был такой тонкий намёк на то что на дворе уже C++14
BFE>Да ладно! Я только сегодня понял, что оператор --> можно переопределить:

Подобным образом можно ещё и именованные операторы

Автор: Evgeny.Panasyuk
Дата: 24.01.14

вводить:

auto fibs = fix(cons(0) * cons(1) * (zipWith(sum) <ap> tail));
auto x = fibs <at> 101;

BFE>И вместо неясной мультипликации получаем интересный и понятный синтаксис:

Подразумевалось что мультипликация будет спрятана в макросе

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>>>Да и теряется возможно обернуть всё это в удобный макрос:
BFE>>
EP>Это же действительно удобно. Не понимаю зачем отказываться от макросов там где они реально упрощают код.
Макросы не упрощают код, они всего лишь прячут его.

EP>Подобным образом можно ещё и именованные операторы

Автор: Evgeny.Panasyuk
Дата: 24.01.14

вводить:
Не, это не то...
А вот оператор "Goes to" реально круто выглядит!
x = b------>asdf;

Не, ну реально круто! Вот, например, как задачка на собеседование. Может ли такой код быть валидным в C++:

a -------> m_n = 0;

Не многие поймут. Мало, кто сможет реализовать... (Да, да. "минусов" нечётное число!)

BFE>>И вместо неясной мультипликации получаем интересный и понятный синтаксис:
EP>Подразумевалось что мультипликация будет спрятана в макросе

А зачем тогда переменная aux? Прятали бы тогда прямо функцию.

Здравствуйте, B0FEE664, Вы писали:

EP>>>>Да и теряется возможно обернуть всё это в удобный макрос:
BFE>>>
EP>>Это же действительно удобно. Не понимаю зачем отказываться от макросов там где они реально упрощают код.
BFE>Макросы не упрощают код, они всего лишь прячут его.

Функции тоже прячут код, тем самым упрощая его, так же как и макросы.

BFE>Не, ну реально круто! Вот, например, как задачка на собеседование.

Конечно смотря на какую позицию, но в целом я бы не стал спрашивать ничего подобного.

BFE>Может ли такой код быть валидным в C++:
BFE>

BFE> a -------> m_n = 0;

BFE>Не многие поймут. Мало, кто сможет реализовать... (Да, да. "минусов" нечётное число!)

Раз нечётное, то перегрузка -- и -> ?

BFE>>>И вместо неясной мультипликации получаем интересный и понятный синтаксис:
EP>>Подразумевалось что мультипликация будет спрятана в макросе
BFE>А зачем тогда переменная aux? Прятали бы тогда прямо функцию.

Для того что бы был красивый синтаксис:

scope_exit
{
    // ...
};

С функцией вместо }; было бы });, что совсем не по фен-шую.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

BFE>>Макросы не упрощают код, они всего лишь прячут его.
EP>Функции тоже прячут код, тем самым упрощая его, так же как и макросы.
Функции код не прячут, они его группируют. Разница в способе взаимодействия с окружающим кодом и в количестве кода.

EP>Раз нечётное, то перегрузка -- и -> ?
да.

EP>С функцией вместо }; было бы });, что совсем не по фен-шую.
Понял.
Но всё равно, если речь о макросах, то о фен-шуе говорить не приходится. Как только понадобится сделать dismiss у guard'а или, например, параметры передать в тело лямбды, то начнутся эзотерические изыскания в дебрях макроса...

Здравствуйте, B0FEE664, Вы писали:

BFE>>>Макросы не упрощают код, они всего лишь прячут его.
EP>>Функции тоже прячут код, тем самым упрощая его, так же как и макросы.
BFE>Функции код не прячут, они его группируют. Разница в способе взаимодействия с окружающим кодом и в количестве кода.

В случае с scope_exit не вижу проблем, но естественно нужна документация.

EP>>С функцией вместо }; было бы });, что совсем не по фен-шую.
BFE>Понял.
BFE>Но всё равно, если речь о макросах, то о фен-шуе говорить не приходится. Как только понадобится сделать dismiss у guard'а или,

guard с dismiss'ом это уже совсем другая семантика нежели scope_exit.
Кстати, для таких случаев есть scope_failure:

{
    cout << "success case:" << endl;
    scope(exit)
    {
         cout << "exit" << endl;
    };
    scope(success)
    {
        cout << "success" << endl;
    };
    scope(failure)
    {
        cout << "failure" << endl;
    };
}
cout << string(16,'_') << endl;
try
{
    cout << "failure case:" << endl;
    scope(exit)
    {
        cout << "exit" << endl;
    };
    scope(success)
    {
        cout << "success" << endl;
    };
    scope(failure)
    {
        cout << "failure" << endl;
    };
    throw 1;
}
catch(int){}
// OUTPUT:
success case:
success
exit
________________
failure case:
failure
exit

http://ideone.com/EKsBDB
https://github.com/panaseleus/stack_unwinding
http://rsdn.ru/forum/cpp/4908728.1

Автор: Evgeny.Panasyuk
Дата: 27.09.12

BFE>например, параметры передать в тело лямбды, то начнутся эзотерические изыскания в дебрях макроса...

Какие параметры? Имхо, [&] вполне достаточно для scope_exit.