Re: [boost] Nasty compile time reflection and iteration for POD types using C++14 without macro

Subject: Re: [boost] Nasty compile time reflection and iteration for POD types using C++14 without macro
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2016-03-25 12:35:23

2016-03-25 14:36 GMT+03:00 Klemens Morgenstern <klemens.morgenstern_at_[hidden]>
:

> I've tried to use __PRETTY_FUNCTION__ directly a year or two ago. Some
>> compilers allowed that, some not.
>>
>> Could you try to compile that code on Clang? If that works, try to mark
>> detail::ctti<T>::n() with constexpr and use in your code:
>>
>
> Clang 3.8 does compile with the example code.
>
>
>>      template<std::size_t Index>
>>      constexpr static char step()
>>      {
>>          return detail::ctti<T>::n()[Index];
>>      }
>>
>> If that works, then it would be a really great addition to type_index!
>>
>>
> That probably won't work. Constexpr [] on a const char* seems not to work,
> while "xyz"[1] works. That's why I use the __PRETTY_FUNC__ directly. Can be
> implemented that way though.

I've tired the following:

#include <boost/current_function.hpp>
#include <iostream>

template <class T>
struct ctti {
    static constexpr const char* n() noexcept {
        return BOOST_CURRENT_FUNCTION + 5;
    }
};

int main() {
    constexpr auto c = ctti<int>::n() + 10;
    std::cerr << c;
}

And that worked on GCC5.3 and Clang3.7.
Looks like it's time to continue the work on
https://github.com/apolukhin/type_index/tree/constexpr14 and make the
type_index constexpr :)

> That won't help. I need a way to make conversion of T type to some
>> non-templated class and back:
>> T -> int -> T
>>
>> TypeIndex allows only the first part of that: T -> type_index, but does
>> not
>> allow type_index -> T
>>
>
> Ah sure. Yeah then you can't get around some form of a macro. But maybe
> you could remove the index number, so adding a new class would work without
> that. That would allow me to add types at several places, because elsewise
> it might crash when different libraries do that. Though that would be a
> tweak later on.

Actually you do not need to add types. The code must work with any POD type
as member types are either
1) fundamental types (that are registered)
2) or PODs, then goto step 1) for that member

-- 
Best regards,
Antony Polukhin