Автоматический сброс флага на выходе из функции (комментарии)

Автоматический сброс флага на выходе из функции (комментарии)

Это сообщение сгенерировано автоматически.

template<class T>
class AutoReset
{
  T& m_variable;
  T m_oldvalue;
public:
  AutoReset( T& var, const T& val ) : m_variable(var)
  {
    m_oldvalue = m_variable;
    m_variable = val;
  }

  ~AutoReset()
  {
    m_variable = m_oldvalue;
  }
}

по моему так более очевидно и удобно... ( потратил 7 минут, не проверял )

Ну и подсказки пошли...

Смысл? Писать одну строку в начале в место конца?

Ghost2
> Ну и подсказки пошли...
Ещё это посмотри :)

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

Я к тому, что использование автоматических переменных это как раз то, что можно было ожидать от подсказки. Но:
1. Об этих самых переменных тут ни слова.
2. Причем тут boost::shared_ptr?

1. они внутри щаред птр
2. поэтому он и юзается, работа перекладывается на него

>1. они внутри щаред птр
Видимо аудитория, на которую эти подсказки рассчитаны, должна до этого догадаться.

my.name
Это удобно в отдельных блоках, один раз объявил и забыл (типа while, for)...

Госпади, зачем boost?

void func()
{
  struct A
  { 
    A() {flag = true;}
    ~A() {flag = false;}
  } a;
...
}

hellokote
> Госпади, зачем boost?
затем киса, что наш соотечественник зафигачил scope_exit,
http://www.boost.org/doc/libs/1_40_0/libs/scope_exit/doc/html/index.html

велосипедостроителям пламенный привет.

За это можно стать участником? Может, меня тоже впишут?

    struct operation_t
    {
        operation_t(bool we = false)
        {
            assert(SSP::mutex0.IsLocked());
            
            asserts_idle();
            
            WE(we);
            CS(false);

[...]
            
            asserts_active();
        }
        
        ~operation_t(void)
        {
            asserts_active();
            
[...]
            
            CS(true);
            WE(false);

            asserts_idle();
        }
    };

Сейчас пришло в голову.
Красивые крит секции :)

class AutoScopedLock
{
protected:
  CRITICAL_SECTION* m_cs;

public:
  AutoScopedLock(CRITICAL_SECTION* cs)
    : m_cs(cs)
  {}
  ~AutoScopedLock()
  {
    LeaveCriticalSection(m_cs);
  }

  operator bool() const
  {
    EnterCriticalSection(m_cs);
    return true;
  }
};
#define ScopedLock(_cs_)    if( AutoScopedLock _scoped_lock = _cs_ )

// использование
ScopedLock(criticalSection)
{
   // тут делать операции под защитой крит секции
}

и раз уж тут if, то легко добавить Try.

class AutoScopedLock
{
protected:
  CRITICAL_SECTION* m_cs;
            bool m_acquired;

public:
  AutoScopedLock(CRITICAL_SECTION* cs)
    : m_cs(cs), m_acquired(false)
  {}
  ~AutoScopedLock()
  {
    if( m_acquired )
      LeaveCriticalSection(m_cs);
  }

  operator bool() const
  {
    return (m_acquired = (TryEnterCriticalSection(m_cs) != 0));
  }
};
#define TryScopedLock(_cs_)    if( AutoScopedLock _scoped_lock = _cs_ )

// использование
TryScopedLock(criticalSection)
{
   // смогли войти в крит секцию, делаем свои дела тут
}

хотя вариант с Try возможно стоит делать не TryScopedLock(criticalSection), а как нибудь типа if( TryLock(criticalSection) ) для наглядности.
где TryLock:
#define TryLock(_cs_) AutoScopedLock _scoped_lock = _cs_

gexogen
как бы это уже давно многие используют, например попкап...

Pushkoff
да нет, нигде такого не видел и в попкапе такого нет. Там есть AutoCrit, но разница в том, что его надо объявлять как переменную, внутри блока, а моя конструкция - больше похожа на блоки if\for\while или using(C#), логически более понятна и наглядна. Это не замена таким классам, как AutoCrit, а дополнение, ведь часто нужно ограничить не всю область внутри функции, а только маленький блок, в таких случаях она и пригодится.