Существует ли стандартный класс С++ для установки переменной в значение при выходе из области видимости

Пока нет (были предложения по этому поводу). Но реализовать общий достаточно просто;

struct scope_exit {
  std::function<void()> f_;
  explicit scope_exit(std::function<void()> f) noexcept : f_(std::move(f)) {}
  ~scope_exit() { if (f_) f_(); }
};
// ...
m_theVariableToChange = true;
scope_exit resetFalse([&m_theVariableToChange]() { m_theVariableToChange = false; });

Для простоты выше я отредактировал конструкторы копирования и перемещения и т. д....

Отметив их как = delete, вы сделаете приведенное выше минимальное решение. Дальше; при желании перемещение может быть разрешено, но копирование должно быть запрещено.

Более полный scope_exit будет выглядеть так (онлайн-демонстрация здесь);

template <typename F>
struct scope_exit {
  F f_;
  bool run_;
  explicit scope_exit(F f) noexcept : f_(std::move(f)), run_(true) {}
  scope_exit(scope_exit&& rhs) noexcept : f_((rhs.run_ = false, std::move(rhs.f_))), run_(true) {}
  ~scope_exit()
  {
    if (run_)
      f_(); // RAII semantics apply, expected not to throw
  }

  // "in place" construction expected, no default ctor provided either
  // also unclear what should be done with the old functor, should it
  // be called since it is no longer needed, or not since *this is not
  // going out of scope just yet...
  scope_exit& operator=(scope_exit&& rhs) = delete;
  // to be explicit...
  scope_exit(scope_exit const&) = delete;
  scope_exit& operator=(scope_exit const&) = delete;
};

template <typename F>
scope_exit<F> make_scope_exit(F&& f) noexcept
{
  return scope_exit<F>{ std::forward<F>(f) };
}

Примечания по реализации;

• std::function<void()> можно использовать для стирания типа функтора. std::function<void()> предлагает гарантии исключений для конструкторов перемещения на основе исключений, специфичных для удерживаемой функции. Пример этой реализации находится здесь
• Эти спецификации исключений согласуются с предложением C++ и реализациями GSL.
• Я отредактировал большую часть мотивации для noexcept, более существенные подробности можно найти в Предложение C++
• «Обычная» семантика RAII деструктора, следовательно, применима функция «выход из области действия»; это не будет throw, это также согласуется со спецификацией C++11 по спецификации исключения по умолчанию для деструктора. См. cppreference, SO Q&A, GotW#47 и HIC++

• Предложение C++, упомянутое выше, и его редакция (на момент написания этой статьи)
• Boost.ScopeExit
• Реализация Microsoft GSL

Вы можете «оскорбить» shared_ptr за это:

m_theVariableToChange = true;
std::shared_ptr<void> resetFalse(nullptr, [&](void*){ m_theVariableToChange = false; });

Если есть опасения по поводу использования void в качестве параметра шаблона T, я нашел следующее в стандарте C++:

20.8.2.2§2:

... Параметр шаблона T для shared_ptr может быть неполным типом.

Это указывает на то, что T используется только как указатель, поэтому использование void должно подойти.

Стандартной версии этого нет.

Библиотека поддержки CppGoreGuidelines (GSL) имеет обобщенную версию, которая называется наконец-то, но эта библиотека еще не доведена до производственного качества. Это определенно рекомендуемая практика.

E.19: используйте объект final_action для экспресс-очистки, если нет подходящего дескриптора ресурса.

Причина

finally менее многословен и в нем труднее ошибиться, чем try/catch.

Пример

void f(int n)
{
    void* p = malloc(1, n);
    auto _ = finally([p] { free(p); });
    // ...
}

Примечание

finally не такой беспорядочный, как try/catch, но он все еще случайный. Предпочитайте правильные объекты управления ресурсами.

Аналогичный вопрос: самый простой и аккуратный С++ 11 ScopeGuard

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

Например, решение из этого ответа для вашего кода будет таким:

scope_guard guard1 = [&]{ m_theVariableToChange = false; };

В другом ответе в этой теме отмечается, что аналогичная концепция была предложена для стандартизации С++ 17; а также представлено решение C++03.