Home / Questions / 136504
Accepted
Trauma
Asked: 2020-02-07 01:44:54 +0800 CST 2020-02-07 01:44:54 +0800 CST

Correct RAII handling in C++

  • 772

RAII ( resource acquisition is initialization ) is a common language in C++; I recently had a small problem using it, which I summarize in this code (the code is not valid, it is for illustrative purposes only ):

template< typename T > class Algo {
  bool enqueue( T arg ) {
    struct raii {
      T val;
      ~raii( ) {
        // Hacemos algo con las variables ...
      }
    } RAII = { arg };

    // Cuerpo real de la función ...
  }

  // Resto de la plantilla ...
};

Inside the function enqueue( )we create a control structure; its only mission is to guarantee that a part of our code will be executed, even in the presence of exceptions . The C++ language guarantees that the destructor will be called . It is the equivalent in C++ to the blocks finally { ... }present in other languages.

The problem I've run into is that the compiler, in an effort to keep us out of trouble, gives us an unused variable warning :

warning: unused RAII variable

In modern compilers , we can use the new features of C++11; specifically, the attributes ; more exactly, in C++17 we can use

} RAII [[maybe_unused]] = { arg };

In g++, we can use __attribute((unused))__or [[gnu::unused]](depending on the version). And it even sounds like something to me pragma _Unusedin other compilers.

Other, more manual methods consist of declaring and using a constructor; this way, the compiler sees that we 're using the instance, and doesn't give us its well-intentioned warning either.

The question:

Doesn't C++ provide a standard, agreed mechanism for using RAII? That is, to inform the compiler that the only use of an instance is to call its destructor.

c++

2 Answers

  1. Best Answer

    Just do a conversion to void:

    template< typename T > class Algo {
  bool enqueue( T arg ) {
    struct raii {
      T val;
      ~raii( ) {
        // Hacemos algo con las variables ...
      }
    } RAII = { arg };
    static_cast<void>(RAII);

    // Cuerpo real de la función ...
  }

  // Resto de la plantilla ...

};

    The effect on the generated code is nil, since the compiler sees that you don't fetch the result and won't generate a single additional statement.

    Another possibility... since in this case Tit has to be a pointer (otherwise the destructor of the resource would be called automatically), is to replace that structure with a unique_ptr:

    template< typename T > class Algo {
  bool enqueue( T arg ) {
    std::unique_ptr<typename std::remove_pointer<T>::type> raii(arg);

    // Cuerpo real de la función ...
  }

  // Resto de la plantilla ...

};

    And you can even complete the matter a bit more if we add a destructor prepared for the occasion:

    #include <iostream>
#include <memory>
#include <type_traits>

template<class T>
void func(T arg)
{
  using ObjectType = typename std::remove_pointer<T>::type;

  auto deleter = [](T ptr){ std::cout << "operaciones de limpieza\n"; delete ptr; };

  std::unique_ptr<ObjectType,decltype(deleter)> ptr(arg, deleter);
}

struct test
{
  ~test()
  { std::cout << "destructor\n"; }
};

int main()
{
  test* t = new test;
  func(t);
}
    • 3

  2. Doesn't C++ provide a standard, agreed mechanism for using RAII?

    I present to you the technical document p0052r6 under study for its inclusion in C++20 (my translation).

    Generic Scope Guards and RAII Wrapper for the Standard Library

    Peter Sommerlad and Andrew L. Sandoval with contributions by Eric Niebler and Daniel Krügler

    2017-11-21

    ...

    6.1 General Principles

    The following general principles have been formulated for unique_resourceand are valid for scope_exit.

    • Transparency: It should be obvious at a glance what each unique_resource. By binding the resource to its deletion routine, the declaration unique_resourcemakes its intent clear.
    • Resource Conservation and Life Cycle Management: unique_resourceenables "set it and forget it" in the sense that the release always happens after it unique_resourcehas been initialized.
    • Security vs. Exceptions: Exception unwinding is one of the main reasons why unique_resourceand scope_exit/ scope_failare necessary. Thus, the specification requires a strict guarantee against exceptions when creating or moving defined types, ensuring the call to the delete or exit function.
    • Flexibility: It unique_respircehas been designed to be flexible, allowing the use of existing lambdas or functions to free up resources.

    About...

    That is, to inform the compiler that the only use of an instance is to call its destructor.

    That has never been RAII's goal. The non-use of variables alarm appears for your RAII object circumstantially, not because it is RAII.

    You can prevent that alarm from appearing by configuring the compiler to ignore that specific alarm, but I don't advise it. Another option would be to use compiler or language specific tools to mark the object as unused (option you are already familiar with). And if all that fails, you can do the conversion (void)as eferion suggests but to denote intentionality you should use a macro:

    #define UNUSED(x) (void)x;

    I personally prefer to use a function, which has the same effect:

    template <typename T>
void UNUSED(T){}

    Being a template function, it will accept any type and being the received parameter anonymous, it will not complain about the lack of use of the parameter.

    • 3