Why must an enumeration’s size be provided when it is forward declared?

by

This has been standardized, proposal 2764: Forward declaration of enumerations (rev. 3) allowed the forward declaration of enums if you specify the underlying type, whereas before this was not possible.

The main reason is that when the underlying type is not specified the size is implementation defined and can depend on the enumerator values. From the draft C++11 standard section 7.2 [dcl.enum]:

For an enumeration whose underlying type is not fixed, the underlying
type is an integral type that can represent all the enumerator values
defined in the enumeration. If no integral type can represent all the
enumerator values, the enumeration is ill-formed. It is
implementation-defined which integral type is used as the underlying
type except that the underlying type shall not be larger than int
unless the value of an enumerator cannot fit in an int or unsigned
int. If the enumerator-list is empty, the underlying type is as if the
enumeration had a single enumerator with value 0.

When passing by value it makes sense that not knowing the underlying type is an issue, but why is it an issue when it is a pointer or reference? This matters since apparently on some architectures, char* and int* can have different sizes as mentioned in this comp.lang.c++ discussion: GCC and forward declaration of enum:

[…] While on most architectures it may not be an issue, on some
architectures the pointer will have a different size, in case it is a
char pointer. So finally our imaginary compiler would have no idea
what to put there to get a ColorsEnum*[…]

We have the following stackoverflow answer for reference which describes the case where char* can be larger than int*, which backs up the assertion in the discussion above.

Some more details on the possible sizes of pointers it looks like char * and void * are the two main exceptions here and so other object pointers should not have the same issues. So it seems like this case ends up being unique to enums.

More Related Contents:

  1. Allow for Range-Based For with enum classes?
  2. Is it possible to determine if a type is a scoped enumeration type?
  3. How can I output the value of an enum class in C++11
  4. How to use C++11 enum class for flags
  5. Enum vs Strongly typed enum
  6. Equivalent of “using namespace X” for scoped enumerations?
  7. “unpacking” a tuple to call a matching function pointer
  8. Does C++11 allow vector?
  9. shared_ptr to an array : should it be used?
  10. When does a constexpr function get evaluated at compile time?
  11. Compiling C++11 with g++
  12. How much is too much with C++11 auto keyword?
  13. Why do I get the same sequence for every run with std::random_device with mingw gcc4.8.1?
  14. Why do C++11-deleted functions participate in overload resolution?
  15. What does std::match_results::size return?
  16. Disambiguate class-member in multiple inheritance
  17. Where is the lock for a std::atomic?
  18. Difference between C++03 throw() specifier C++11 noexcept
  19. Why do some people use swap for move assignments?
  20. Default, value and zero initialization mess
  21. Debugging template instantiations
  22. So can unique_ptr be used safely in stl collections?
  23. How Does std::enable_if work?
  24. decltype as a return type in class member function
  25. Move or Named Return Value Optimization (NRVO)?
  26. Vary range of uniform_int_distribution
  27. forward declaration with vector of class type – pointer to incomplete class type not allowed
  28. Default Move Constructor in Visual Studio 2013 (Update 3)
  29. unique_ptr and OpenSSL’s STACK_OF(X509)*
  30. Is it safe to reinterpret_cast an enum class variable to a reference of the underlying type?

Leave a Comment