Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile-time NameDecoder #4514

Open
hugtalbot opened this issue Feb 20, 2024 Discussed in #3179 · 1 comment
Open

Compile-time NameDecoder #4514

hugtalbot opened this issue Feb 20, 2024 Discussed in #3179 · 1 comment
Assignees
Labels
issue: discussion Open topic of discussion

Comments

@hugtalbot
Copy link
Contributor

Discussed in #3179

Originally posted by alxbilger July 27, 2022
NameDecoder has functions to get the name, template name, namespace etc as a string based on a type. Currently, functions are runtime.
Since types are known at compile-time, it would make sense that NameDecoder could be constexpr.
The problem is that C++ does not offer compile-time and portable features to do such a thing.

I found a solution on the web, but it is not portable:

It uses __PRETTY_FUNCTION__ (for clang and msvc) and __FUNCSIG__ for msvc.

Some problems with this solution:

  • Other compilers are not supported.
  • __FUNCSIG__ might not be defined depending on the compilation options.
  • __PRETTY_FUNCTION__ is not defined with old gcc

Open-source libraries I found (such as https://github.com/Manu343726/ctti or https://github.com/adambadura/type_name) also use the __PRETTY_FUNCTION__ solution.

I think it would not affect any of us if we start using this non-portable C++ since the modern compilers that we use support it. But, to be safe, I start the discussion if we go to this direction.

@hugtalbot hugtalbot added the issue: discussion Open topic of discussion label Feb 20, 2024
@damienmarchal
Copy link
Contributor

damienmarchal commented Apr 17, 2024

Personnally I'm wondering if using a string here instead of magical systems is not better because otherwise it means we are relying on undocumented feature in our UX (because NameDecoder are used to register object in the factory).

More fundamentally, exposing the implementation names through the UX is considered as as bad design and is very typical of application make by developpers that considere themselves as their first users... so they find themselves find super cool as a kind of "super print debuggin" as well as the ability to see "their" naming in the end user app.

When targetted users are not the developpers, it is considered much better to make a glossary of the term they use... shape the UX on top of that and use their term in the UX... while keeping implementation's names out of user's eyes .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
issue: discussion Open topic of discussion
Projects
None yet
Development

No branches or pull requests

3 participants