Там даже есть про макросы, EBFN и PEG немного.

http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Successful-Features-of-D

Оператор scope интересный. Может реализовать такой?

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

C>Оператор scope интересный. Может реализовать такой?

Смотреть мултики не охота. Есть ссылка на описание?

int x = 0;

{
int x = 1;
println(x); // 1
println(.x); // 0
// . — это оператор scope
}

Здравствуйте, Аноним, Вы писали:

А>int x = 0;

А>{
А> int x = 1;
А> println(x); // 1
А> println(.x); // 0
А> // . — это оператор scope
А>}

гениально! всегда было смутное ощущение, что чего-то в языках не хватает. и вот оно!

Здравствуйте, Аноним, Вы писали:

А>int x = 0;

А>{
А> int x = 1;
А> println(x); // 1
А> println(.x); // 0
А> // . — это оператор scope
А>}

А оно реально нужно? Ввел себе переменную и нет проблем.

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

Здравствуйте, Аноним, Вы писали:

А>int x = 0;

А>{
А> int x = 1;
А> println(x); // 1
А> println(.x); // 0
А> // . — это оператор scope
А>}

Нет. Смотри мультик.

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

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

C>>Оператор scope интересный. Может реализовать такой?

VD>Смотреть мултики не охота. Есть ссылка на описание?

Есть pdf слайдов: http://ecn.channel9.msdn.com/events/LangNEXT2012/AndreiLangNext.pdf

Если коротко, то спикер утвеждает, что try-catch-finally плохо работают (их сложно писать и читать), когда вложены один в другой. В D создали оператор scope, который не добавляет дополнительной вложенности. Как-то так.

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

C>Если коротко, то спикер утвеждает, что try-catch-finally плохо работают (их сложно писать и читать), когда вложены один в другой. В D создали оператор scope, который не добавляет дополнительной вложенности. Как-то так.

А зачем их писать в больших количествах, да еще и вложенными? Сдается мне они там фигней занимаются.

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

C>Нет. Смотри мультик.
Искал в гугле по "language d", "scope operator"

Посмотрел мультик.
С чем-то подобным, вроде, боролся Александреску, вводя ScopeGuard'ы на ресурсы.

void User::AddFriend(User& newFriend)
{
    friends_.push_back(&newFriend);
    ScopeGuard guard = MakeObjGuard(friends_, &UserCont::pop_back);
    pDB_->AddFriend(GetName(), newFriend.GetName());
    guard.Dismiss();
}

Откровенно говоря, его пример про С++ я не понял.

Вот он сообщает нам:

RAII1 raii1;
try
{
    RAII2 raii2;
    try
    {
        next2();
    }
    catch(...)
    {
        rollback2();
        throw;
    }
}
catch (...)
{
    rollback1();
    throw;
}

Какое действие будет откатывать rollback1? Для next2 уже есть rollback2, а raii1 и raii2 сами с усами.

По-моему, его пример хуже не станет, если внешний try/catch убрать:

RAII1 raii1;

RAII2 raii2;
try
{
    next2();
}
catch(...)
{
    rollback2();
    throw;
}

Но и даже здесь try/catch не нужен

RAII1 raii1;

RAII2 raii2;

NEXT2 next2;
next2.act();
next2.commit();

Можно и больше next-ов наколбасить без всякой вложенности:

RAII1 raii1;

RAII2 raii2;

NEXT2 next2;
NEXT3 next3;
NEXT4 next4;

next2.act();
next3.act();
next4.act();

next2.commit();
next3.commit();
next4.commit();

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

C>Если коротко, то спикер утвеждает, что try-catch-finally плохо работают (их сложно писать и читать), когда вложены один в другой. В D создали оператор scope, который не добавляет дополнительной вложенности. Как-то так.

в с++ finally нет, там для этого деструкторы
в c# я не так давно сделал тоже самое, но в Dispose() (тут надо признаться нет такой надёжности, но и место там не такое важное, да и использую я это строго)
в немерле мне кажется было бы удобнее решать эту проблему так

Автор: para
Дата: 28.09.09

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

MX>Какое действие будет откатывать rollback1? Для next2 уже есть rollback2, а raii1 и raii2 сами с усами.

Подразумевается что в первом блоке try-catch будет что-то делаться с raii1. И если случится какая-то пакость, то нужно откатить изменения.

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

C>Подразумевается что в первом блоке try-catch будет что-то делаться с raii1. И если случится какая-то пакость, то нужно откатить изменения.

Возможно. Но я по-прежнему не вижу, зачем городить все эти вложенные try/catch, когда для отката пакостей есть деструкторы.

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

C>Если коротко, то спикер утвеждает, что try-catch-finally плохо работают (их сложно писать и читать), когда вложены один в другой. В D создали оператор scope, который не добавляет дополнительной вложенности. Как-то так.

Там суть не столько в try-catch-finally а в том что рассматривается ситуация когда кроме операции очистки (clean) есть
операция отката (rollback). Когда отката нет то RAII из C++ (да и в D он доступен) выглядит красиво и чисто, с откатом
же приходится городить try-catch-finally.

D'шный же scope все позволяет делать красиво:

scope(exit){
    writeln("exit: срабатывает всегда на выходе");
    }
    
scope(success){
    writeln("success: срабатывает если не было исключений");
    }
    
scope(failure){
    writeln("success: срабатывает в случае исключений");
    }

http://dlang.org/statement.html#ScopeGuardStatement

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


MX>Возможно. Но я по-прежнему не вижу, зачем городить все эти вложенные try/catch, когда для отката пакостей есть деструкторы.

В деструкторах нормальная очистка, try/catch для отката в случае неуспеха.

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

FR>Там суть не столько в try-catch-finally а в том что рассматривается ситуация когда кроме операции очистки (clean) есть
FR>операция отката (rollback). Когда отката нет то RAII из C++ (да и в D он доступен) выглядит красиво и чисто, с откатом
FR>же приходится городить try-catch-finally.

Как-то не встречал такой проблемы. Чем откат вдруг стал отличаться от другой очистки ресурсов?

В том же шарпе отлично работает стратегия:

using (var connection = DbManager.GetConnection())
{
  ... // делаем что хотим...

  if (что-то_не_так)
  {
    connection.Rollback();
    return;
  }

  connection.Commit();
} // по любому исключению - Rollback

Никаких try-на при этом вообще заводить не приходится.

Где проблема то?

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

VD>Как-то не встречал такой проблемы. Чем откат вдруг стал отличаться от другой очистки ресурсов?

Часто ничем.
Но бывает что нужен кроме очистки и откат, который срабатывает только при ошибке.

VD>В том же шарпе отлично работает стратегия:
...
VD>Никаких try-на при этом вообще заводить не приходится.

Эта стратегия прекрасно работает, и не только в шарпе, только если обработка ошибок построена
на кодах возврата, если же она основывается на исключениях то будет как и продемонстрировал
Александреску вложенные try.

VD>Где проблема то?

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

Но даже без этой проблемы тот же scope по моему гораздо удобнее try ... finally или
одноразовых RAII оберток.

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

FR>Часто ничем.
FR>Но бывает что нужен кроме очистки и откат, который срабатывает только при ошибке.

Дык, может в этом и дело? Почему только при ошибке? Откат должен быть всегда, если не было комита. И все! Проблем больше нет.

FR>Эта стратегия прекрасно работает, и не только в шарпе, только если обработка ошибок построена
FR>на кодах возврата, если же она основывается на исключениях то будет как и продемонстрировал
FR>Александреску вложенные try.

Мне плевать на тараканов в голове у Александреску. Описанная мной стратегия прекрасно работает в любом случае. Исключения ничем не мешают ей.

VD>>Где проблема то?

FR>Проблема возникает если используешь исключения.

Не возникает.

Давай без заявлений. Покажи проблему. Я пока что ее в упор не вижу.

FR>Но даже без этой проблемы тот же scope по моему гораздо удобнее try ... finally или
FR>одноразовых RAII оберток.

Я использую try finally в чистом виде раз в год по чайной ложке. Что толку от улучшения этой чайной ложки?

Потом, чем лучше?

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

FR>Но даже без этой проблемы тот же scope по моему гораздо удобнее try ... finally или
FR>одноразовых RAII оберток.
Да ладно.
Просто нужно к построению логики подходить с другой стороны.
Нужно вызывать в коде не rollback, а commit. Вызов rollback произойдет при откате, если не было commit.
И сразу вся вложенность пропадает.

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


FR>>Проблема возникает если используешь исключения.

VD>Не возникает.

using (var connection = DbManager.GetConnection())
{
  ... // делаем что хотим...
  
  // тут вылетело исключение, откат обязателен, как ловим без try?
 
  if (что-то_не_так)
  {
    connection.Rollback();
    return;
  }

  connection.Commit();
} // по любому исключению - Rollback

VD>Давай без заявлений. Покажи проблему. Я пока что ее в упор не вижу.

В пдфке и выше в коде проиллюстрировано.

FR>>Но даже без этой проблемы тот же scope по моему гораздо удобнее try ... finally или
FR>>одноразовых RAII оберток.

VD>Я использую try finally в чистом виде раз в год по чайной ложке. Что толку от улучшения этой чайной ложки?

Я кстати тоже так стараюсь, но писатели библиотек часто думают по другому

VD>Потом, чем лучше?

Для меня очень удобным оказался банальный scope(exit)