Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-24 16:06:15
On 22 Nov 2013 at 18:28, Gottlob Frege wrote:
> > There is something to be said for eliminating the name() function
> altogether ...
> Yes, first determine what types of name functions you want (mangled,
> demangled, compatible, unique, etc).
> Then supply ALL those functions.
Indeed, this is what I suggested to Antony off-list:
/*! Returns a static const char string of unknown format uniquely
identifying this type. The only guarantee is that this string will be
unique to the type within this process lifetime.*/
const char *unique_name() const noexcept;
/*! Returns a representation of this type suitable for printing.
This call may take some time as its storage may not be cached.*/
std::string pretty_name() const;
class enum mangling
Native, //!< Whatever the native mangling used by this toolset is
MSVC, //!< The Microsoft C++ mangling format
Itanium //!< The Itanium C++ mangling format
/*! Returns the mangled form of the string representation of the
After the calculation the value is cached statically such that the
function can be used to convert the returned string to a const char *
format identical to what may be returned by std::type_info::name()
raw_name() on MSVC). This function may throw an exception if it does
support mangled type string calculation, including when
const std::string &mangled_name(mangling=Native) const;
Note I have not convinced Antony of the merit of this approach (i.e.
of not providing a name() function at all, and leaving it up to user
code to subclass boost::type_index if so desired with something which
does implement some name() function locally to that specific
Thanks for the feedback Tony, and I hope things at our former
employer aren't too bad.
-- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/