2013/11/13 Gavin Lambert
On 13/11/2013 08:34, Quoth Niall Douglas:
Boost community feedback is requested for the formal peer review of
the TypeIndex library by Antony Polukhin.
[...]
NOTE: Please read the TypeIndex documentation (linked to below)
before asking any questions e.g. about potential code bloat etc. You'll probably find the answer already there.
The docs for .name_demangled() indicate "Readable names may also differ between compilers: struct user_defined_type, user_defined_type."
Is it feasible to enforce some sort of compiler-independent uniformity on this (eg. guaranteeing that even if the native typeid output would insert "struct" or "class", name_demangled() would strip it off before returning it)? It would be good for code portability if users didn't have to worry about possibly externally stripping such things to produce "nice" output, or consistent output between compilers.
This is almost impossible: different compilers decorate names differently. This means that for each compiler we need to write parser/lexer that: * puts const, volatile, rvalue, reference at correct position (always after the type or always before) * strips away class, struct, __cdecl* * unifies template parameters representation * makes other unifications (array representations, wchar_t and __wchar_t unifications and so on...) This may be done some day and `name_portable()` method can be added. But I'm afraid this won't happen soon. I'm also not sure "name_demangled" is a good method name, as "name" being
mangled is a GCC implementation detail that is not true in MSVC, for example. I would prefer something more generic, such as "long_name" or "friendly_name", or like MSVC using "raw_name" in place of the current "name", and "name" in place of the current "name_demangled".
According to C++03 and C++11 Standard type_info::name() must return const char*. Getting readable name requires some work and an internal buffer inside boost::type_info. This looks like a bad solution (so "raw_name()" and "name()" won't fit). MSVC also mangles names, but hides that from user. So as for me, name_demangled() looks not bad. -- Best regards, Antony Polukhin