Type to string conversion utilites

[pgeier]

Description

This PR provides utilities to convert arbitrary types to strings by calling typeToString<T>().
This utility is useful to create detailed error (and log) messages in templated code or to generate
a set of specialized error messages consistently.

A typical usecase is type dispatching with std::variant:

using Value = std::variant<bool, long, double, std::string>;

template<typename T>
T getValue(const Value& var) {
   if (std::holds_alternative<T>(var)) {
      return std::get<T>(var);   
   }
   std::ostringstream oss;
   oss << "Expected type " << typeToString<T>() << " but contained ";
   oss << std::visit([](const auto& v){ return typeToString<std::decay_t<decltype(v)>>(); }, var);
   throw std::runtime_error(oss.str());
};

Contributor Declaration

By opening this pull request, I affirm the following:

• All authors agree to the Contributor License Agreement.
• The code follows the project's coding standards.
• I have performed self-review and added comments where needed.
• I have added or updated tests to verify that my changes are effective and functional.
• I have run all existing tests and confirmed they pass.

[tbkr]

This looks good to me, as soon as the clang format is done.

[pgeier]

There is alread a demangle approach used: https://github.com/ecmwf/eckit/blob/develop/src/eckit/codec/detail/demangle.cc

If that approach is accepted to be safer, I'm fine with that. It just returns values like "i" for an "int" on some compilers.

EDIT: demangle is used with typeid(object).name()

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 65.83%. Comparing base (cf125e8) to head (1a66266).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #225      +/-   ##
===========================================
+ Coverage    65.80%   65.83%   +0.02%     
===========================================
  Files         1131     1133       +2     
  Lines        57598    57647      +49     
  Branches      4338     4338              
===========================================
+ Hits         37902    37951      +49     
  Misses       19696    19696              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[wdeconinck]

There is alread a demangle approach used: https://github.com/ecmwf/eckit/blob/develop/src/eckit/codec/detail/demangle.cc

If that approach is accepted to be safer, I'm fine with that. It just returns values like "i" for an "int" on some compilers.

Demangle is to make c++ mangled symbols human readable. It is used in the backtraces. That is definitely not your use case.

Perhaps you intend or could use typeid from c++
https://en.cppreference.com/w/cpp/language/typeid.html

[pgeier]

There is alread a demangle approach used: https://github.com/ecmwf/eckit/blob/develop/src/eckit/codec/detail/demangle.cc
If that approach is accepted to be safer, I'm fine with that. It just returns values like "i" for an "int" on some compilers.

Demangle is to make c++ mangled symbols human readable. It is used in the backtraces. That is definitely not your use case.

Perhaps you intend or could use typeid from c++ https://en.cppreference.com/w/cpp/language/typeid.html

typeid would be used together with demangle, otherwise the result is not readable.
typeid uses RTTI and always need to be called on an object demangle(typeid(x).name()).

These are basically the reason why the other approach is commonly more accepted - to get compile time strings.
With C++ I would also go further and make the TypeToString wrapper a constexpr.