Optionals and variants

In [1], there is boost::optional (it will likely be included in C++17) which maybe holds an value.

The class boost::variant is kind of an union of a tuple which holds one value of a list of different types. [2]

What we will implement here to hold nothing, errors or values is a small version of a mixture of both.

In pseudocode it would look like this

template< typename... types_t >
class variant
{
    // Number of which type is currently stored.
    uint8_t _what;

    // Data area where we store the data.
    uint8_t* _storage;

public:

    // Return the type.
    uint8_t what();

    // Get the value.
    template<int n>
    get_n<n, types_t...>::type get_value();

    // Initialize empty.
    variant();

    // Initialize with value.
    template<int n>
    variant( get_n<n, types_t...>::type value );
};

we define our states as

// Alias for the first three values.
enum {
    e_nothing = 0;
    e_value = 1;
    e_error = 2;
};

Our three state variant would consist of the types void for nothing, char for the value, int for the error.

The usage in the make_...-functions would be

variant<void,char,int>::variant<0> v_nothing();
variant<void,char,int>::variant<1> v_value( the_value );
variant<void,char,int>::variant<2> v_error( the_error );

except in current C++ it is not possible to call the constructor directly with an template argument. We'll ignore that fact for now and use a workaround [3].

In order to implement a new class optional_variant we have the following options

• reimplement variant,
• inherit from variant,
• use a variant instance as a member.

The third option seems the smallest and most flexible on a microcontroller as it avoids inheritance and code duplication.

The optional_variant is defined as

template< class value_t, typename... rest_t >
class optional_variant
{
    variant< void, value_t, rest_t... > _v;

public:
    // Return the type.
    uint8_t what() {
        return _v.what();
    }

    // Return the value.
    value_t get_value() {
        return _v.get_value<1>();
    }

    // Return the error.
    get_n<2, types_t...>::type get_value() {
        return _v.get_value<2>();
    }


    // Get the value.
    template<int n>
    get_n<n, types_t...>::type get_value();

    // Initialize empty.
    optional_variant()
        : _v()
    {}

    // Initialize with value.
    optional_variant( value_t value )
        : _v<n>( value )
    {}

    // Initialize with status and value.
    template<int n>
    optional_variant( get_n<n, types_t...>::type value )
        : _v<n>( value )
    {}
};

. The template parameter value_t is always necessary while the parameter pack rest_t... can be empty. This means the error parameter is optional.

The member variant _v has void added as first template parameter.

The optional_variant can be used as

optional_variant<char> just_optional();

without error value and with error value as

optional_variant<char, int> error_optional();

.

One difference from most implementations of variant is that in our case a variant is identified by the number instead of the type.

Usually the data could be retrieved by a method like

template<typename... types_t>
class type_variant {
...
    template< class T >
    T get_value_as();
...
};

which specializes the by the data type.

This is not a suitable implementation for us since the value type and the error type could be identical.

Due to the definition by number

optional_variant<int, int> error_optional();

is also valid and a call to error_optional.what() gives the corresponding number which can be used to distinguish between the first int (value) and the second :code`int` (error).

Library and Examples

While the above pseudo-code is useful to illustrate, it won't compile due to some subtleties of the C++ language.

The library i wrote, therefore uses a slightly different implementation.

You can download the library here.

Chapter conclusion

Optionals and variants are a versatile data structure for error handling and can be implemente efficiently in microcontrollers.