Добрый день.
Надоело постоянно писать конструкции типа:

try
{
flag = true;
...
}
finally
{
flag = false;
}

Придумал такое:

       class A
        {
            private bool flag = false;

            private class FlagWrapper : IDisposable
            {
                private readonly A a;

                public FlagWrapper(A a)
                {
                    this.a = a;
                    a.flag = true;
                }


                public void Dispose()
                {
                    a.flag = false;
                }
            }

            private FlagWrapper Flag
            {
                get
                {
                    return new FlagWrapper(this);
                }
            }
...

}

Теперь:

                using (Flag)
                {
                    Debug.Assert(flag);
                }

                Debug.Assert(!flag);

По-моему гораздо симпатичней, но вот вопрос не будет ли это накладно для ресурсов постоянно
диспосабл объекты создавать, да и на взгляд других программистов может быть не очень
очевидное использование using..
Решил спросить совета.

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

N>По-моему гораздо симпатичней, но вот вопрос не будет ли это накладно для ресурсов постоянно
N>диспосабл объекты создавать,

Если сделать struct, то не должно быть накладно.

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

N>По-моему гораздо симпатичней, но вот вопрос не будет ли это накладно для ресурсов постоянно
N>диспосабл объекты создавать,

Не будет нисколько не накладно. Память в .NET выделяется последовательно и, =>, очень быстро. Объект используется внутри одного метода, поэтому по завершению метода при первой же сборке мусора (то есть при первой же необходимости) будет "собран".

N>да и на взгляд других программистов может быть не очень
N>очевидное использование using..

Имхо, очень правильное использование.

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

N>Надоело постоянно писать конструкции типа:
N>...
N>Придумал такое:
N>...
N>По-моему гораздо симпатичней

Ты собираешься для каждого флага писать такой враппер?

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

N>По-моему гораздо симпатичней, но вот вопрос не будет ли это накладно для ресурсов постоянно
N>диспосабл объекты создавать, да и на взгляд других программистов может быть не очень
N>очевидное использование using..

Попробуйте подойти к проблеме с другой стороны. Для эффективного рытья котлованов политика совершенствования лопаты может оказаться не дальновидной — экскаватор будет намного более эффективней.

Какая именно задача дешается? Отказаться от флагов "вообще" не пробовали?

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

_FR>Имхо, очень правильное использование.
А по-моему это не очень целевое использование:

• самое главное, шкурка выделки не стоит;
  
• есть вероятность снижения читаемости кода другим программистом.

Но если уж очень нравится, то... чем бы дитя не тешилось.

D>Ты собираешься для каждого флага писать такой враппер?

Он у меня один

TK>Попробуйте подойти к проблеме с другой стороны. Для эффективного рытья котлованов политика совершенствования лопаты может оказаться не дальновидной — экскаватор будет намного более эффективней.

TK>Какая именно задача дешается? Отказаться от флагов "вообще" не пробовали?

Без флагов оно конечно лучше. Пробовал — не получилось.

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

N>>По-моему гораздо симпатичней, но вот вопрос не будет ли это накладно для ресурсов постоянно
N>>диспосабл объекты создавать,

N>Если сделать struct, то не должно быть накладно.

Разве здесь не будет boxing-а?

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

TK>>Какая именно задача дешается? Отказаться от флагов "вообще" не пробовали?

А>Без флагов оно конечно лучше. Пробовал — не получилось.

продолжайте пробовать =)

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

N>>По-моему гораздо симпатичней, но вот вопрос не будет ли это накладно для ресурсов постоянно
N>>диспосабл объекты создавать, да и на взгляд других программистов может быть не очень
N>>очевидное использование using..

TK>Попробуйте подойти к проблеме с другой стороны. Для эффективного рытья котлованов политика совершенствования лопаты может оказаться не дальновидной — экскаватор будет намного более эффективней.

TK>Какая именно задача дешается? Отказаться от флагов "вообще" не пробовали?

"Для эффективного рытья" надо использовать настраиваемую лопату:

  public delegate void Action();
  
  public sealed class MethodDisposable : IDisposable
  {
    #region Fields

    private readonly Action action;

    #endregion Fields

    #region Constructors\Finalizer

    public MethodDisposable(Action action) {
      this.action = action;
    }

    #endregion Constructors\Finalizer

    #region Properties

    private Action Action {
      [DebuggerStepThrough]
      get { return action; }
    }

    #endregion Properties

    #region IDisposable Members

    public void Dispose() {
      if(Action != null) {
        Action();
      }//if
    }

    #endregion IDisposable Members
  }

  
  //…
  
  public IDisposable UsingFlag() {
    flaf = true;
    return new MethodDisposable(delegate { flag = false; });
  }

  //…
  
  using(UsingFlag()) {
    Debug.Assert(flag);
  }//using

  // или напрямую…
  using(new MethodDisposable(delegate { flag = false; })) {
    Debug.Assert(flag);
  }//using

Рассматриваемый случай так же применяется и в третьем фреймворке, например в BlockReentrancy()

Имхо, это очень хорошо, когда API [вместо|в дополнение к] void Begin…\void End… предоставляет метод, возвращающий IDisposable.

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

N>>Если сделать struct, то не должно быть накладно.

L>Разве здесь не будет boxing-а?

Нет.

15.13 The using statement
........
if ResourceType is a non-nullable value type or a type parameter with the value type
constraint (§25.7), the finally clause is expanded to the semantic equivalent of:

finally {
((System.IDisposable)resource).Dispose();
}

except that casting resource to System.IDisposable shall not cause boxing to occur.

При компиляции такой конструкции она превращается в

constrained S
callvirt instance void [mscorlib]System.IDisposable::Dispose()

, то есть в ту же инструкцию, которая возникает при вызове метода интерфейса у переменной, имеющий тип type parameter, который ограничен и констрейнтом struct и констрейнтом интерфейса (как известно, там boxing не возникает).

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

N>>>По-моему гораздо симпатичней, но вот вопрос не будет ли это накладно для ресурсов постоянно
N>>>диспосабл объекты создавать,

N>>Если сделать struct, то не должно быть накладно.

L>Разве здесь не будет boxing-а?

15.13 The using statement
…
The precise form of the finally block is determined as follows:

• If there is not an implicit conversion from ResourceType to the System.IDisposable interface,
  then a compile-time error is produced.
  
• Otherwise, if ResourceType is a non-nullable value type or a type parameter with the value type
  constraint (§25.7), the finally clause is expanded to the semantic equivalent of:
  

  finally {
    ((System.IDisposable)resource).Dispose();
  }

  
  except that casting resource to System.IDisposable shall not cause boxing to occur.
  
• Otherwise, the finally clause is expanded to:
  

  finally {
    if (resource != null) ((System.IDisposable)resource).Dispose();
  }

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

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

N>>>Если сделать struct, то не должно быть накладно.

L>>Разве здесь не будет boxing-а?

N>Нет.

Любопытно, что если под using запихнуть nullable value-type, underlying type которого реализует IDisposable, то boxing будет происходить.

всенепременно