[cfe-dev] Why is compiler support needed for std::underlying_type?

[Richard Smith]

On Mon, Oct 21, 2013 at 12:30 PM, Stephen Kelly <steveire at gmail.com> wrote:

> Richard Smith wrote:
>
> > enum E1 : long {};
> > static_assert(std::is_same<std::underlying_type<E>::type, long>::value,
> > ""); // ok
> > static_assert(std::is_same<UnderLyingType<E>::Type, long>::value, ""); //
> > fails
> >
> > enum E2 : char {};
> > static_assert(std::is_same<std::underlying_type<E>::type, char>::value,
> > ""); // ok
> > static_assert(std::is_same<UnderLyingType<E>::Type, char>::value, ""); //
> > fails
> >
>
> Am I right to say this? :
>
> Even if sizeof(long)==sizeof(long long), they are not the same type. The
> compiler intrinsic knows that, but my solution does not.
>
> Similarly, signed char, char and unsigned char are three different distinct
> types. The compiler knows this, but my solution does not.


Right. This doesn't prove the non-existence of a non-intrinsic approach,
though. You can probably get a lot closer by triggering integral promotion
for a value of the enumeration type and then looking at the type of that
value -- that should work for any unscoped enumeration type (whether or not
the underlying type is fixed).

For a scoped enumeration type, I think it is not possible to determine the
underlying type without compiler support, because no core language feature
exposes the type.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131021/e7b2cc79/attachment.html>