Suggestion: consider using C++20 `source_location` utilities

[SainoNamkho]

C++20 now has a standard way to get __PRETTY_FUNCTION__. This may ease the effort to work with compilers.

In addition, I found the hard coded offset has changed during the commits, reflecting changes of the implementations, would you mind documenting a brief naming rule among different versions of these implementations? And I've tested this approach without magic numbers, will it be an alternative?

[Neargye]

Do you know if this gives some kind of boost to compilation time?

[Epixu]

The provided approach had bad corner cases where it cropped names wrongly, if they ended up with similar characters, so I took the liberty to improve on the snippet.

When it comes to compile speed - it didn't seem to affect my reflection tests, but is definitely a huge improvement when it comes to future maintenance - compilers are many and they often change. Keeping track of the proper offsets will be a chore, it is much more elegant to automate it by using this handsome utility.

[Epixu]

~Did some more tinkering, trying to implement that mechanism on a working code base, and GCC/Clang gave me a lot of grief. Only Clang-Cl 16.0.6 reports bad function_name() output, while GNU 11.4.0 compiles, but segfaults at a consistent, but unexplicable place.~

~Smells like bad standard library implementation. Only latest MSVC seems to not cause any problems whatsoever. Unfortunately, I'm completely unable to reproduce this in godbolt for some reason...~

~So I'm definitely reverting my use of this, and it should be extensively tested, if anyone attempts it. Hopefully it's not just some ridiculous mistake on my behalf.~

EDIT: Nope, it's my mistake - turns out that under GCC/Clang, due to the way the text is formatted, it is possible to have a corner case, where left side of the string can also match the pattern i provided.

Here's that accounted for

Additionally, the same strategy can be applied with the conventional way its done up until now, just substitute source_location::current().function_name() with REFLECT_FUNCTION() as defined here:

/// Shamelessly stolen from boost and extended to my liking                   
/// Dumps the current function name                                           
#if defined(__GNUC__) or (defined(__MWERKS__) and (__MWERKS__ >= 0x3000)) or (defined(__ICC) and (__ICC >= 600)) or defined(__ghs__)
   #define REFLECT_FUNCTION() __PRETTY_FUNCTION__
#elif defined(__clang__)
   #define REFLECT_FUNCTION() __PRETTY_FUNCTION__
#elif defined(__DMC__) and (__DMC__ >= 0x810)
   #define REFLECT_FUNCTION() __PRETTY_FUNCTION__
#elif defined(__FUNCSIG__) or defined(_MSC_VER)
   #define REFLECT_FUNCTION() __FUNCSIG__
#elif (defined(__INTEL_COMPILER) and (__INTEL_COMPILER >= 600)) or (defined(__IBMCPP__) and (__IBMCPP__ >= 500))
   #define REFLECT_FUNCTION() __FUNCTION__
#elif defined(__BORLANDC__) and (__BORLANDC__ >= 0x550)
   #define REFLECT_FUNCTION() __FUNC__
#elif defined(__STDC_VERSION__) and (__STDC_VERSION__ >= 199901)
   #define REFLECT_FUNCTION() __func__
#elif defined(__cplusplus) and (__cplusplus >= 201103)
   #define REFLECT_FUNCTION() __func__
#else
   #error Not implemented
#endif

and voila, automatic indices

[frederick-vs-ja]

std::source_location::function_name is not a standard way to get __PRETTY_FUNCTION__. It is allowed, but not required, to give more information than __func__. Currently, only implementations guarantee ways to obtain detailed function signatures, and we should continue to use what the implementations guarantee.

I personally suggest to use std::source_location::current().function_name() as a fallback when neither __PRETTY_FUNCTION__ nor __FUNCSIG__ is usable. However, it's doubtful where there is, or will be, even one implementation where only these standand functions give guaranteed and wanted results.