Boost logo

Boost :

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-24 18:23:02


On 25/11/2013 10:06, Quoth Niall Douglas:
> 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
> type.
> After the calculation the value is cached statically such that the
> c_str()
> 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()
> (or
> raw_name() on MSVC). This function may throw an exception if it does
> not
> support mangled type string calculation, including when
> mangling=Native on
> some platforms.*/
>
> const std::string &mangled_name(mangling=Native) const;

Given that I'm still mostly using not-C++11 compilers I get a little
nervous when I see "class enum"s. Not that this is a reason to not do
it. :)

I'm not sure what the motivation for having the returned mangled type
configurable is though. Presumably most existing use cases would just
want Native, and the burden of providing alternates might be significant
(and therefore left unimplemented and throwing an exception, as
specified, limiting the potential usefulness of this anyway). Though as
I've said before I admit to ignorance about many of the use cases, so
maybe there is a need for this that I am unaware of.

Why not just specify a mangled_name that will return the native mangled
name if it can, but is allowed to return the same as unique_name? Or is
that too close to what unique_name itself will do?

(One use case I can imagine for a specified format is for
cross-compiler/machine serialisation, but OTOH I'm not sure how much I'd
want to trust using a mangled name for that anyway. Maybe I'm overly
paranoid though.)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk