Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2013-11-13 05:16:04

2013/11/13 Andrey Semashev <andrey.semashev_at_[hidden]>

> On Wed, Nov 13, 2013 at 2:02 PM, Antony Polukhin <antoshkka_at_[hidden]>
> wrote:
> > 2013/11/13 Andrey Semashev <andrey.semashev_at_[hidden]>
> >
> >> On Wed, Nov 13, 2013 at 1:28 PM, Antony Polukhin <antoshkka_at_[hidden]>
> >> wrote:
> >> > 2013/11/13 Gavin Lambert <gavinl_at_[hidden]>
> >> >
> >> >> Or how about:
> >> >>   * const char *name() : returns whatever std::type_info::name does
> [if
> >> >> RTTI]
> >> >>   * std::string short_name() : returns the raw/mangled name
> >> >>   * std::string long_name() : returns the long/demangled name
> >> >>
> >> >> Or flip the components (name_short and name_long) if you prefer; it
> >> sorts
> >> >> better but reads worse that way, I think.
> >> >>
> >> >> (With RTTI disabled, all three would probably return the same value.)
> >> >>
> >> >
> >> > This is a good idea, thanks! Using it less user code will be broken.
> >> >
> >> > Do you like the following names:
> >> > * const char* name() // minor behavior change on MSVC
> >> > * const char* name_mangled() // this method must be added
> >> > * std::string name_demangled() // remains exactly the same
> >>
> >> I haven't had the chance to review the library (yet), but I second
> >> that boost::type_info::name() should be equivalent to
> >> std::type_info::name(), including MSVC.
> >>
> >> All special logic of demangling should be implemented in a new
> >> function, like name_demangled (and let me suggest a few other names
> >> for it - readable_name(), pretty_name()).
> >>
> >> name_mangled() is controversial because formally you have no
> >> guaranteed way to acquire a mangled name of the type. Some compilers
> >> provide it, others don't. I assume, you don't want to implement
> >> mangling algorithms for these compilers, so I'm in favor of removing
> >> this function or at least changing its semantics and name to something
> >> less obligatory, like raw_name() or underlying_name().
> >>
> >
> > Agreed.
> >
> > People may use auto-fill in IDE a lot (I do), so maybe starting methods
> > from name_* is more auto-fill friendly:
> >
> > * const char* name() // same as std::type_info::name()
> > * const char* name_raw() //
> > * std::string name_pretty() // was name_demangled()
> >
> > In this way you just type name_ and see all the available name methods.
>
> IMHO, it's better when the names differ from the beginning, so you
> don't have to select the variant in the combo-box. It's enough to just
> press 'n', 'r' or 'p' to get the required function first in the list.
> Also, some IDE's allow to select auto-completion choices based on
> substrings in any part of the function name, not just the beginning.
>
> In any case, I think a clear name is more important than trying to
> make it work nicely in a particular IDE. There are many IDEs, of
> varying qualities and levels of sophistication, and in the end the
> only thing that matters is the code.
>

Then it will be:

* const char* name() // same as std::type_info::name()
* const char* raw_name() // mangled/short/not very readable name
* std::string pretty_name() // was name_demangled()

-- 
Best regards,
Antony Polukhin