template<class T>
Corrade::Utility::TweakableParser struct

Parser for Tweakable types.

Support for basic types that are expressible with plain literals is implemented in TweakableParser<int>, TweakableParser<unsigned int>, TweakableParser<long>, TweakableParser<unsigned long>, TweakableParser<long long>, TweakableParser<unsigned long long>, TweakableParser<float>, TweakableParser<double>, TweakableParser<long double> and TweakableParser<char>.

Implementing support for custom literals

The parser support is limited to what's expressible with C++11 user-defined literals, together with an optional unary + or - in front. Current implementation supports only trivially copyable and trivially destructible types of a limited size — in particular, saving strings is not possible.

In order to implement support for a custom type, create a (partial) template specialization with a parse() function with the following sigature for given type T — assuming there's a user-defined C++11 literal that returns T as well:

namespace Corrade { namespace Utility { // namespace is important

template<> struct TweakableParser<T> {
    static std::pair<TweakableState, T> parse(Containers::ArrayView<const char> value);
};

}}

The function gets a view onto the contents of the annotation, with outer whitespace stripped (so e.g. for string literals you get also the quotes around). It returns the parsed value and a parser state. The state should be one of the following:

  • TweakableState::Success if parsing consumed the whole input and there was no error
  • TweakableState::Error if parsing failed and the parser is sure that this is a compile error (and not suddenly a different type, for example — 0xa901g0f might look like an error, but it could be also a user-defined literal g0f). Examples of such errors can be unterminated string/char literals or unknown escape characters in them.
  • TweakableState::Recompile if parsing failed and the parser is not sure that this is a compile error

Returning TweakableState::NoChange is not allowed.

Note that the user-defined literal has to return a custom type that's not already handled by the implementation. So for example a custom C++11 binary literal 110110110_b, returning int and supplementing the builtin C++14 literal 0b110110110, wouldn't be possible to implement, since TweakableParser<int> is already defined.