in which situations anonymous enum should be used? - c++

In both c and c++ enum could be defined with tag
enum e_smth {
smth_one,
smth_two,
smth_err
};
or without tag
enum {
smth_one,
smth_two,
smth_err
};
If it was defined with tag it makes sense in switch statements in both c and c++ :
e_smth some_var;
....//do some stuff with some_var
switch (some_var)
{
case smth_one:
break;
case smth_two:
break;
}
will produce -Wswitch warning if this will be compiled with gcc or g++.
It makes sense in functions declarations and variables initialization in c++ :
e_smth var;
var=99;
Will produce -fpermissive error if compiled with g++.
Both types with or without tag could be used as one file #define macro without parameters.
update
could be used as one file #define macro without parameters
meant : Instead of writing #define MAX 1000 in file and adding MAX to global use enum { MAX=1000 } just in file scope
And what about anonymous enums, I've found just one use cases:
definition like typedef enum { a,b,c } some_t; makes it work like enum with tag
Question:
if I haven't yet described all reasonable use cases, what for anonymous enums should be used?

In C (but not in C++), enum can be [ab]used to define int constants.
For example, given this declaration:
const int MAX = 1024;
MAX is not a constant expression, it's the name of a read-only object. That means you can't use it in a case label, as the size of an array declared at file scope or with static, or in any other context requiring a constant expression.
But if you write:
enum { MAX = 1024 };
then MAX is a constant expression of type int, usable in any context where you could use the constant 1024.
Of course you could also write:
#define MAX 1024
but there are disadvantages to using the preprocessor: the identifier isn't scoped the way it would be given an ordinary declaration, for example.
The drawback is that such a constant can only be of type int.
C++ has different rules; enumeration constants are of the enumerated type, not int, but you can use declared constant objects as constant expressions (as long as the initializer is a constant expression).
To address the original question, when you use an enum declaration to create constants like this, there's no point in having either a tag or a typedef, since you'll never use the type itself.
Background: This:
enum foo { zero, one, two };
enum foo obj = two;
creates a type enum foo and constants zero, one, and two. In C, the constants are always of type int, which is admittedly odd, and the initialization of obj involves an implicit conversion from int to enum foo.
In C++, the type enum foo can also be referred to as just foo, and the constants are of type enum foo (which is compatible with some integer type, not necessarily int).

Another use case is as an element of a struct or union, typically when it doesn't make sense to use it by itself (because it's there solely to satisfy the ABI of a communication protocol or etc. and there is a more appropriate representation for programmatic use).

#eith Thompson
Your answer has the statement that "const int MAX = 1024;
MAX is not a constant expression,".
However, the example from the link http://en.cppreference.com/w/cpp/language/constant_expression
shows that it's a constant expression and can be used in a array declaration.
Constant expressions
C++ C++ language Expressions
Defines an expression that can be evaluated at compile time.
Such expressions can be used as non-type template arguments, array sizes, and in other contexts that require constant expressions, e.g.
int n = 1;
std::array<int, n> a1; // error, n is not a constant expression
const int cn = 2;
std::array<int, cn> a2; // OK, cn is a constant expression

Usually, you only need to name an enum when you use it more than once. In other words, if you define multiple variables using the same enum, then you need to name the enum. However, if you only use the enum once and there will only ever be one variable having that enum, then an anonymous enum makes sense. For example:
enum color { red, blue, gray, green };
enum color car_color;
enum color house_color;
Here there are multiple variables, so the enum is named.
typedef struct {
int year;
enum { Jan, Feb, Mar, Apr, May, Jun, July, Aug, Sep, Oct, Nov, Dec } month;
unsigned int day;
} date;
Here the author plans to only use the enum once, so a name is unnecessary.

Related

Why does C++ allow forward declaration of class but not enums? [duplicate]

I'm trying to do something like the following:
enum E;
void Foo(E e);
enum E {A, B, C};
which the compiler rejects. I've had a quick look on Google and the consensus seems to be "you can't do it", but I can't understand why. Can anyone explain?
Clarification 2: I'm doing this as I have private methods in a class that take said enum, and I do not want the enum's values exposed - so, for example, I do not want anyone to know that E is defined as
enum E {
FUNCTIONALITY_NORMAL, FUNCTIONALITY_RESTRICTED, FUNCTIONALITY_FOR_PROJECT_X
}
as project X is not something I want my users to know about.
So, I wanted to forward declare the enum so I could put the private methods in the header file, declare the enum internally in the cpp, and distribute the built library file and header to people.
As for the compiler - it's GCC.
Forward declaration of enums is possible since C++11. Previously, the reason enum types couldn't be forward declared was because the size of the enumeration depended on its contents. As long as the size of the enumeration is specified by the application, it can be forward declared:
enum Enum1; // Illegal in C++03 and C++11; no size is explicitly specified.
enum Enum2 : unsigned int; // Legal in C++11.
enum class Enum3; // Legal in C++11, because enum class declarations have a default type of "int".
enum class Enum4: unsigned int; // Legal C++11.
enum Enum2 : unsigned short; // Illegal in C++11, because Enum2 was previously declared with a different type.
The reason the enum can't be forward declared is that, without knowing the values, the compiler can't know the storage required for the enum variable. C++ compilers are allowed to specify the actual storage space based on the size necessary to contain all the values specified. If all that is visible is the forward declaration, the translation unit can't know what storage size has been chosen – it could be a char, or an int, or something else.
From Section 7.2.5 of the ISO C++ Standard:
The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration. It is implementation-defined which integral type is used as the underlying type for an enumeration 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. The value of sizeof() applied to an enumeration type, an object of enumeration type, or an enumerator, is the value of sizeof() applied to the underlying type.
Since the caller to the function must know the sizes of the parameters to correctly set up the call stack, the number of enumerations in an enumeration list must be known before the function prototype.
Update:
In C++0X, a syntax for forward declaring enum types has been proposed and accepted. You can see the proposal at Forward declaration of enumerations (rev.3)
You can forward-declare an enum in C++11, so long as you declare its storage type at the same time. The syntax looks like this:
enum E : short;
void foo(E e);
....
enum E : short
{
VALUE_1,
VALUE_2,
....
}
In fact, if the function never refers to the values of the enumeration, you don't need the complete declaration at all at that point.
This is supported by G++ 4.6 and onwards (-std=c++0x or -std=c++11 in more recent versions). Visual C++ 2013 supports this; in earlier versions it has some sort of non-standard support that I haven't figured out yet - I found some suggestion that a simple forward declaration is legal, but your mileage may vary.
Forward declaring things in C++ is very useful because it dramatically speeds up compilation time. You can forward declare several things in C++ including: struct, class, function, etc...
But can you forward declare an enum in C++?
No, you can't.
But why not allow it? If it were allowed you could define your enum type in your header file, and your enum values in your source file. It sounds like it should be allowed, right?
Wrong.
In C++ there is no default type for enum like there is in C# (int). In C++ your enum type will be determined by the compiler to be any type that will fit the range of values you have for your enum.
What does that mean?
It means that your enum's underlying type cannot be fully determined until you have all of the values of the enum defined. Which means you cannot separate the declaration and definition of your enum. And therefore you cannot forward declare an enum in C++.
The ISO C++ standard S7.2.5:
The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration. It is implementation-defined which integral type is used as the underlying type for an enumeration 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. The value of sizeof() applied to an enumeration type, an object of enumeration type, or an enumerator, is the value of sizeof() applied to the underlying type.
You can determine the size of an enumerated type in C++ by using the sizeof operator. The size of the enumerated type is the size of its underlying type. In this way you can guess which type your compiler is using for your enum.
What if you specify the type of your enum explicitly like this:
enum Color : char { Red=0, Green=1, Blue=2};
assert(sizeof Color == 1);
Can you then forward declare your enum?
No. But why not?
Specifying the type of an enum is not actually part of the current C++ standard. It is a VC++ extension. It will be part of C++0x though.
Source
[My answer is wrong, but I've left it here because the comments are useful].
Forward declaring enums is non-standard, because pointers to different enum types are not guaranteed to be the same size. The compiler may need to see the definition to know what size pointers can be used with this type.
In practice, at least on all the popular compilers, pointers to enums are a consistent size. Forward declaration of enums is provided as a language extension by Visual C++, for example.
There is indeed no such thing as a forward declaration of enum. As an enum's definition doesn't contain any code that could depend on other code using the enum, it's usually not a problem to define the enum completely when you're first declaring it.
If the only use of your enum is by private member functions, you can implement encapsulation by having the enum itself as a private member of that class. The enum still has to be fully defined at the point of declaration, that is, within the class definition. However, this is not a bigger problem as declaring private member functions there, and is not a worse exposal of implementation internals than that.
If you need a deeper degree of concealment for your implementation details, you can break it into an abstract interface, only consisting of pure virtual functions, and a concrete, completely concealed, class implementing (inheriting) the interface. Creation of class instances can be handled by a factory or a static member function of the interface. That way, even the real class name, let alone its private functions, won't be exposed.
I am just noting that the reason actually is that the size of the enum is not yet known after forward declaration. Well, you use forward declaration of a struct to be able to pass a pointer around or refer to an object from a place that's referred to in the forward declared struct definition itself too.
Forward declaring an enum would not be too useful, because one would wish to be able to pass around the enum by-value. You couldn't even have a pointer to it, because I recently got told some platforms use pointers of different size for char than for int or long. So it all depends on the content of the enum.
The current C++ Standard explicitly disallows doing something like
enum X;
(in 7.1.5.3/1). But the next C++ Standard due to next year allows the following, which convinced me the problem actually has to do with the underlying type:
enum X : int;
It's known as an "opaque" enum declaration. You can even use X by value in the following code. And its enumerators can later be defined in a later redeclaration of the enumeration. See 7.2 in the current working draft.
I'd do it this way:
[in the public header]
typedef unsigned long E;
void Foo(E e);
[in the internal header]
enum Econtent { FUNCTIONALITY_NORMAL, FUNCTIONALITY_RESTRICTED, FUNCTIONALITY_FOR_PROJECT_X,
FORCE_32BIT = 0xFFFFFFFF };
By adding FORCE_32BIT we ensure that Econtent compiles to a long, so it's interchangeable with E.
You can wrap the enum in a struct, adding in some constructors and type conversions, and forward declare the struct instead.
#define ENUM_CLASS(NAME, TYPE, VALUES...) \
struct NAME { \
enum e { VALUES }; \
explicit NAME(TYPE v) : val(v) {} \
NAME(e v) : val(v) {} \
operator e() const { return e(val); } \
private:\
TYPE val; \
}
This appears to work:
http://ideone.com/TYtP2
If you really don't want your enum to appear in your header file and ensure that it is only used by private methods, then one solution can be to go with the PIMPL principle.
It's a technique that ensure to hide the class internals in the headers by just declaring:
class A
{
public:
...
private:
void* pImpl;
};
Then in your implementation file (.cpp), you declare a class that will be the representation of the internals.
class AImpl
{
public:
AImpl(A* pThis): m_pThis(pThis) {}
... all private methods here ...
private:
A* m_pThis;
};
You must dynamically create the implementation in the class constructor and delete it in the destructor and when implementing public method, you must use:
((AImpl*)pImpl)->PrivateMethod();
There are pros for using PIMPL. One is that it decouples your class header from its implementation, and there isn't any need to recompile other classes when changing one class implementation. Another is that is speeds up your compilation time, because your headers are so simple.
But it's a pain to use, so you should really ask yourself if just declaring your enum as private in the header is that much a trouble.
There's some dissent since this got bumped (sort of), so here's some relevant bits from the standard. Research shows that the standard doesn't really define forward declaration, nor does it explicitly state that enums can or can't be forward declared.
First, from dcl.enum, section 7.2:
The underlying type of an enumeration
is an integral type that can represent
all the enumerator values defined in
the enumeration. It is
implementation-defined which integral
type is used as the underlying type
for an enumeration 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. The value of
sizeof() applied to an enumeration
type, an object of enumeration type,
or an enumerator, is the value of
sizeof() applied to the underlying
type.
So the underlying type of an enum is implementation-defined, with one minor restriction.
Next we flip to the section on "incomplete types" (3.9), which is about as close as we come to any standard on forward declarations:
A class that has been declared but not defined, or an array of unknown size or of
incomplete element type, is an incompletely-defined object type.
A class type (such as "class X") might be incomplete at one point in a translation
unit and complete later on; the type "class X" is the same type at both points. The
declared type of an array object might be an array of incomplete class type and
therefore incomplete; if the class type is completed later on in the translation unit,
the array type becomes complete; the array type at those two points is the same type.
The declared type of an array object might be an array of unknown size and therefore be
incomplete at one point in a translation unit and complete later on; the array types at
those two points ("array of unknown bound of T" and "array of N T") are different
types. The type of a pointer to array of unknown size, or of a type defined by a typedef
declaration to be an array of unknown size, cannot be completed.
So there, the standard pretty much laid out the types that can be forward declared. Enum wasn't there, so compiler authors generally regard forward declaring as disallowed by the standard due to the variable size of its underlying type.
It makes sense, too. Enums are usually referenced in by-value situations, and the compiler would indeed need to know the storage size in those situations. Since the storage size is implementation defined, many compilers may just choose to use 32 bit values for the underlying type of every enum, at which point it becomes possible to forward declare them.
An interesting experiment might be to try forward declaring an enum in Visual Studio, then forcing it to use an underlying type greater than sizeof(int) as explained above to see what happens.
In my projects, I adopted the Namespace-Bound Enumeration technique to deal with enums from legacy and 3rd-party components. Here is an example:
forward.h:
namespace type
{
class legacy_type;
typedef const legacy_type& type;
}
enum.h:
// May be defined here or pulled in via #include.
namespace legacy
{
enum evil { x , y, z };
}
namespace type
{
using legacy::evil;
class legacy_type
{
public:
legacy_type(evil e)
: e_(e)
{}
operator evil() const
{
return e_;
}
private:
evil e_;
};
}
foo.h:
#include "forward.h"
class foo
{
public:
void f(type::type t);
};
foo.cc:
#include "foo.h"
#include <iostream>
#include "enum.h"
void foo::f(type::type t)
{
switch (t)
{
case legacy::x:
std::cout << "x" << std::endl;
break;
case legacy::y:
std::cout << "y" << std::endl;
break;
case legacy::z:
std::cout << "z" << std::endl;
break;
default:
std::cout << "default" << std::endl;
}
}
main.cc:
#include "foo.h"
#include "enum.h"
int main()
{
foo fu;
fu.f(legacy::x);
return 0;
}
Note that the foo.h header does not have to know anything about legacy::evil. Only the files that use the legacy type legacy::evil (here: main.cc) need to include enum.h.
It seems it can not be forward-declared in GCC!
An interesting discussion is here.
For VC++, here's the test about forward declaration and specifying the underlying type:
The following code is compiled OK.
typedef int myint;
enum T ;
void foo(T * tp )
{
* tp = (T)0x12345678;
}
enum T : char
{
A
};
But I got the warning for /W4 (/W3 does not incur this warning)
warning C4480: nonstandard extension used: specifying underlying type for enum 'T'
VC++ (Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86) looks buggy in the above case:
when seeing enum T; VC assumes the enum type T uses default 4 bytes int as underlying type, so the generated assembly code is:
?foo##YAXPAW4T###Z PROC ; foo
; File e:\work\c_cpp\cpp_snippet.cpp
; Line 13
push ebp
mov ebp, esp
; Line 14
mov eax, DWORD PTR _tp$[ebp]
mov DWORD PTR [eax], 305419896 ; 12345678H
; Line 15
pop ebp
ret 0
?foo##YAXPAW4T###Z ENDP ; foo
The above assembly code is extracted from /Fatest.asm directly, not my personal guess.
Do you see the
mov DWORD PTR[eax], 305419896 ; 12345678H
line?
the following code snippet proves it:
int main(int argc, char *argv)
{
union {
char ca[4];
T t;
}a;
a.ca[0] = a.ca[1] = a.[ca[2] = a.ca[3] = 1;
foo( &a.t) ;
printf("%#x, %#x, %#x, %#x\n", a.ca[0], a.ca[1], a.ca[2], a.ca[3] );
return 0;
}
The result is:
0x78, 0x56, 0x34, 0x12
After removing the forward declaration of enum T and move the definition of function foo after the enum T's definition: the result is OK:
The above key instruction becomes:
mov BYTE PTR [eax], 120 ; 00000078H
The final result is:
0x78, 0x1, 0x1, 0x1
Note the value is not being overwritten.
So using of the forward-declaration of enum in VC++ is considered harmful.
BTW, to not surprise, the syntax for declaration of the underlying type is same as its in C#. In pratice I found it's worth to save three bytes by specifying the underlying type as char when talking to the embedded system, which is memory limited.
My solution to your problem would be to either:
1 - use int instead of enums: Declare your ints in an anonymous namespace in your CPP file (not in the header):
namespace
{
const int FUNCTIONALITY_NORMAL = 0 ;
const int FUNCTIONALITY_RESTRICTED = 1 ;
const int FUNCTIONALITY_FOR_PROJECT_X = 2 ;
}
As your methods are private, no one will mess with the data. You could even go further to test if someone sends you an invalid data:
namespace
{
const int FUNCTIONALITY_begin = 0 ;
const int FUNCTIONALITY_NORMAL = 0 ;
const int FUNCTIONALITY_RESTRICTED = 1 ;
const int FUNCTIONALITY_FOR_PROJECT_X = 2 ;
const int FUNCTIONALITY_end = 3 ;
bool isFunctionalityCorrect(int i)
{
return (i >= FUNCTIONALITY_begin) && (i < FUNCTIONALITY_end) ;
}
}
2 : create a full class with limited const instantiations, like done in Java. Forward declare the class, and then define it in the CPP file, and instanciate only the enum-like values. I did something like that in C++, and the result was not as satisfying as desired, as it needed some code to simulate an enum (copy construction, operator =, etc.).
3 : As proposed before, use the privately declared enum. Despite the fact an user will see its full definition, it won't be able to use it, nor use the private methods. So you'll usually be able to modify the enum and the content of the existing methods without needing recompiling of code using your class.
My guess would be either the solution 3 or 1.
To anyone facing this for iOS/Mac/Xcode,
If you are facing this while integrating C/C++ headers in XCode with Objective-C, just change the extension of your file from .mm to .m
Because the enum can be an integral size of varying size (the compiler decides which size a given enum has), the pointer to the enum can also have varying size, since it's an integral type (chars have pointers of a different size on some platforms for instance).
So the compiler can't even let you forward-declare the enum and user a pointer to it, because even there, it needs the size of the enum.
You define an enumeration to restrict the possible values of elements of the type to a limited set. This restriction is to be enforced at compile time.
When forward declaring the fact that you will use a 'limited set' later on doesn't add any value: subsequent code needs to know the possible values in order to benefit from it.
Although the compiler is concerned about the size of the enumerated type, the intent of the enumeration gets lost when you forward declare it.
This way we can forward declare enum
enum A : int;
please refer the link for details.

Why not C++ (not C++0x) support enum forward declaration? [duplicate]

I'm trying to do something like the following:
enum E;
void Foo(E e);
enum E {A, B, C};
which the compiler rejects. I've had a quick look on Google and the consensus seems to be "you can't do it", but I can't understand why. Can anyone explain?
Clarification 2: I'm doing this as I have private methods in a class that take said enum, and I do not want the enum's values exposed - so, for example, I do not want anyone to know that E is defined as
enum E {
FUNCTIONALITY_NORMAL, FUNCTIONALITY_RESTRICTED, FUNCTIONALITY_FOR_PROJECT_X
}
as project X is not something I want my users to know about.
So, I wanted to forward declare the enum so I could put the private methods in the header file, declare the enum internally in the cpp, and distribute the built library file and header to people.
As for the compiler - it's GCC.
Forward declaration of enums is possible since C++11. Previously, the reason enum types couldn't be forward declared was because the size of the enumeration depended on its contents. As long as the size of the enumeration is specified by the application, it can be forward declared:
enum Enum1; // Illegal in C++03 and C++11; no size is explicitly specified.
enum Enum2 : unsigned int; // Legal in C++11.
enum class Enum3; // Legal in C++11, because enum class declarations have a default type of "int".
enum class Enum4: unsigned int; // Legal C++11.
enum Enum2 : unsigned short; // Illegal in C++11, because Enum2 was previously declared with a different type.
The reason the enum can't be forward declared is that, without knowing the values, the compiler can't know the storage required for the enum variable. C++ compilers are allowed to specify the actual storage space based on the size necessary to contain all the values specified. If all that is visible is the forward declaration, the translation unit can't know what storage size has been chosen – it could be a char, or an int, or something else.
From Section 7.2.5 of the ISO C++ Standard:
The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration. It is implementation-defined which integral type is used as the underlying type for an enumeration 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. The value of sizeof() applied to an enumeration type, an object of enumeration type, or an enumerator, is the value of sizeof() applied to the underlying type.
Since the caller to the function must know the sizes of the parameters to correctly set up the call stack, the number of enumerations in an enumeration list must be known before the function prototype.
Update:
In C++0X, a syntax for forward declaring enum types has been proposed and accepted. You can see the proposal at Forward declaration of enumerations (rev.3)
You can forward-declare an enum in C++11, so long as you declare its storage type at the same time. The syntax looks like this:
enum E : short;
void foo(E e);
....
enum E : short
{
VALUE_1,
VALUE_2,
....
}
In fact, if the function never refers to the values of the enumeration, you don't need the complete declaration at all at that point.
This is supported by G++ 4.6 and onwards (-std=c++0x or -std=c++11 in more recent versions). Visual C++ 2013 supports this; in earlier versions it has some sort of non-standard support that I haven't figured out yet - I found some suggestion that a simple forward declaration is legal, but your mileage may vary.
Forward declaring things in C++ is very useful because it dramatically speeds up compilation time. You can forward declare several things in C++ including: struct, class, function, etc...
But can you forward declare an enum in C++?
No, you can't.
But why not allow it? If it were allowed you could define your enum type in your header file, and your enum values in your source file. It sounds like it should be allowed, right?
Wrong.
In C++ there is no default type for enum like there is in C# (int). In C++ your enum type will be determined by the compiler to be any type that will fit the range of values you have for your enum.
What does that mean?
It means that your enum's underlying type cannot be fully determined until you have all of the values of the enum defined. Which means you cannot separate the declaration and definition of your enum. And therefore you cannot forward declare an enum in C++.
The ISO C++ standard S7.2.5:
The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration. It is implementation-defined which integral type is used as the underlying type for an enumeration 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. The value of sizeof() applied to an enumeration type, an object of enumeration type, or an enumerator, is the value of sizeof() applied to the underlying type.
You can determine the size of an enumerated type in C++ by using the sizeof operator. The size of the enumerated type is the size of its underlying type. In this way you can guess which type your compiler is using for your enum.
What if you specify the type of your enum explicitly like this:
enum Color : char { Red=0, Green=1, Blue=2};
assert(sizeof Color == 1);
Can you then forward declare your enum?
No. But why not?
Specifying the type of an enum is not actually part of the current C++ standard. It is a VC++ extension. It will be part of C++0x though.
Source
[My answer is wrong, but I've left it here because the comments are useful].
Forward declaring enums is non-standard, because pointers to different enum types are not guaranteed to be the same size. The compiler may need to see the definition to know what size pointers can be used with this type.
In practice, at least on all the popular compilers, pointers to enums are a consistent size. Forward declaration of enums is provided as a language extension by Visual C++, for example.
There is indeed no such thing as a forward declaration of enum. As an enum's definition doesn't contain any code that could depend on other code using the enum, it's usually not a problem to define the enum completely when you're first declaring it.
If the only use of your enum is by private member functions, you can implement encapsulation by having the enum itself as a private member of that class. The enum still has to be fully defined at the point of declaration, that is, within the class definition. However, this is not a bigger problem as declaring private member functions there, and is not a worse exposal of implementation internals than that.
If you need a deeper degree of concealment for your implementation details, you can break it into an abstract interface, only consisting of pure virtual functions, and a concrete, completely concealed, class implementing (inheriting) the interface. Creation of class instances can be handled by a factory or a static member function of the interface. That way, even the real class name, let alone its private functions, won't be exposed.
I am just noting that the reason actually is that the size of the enum is not yet known after forward declaration. Well, you use forward declaration of a struct to be able to pass a pointer around or refer to an object from a place that's referred to in the forward declared struct definition itself too.
Forward declaring an enum would not be too useful, because one would wish to be able to pass around the enum by-value. You couldn't even have a pointer to it, because I recently got told some platforms use pointers of different size for char than for int or long. So it all depends on the content of the enum.
The current C++ Standard explicitly disallows doing something like
enum X;
(in 7.1.5.3/1). But the next C++ Standard due to next year allows the following, which convinced me the problem actually has to do with the underlying type:
enum X : int;
It's known as an "opaque" enum declaration. You can even use X by value in the following code. And its enumerators can later be defined in a later redeclaration of the enumeration. See 7.2 in the current working draft.
I'd do it this way:
[in the public header]
typedef unsigned long E;
void Foo(E e);
[in the internal header]
enum Econtent { FUNCTIONALITY_NORMAL, FUNCTIONALITY_RESTRICTED, FUNCTIONALITY_FOR_PROJECT_X,
FORCE_32BIT = 0xFFFFFFFF };
By adding FORCE_32BIT we ensure that Econtent compiles to a long, so it's interchangeable with E.
You can wrap the enum in a struct, adding in some constructors and type conversions, and forward declare the struct instead.
#define ENUM_CLASS(NAME, TYPE, VALUES...) \
struct NAME { \
enum e { VALUES }; \
explicit NAME(TYPE v) : val(v) {} \
NAME(e v) : val(v) {} \
operator e() const { return e(val); } \
private:\
TYPE val; \
}
This appears to work:
http://ideone.com/TYtP2
If you really don't want your enum to appear in your header file and ensure that it is only used by private methods, then one solution can be to go with the PIMPL principle.
It's a technique that ensure to hide the class internals in the headers by just declaring:
class A
{
public:
...
private:
void* pImpl;
};
Then in your implementation file (.cpp), you declare a class that will be the representation of the internals.
class AImpl
{
public:
AImpl(A* pThis): m_pThis(pThis) {}
... all private methods here ...
private:
A* m_pThis;
};
You must dynamically create the implementation in the class constructor and delete it in the destructor and when implementing public method, you must use:
((AImpl*)pImpl)->PrivateMethod();
There are pros for using PIMPL. One is that it decouples your class header from its implementation, and there isn't any need to recompile other classes when changing one class implementation. Another is that is speeds up your compilation time, because your headers are so simple.
But it's a pain to use, so you should really ask yourself if just declaring your enum as private in the header is that much a trouble.
There's some dissent since this got bumped (sort of), so here's some relevant bits from the standard. Research shows that the standard doesn't really define forward declaration, nor does it explicitly state that enums can or can't be forward declared.
First, from dcl.enum, section 7.2:
The underlying type of an enumeration
is an integral type that can represent
all the enumerator values defined in
the enumeration. It is
implementation-defined which integral
type is used as the underlying type
for an enumeration 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. The value of
sizeof() applied to an enumeration
type, an object of enumeration type,
or an enumerator, is the value of
sizeof() applied to the underlying
type.
So the underlying type of an enum is implementation-defined, with one minor restriction.
Next we flip to the section on "incomplete types" (3.9), which is about as close as we come to any standard on forward declarations:
A class that has been declared but not defined, or an array of unknown size or of
incomplete element type, is an incompletely-defined object type.
A class type (such as "class X") might be incomplete at one point in a translation
unit and complete later on; the type "class X" is the same type at both points. The
declared type of an array object might be an array of incomplete class type and
therefore incomplete; if the class type is completed later on in the translation unit,
the array type becomes complete; the array type at those two points is the same type.
The declared type of an array object might be an array of unknown size and therefore be
incomplete at one point in a translation unit and complete later on; the array types at
those two points ("array of unknown bound of T" and "array of N T") are different
types. The type of a pointer to array of unknown size, or of a type defined by a typedef
declaration to be an array of unknown size, cannot be completed.
So there, the standard pretty much laid out the types that can be forward declared. Enum wasn't there, so compiler authors generally regard forward declaring as disallowed by the standard due to the variable size of its underlying type.
It makes sense, too. Enums are usually referenced in by-value situations, and the compiler would indeed need to know the storage size in those situations. Since the storage size is implementation defined, many compilers may just choose to use 32 bit values for the underlying type of every enum, at which point it becomes possible to forward declare them.
An interesting experiment might be to try forward declaring an enum in Visual Studio, then forcing it to use an underlying type greater than sizeof(int) as explained above to see what happens.
In my projects, I adopted the Namespace-Bound Enumeration technique to deal with enums from legacy and 3rd-party components. Here is an example:
forward.h:
namespace type
{
class legacy_type;
typedef const legacy_type& type;
}
enum.h:
// May be defined here or pulled in via #include.
namespace legacy
{
enum evil { x , y, z };
}
namespace type
{
using legacy::evil;
class legacy_type
{
public:
legacy_type(evil e)
: e_(e)
{}
operator evil() const
{
return e_;
}
private:
evil e_;
};
}
foo.h:
#include "forward.h"
class foo
{
public:
void f(type::type t);
};
foo.cc:
#include "foo.h"
#include <iostream>
#include "enum.h"
void foo::f(type::type t)
{
switch (t)
{
case legacy::x:
std::cout << "x" << std::endl;
break;
case legacy::y:
std::cout << "y" << std::endl;
break;
case legacy::z:
std::cout << "z" << std::endl;
break;
default:
std::cout << "default" << std::endl;
}
}
main.cc:
#include "foo.h"
#include "enum.h"
int main()
{
foo fu;
fu.f(legacy::x);
return 0;
}
Note that the foo.h header does not have to know anything about legacy::evil. Only the files that use the legacy type legacy::evil (here: main.cc) need to include enum.h.
It seems it can not be forward-declared in GCC!
An interesting discussion is here.
For VC++, here's the test about forward declaration and specifying the underlying type:
The following code is compiled OK.
typedef int myint;
enum T ;
void foo(T * tp )
{
* tp = (T)0x12345678;
}
enum T : char
{
A
};
But I got the warning for /W4 (/W3 does not incur this warning)
warning C4480: nonstandard extension used: specifying underlying type for enum 'T'
VC++ (Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86) looks buggy in the above case:
when seeing enum T; VC assumes the enum type T uses default 4 bytes int as underlying type, so the generated assembly code is:
?foo##YAXPAW4T###Z PROC ; foo
; File e:\work\c_cpp\cpp_snippet.cpp
; Line 13
push ebp
mov ebp, esp
; Line 14
mov eax, DWORD PTR _tp$[ebp]
mov DWORD PTR [eax], 305419896 ; 12345678H
; Line 15
pop ebp
ret 0
?foo##YAXPAW4T###Z ENDP ; foo
The above assembly code is extracted from /Fatest.asm directly, not my personal guess.
Do you see the
mov DWORD PTR[eax], 305419896 ; 12345678H
line?
the following code snippet proves it:
int main(int argc, char *argv)
{
union {
char ca[4];
T t;
}a;
a.ca[0] = a.ca[1] = a.[ca[2] = a.ca[3] = 1;
foo( &a.t) ;
printf("%#x, %#x, %#x, %#x\n", a.ca[0], a.ca[1], a.ca[2], a.ca[3] );
return 0;
}
The result is:
0x78, 0x56, 0x34, 0x12
After removing the forward declaration of enum T and move the definition of function foo after the enum T's definition: the result is OK:
The above key instruction becomes:
mov BYTE PTR [eax], 120 ; 00000078H
The final result is:
0x78, 0x1, 0x1, 0x1
Note the value is not being overwritten.
So using of the forward-declaration of enum in VC++ is considered harmful.
BTW, to not surprise, the syntax for declaration of the underlying type is same as its in C#. In pratice I found it's worth to save three bytes by specifying the underlying type as char when talking to the embedded system, which is memory limited.
My solution to your problem would be to either:
1 - use int instead of enums: Declare your ints in an anonymous namespace in your CPP file (not in the header):
namespace
{
const int FUNCTIONALITY_NORMAL = 0 ;
const int FUNCTIONALITY_RESTRICTED = 1 ;
const int FUNCTIONALITY_FOR_PROJECT_X = 2 ;
}
As your methods are private, no one will mess with the data. You could even go further to test if someone sends you an invalid data:
namespace
{
const int FUNCTIONALITY_begin = 0 ;
const int FUNCTIONALITY_NORMAL = 0 ;
const int FUNCTIONALITY_RESTRICTED = 1 ;
const int FUNCTIONALITY_FOR_PROJECT_X = 2 ;
const int FUNCTIONALITY_end = 3 ;
bool isFunctionalityCorrect(int i)
{
return (i >= FUNCTIONALITY_begin) && (i < FUNCTIONALITY_end) ;
}
}
2 : create a full class with limited const instantiations, like done in Java. Forward declare the class, and then define it in the CPP file, and instanciate only the enum-like values. I did something like that in C++, and the result was not as satisfying as desired, as it needed some code to simulate an enum (copy construction, operator =, etc.).
3 : As proposed before, use the privately declared enum. Despite the fact an user will see its full definition, it won't be able to use it, nor use the private methods. So you'll usually be able to modify the enum and the content of the existing methods without needing recompiling of code using your class.
My guess would be either the solution 3 or 1.
To anyone facing this for iOS/Mac/Xcode,
If you are facing this while integrating C/C++ headers in XCode with Objective-C, just change the extension of your file from .mm to .m
Because the enum can be an integral size of varying size (the compiler decides which size a given enum has), the pointer to the enum can also have varying size, since it's an integral type (chars have pointers of a different size on some platforms for instance).
So the compiler can't even let you forward-declare the enum and user a pointer to it, because even there, it needs the size of the enum.
You define an enumeration to restrict the possible values of elements of the type to a limited set. This restriction is to be enforced at compile time.
When forward declaring the fact that you will use a 'limited set' later on doesn't add any value: subsequent code needs to know the possible values in order to benefit from it.
Although the compiler is concerned about the size of the enumerated type, the intent of the enumeration gets lost when you forward declare it.
This way we can forward declare enum
enum A : int;
please refer the link for details.

extern enum in c++

I have an enum I have declared in some .h file:
typedef enum {
NONE,
ONE,
TWO,
THREE
} MYENUM;
in a seperate .cpp I cannot do this:
extern enum MYENUM; //works
extern MYENUM TWO; //makes sence, TWO is not an INSTANCE of MYENUM...
how would one do so without including the whole header where the enum is declared?
You can't use an incomplete type. You can only pass around pointers to it. This is because until the type is completed, the compiler doesn't know how big it is. OTOH a pointer is the size of a data pointer, no matter what type it's pointing to. One of the things you can't do with an incomplete type is declare variables of that type.
extern in a variable declaration means that the compiler will emit a reference to an identifier provided in another compilation unit (to be resolved by the linker), instead of allocating storage. extern does not modify the type, even if it appears next to the type name in C++ grammar.
What you can do is take advantage of the fact that enum members are integral constant values, and convert just fine to the primitive integral types.
So you can do this:
A.cpp
enum MYENUM { ONE=1, TWO, THREE };
int var = TWO;
B.cpp
extern int var;
But the types must match. You couldn't say MYENUM var = TWO; and also extern int var;. That would violate the one-definition-rule (violation might or might not be detected by the linker).
As an aside, this is incorrect:
typedef enum {
NONE,
ONE,
TWO,
THREE
} MYENUM;
enum MYENUM TWO;
MYENUM is NOT an enum identifier. It is a typedef, and cannot be qualified with the enum keyword later.
You cannot use enum values, if they are not visible. If the header is too large to include, why not just put the enum in its own header, and include only that?

Using numeric_limits::max() in constant expressions

I would like to define inside a class a constant which value is the maximum possible int. Something like this:
class A
{
...
static const int ERROR_VALUE = std::numeric_limits<int>::max();
...
}
This declaration fails to compile with the following message:
numeric.cpp:8: error: 'std::numeric_limits::max()' cannot appear in a constant-expression
numeric.cpp:8: error: a function call cannot appear in a constant-expression
I understand why this doesn't work, but two things look weird to me:
It seems to me a natural decision to use the value in constant expressions. Why did the language designers decide to make max() a function thus not allowing this usage?
The spec claims in 18.2.1 that
For all members declared static const in the numeric_limits template, specializations shall define these values in such a way that they are usable as integral constant expressions.
Doesn't it mean that I should be able to use it in my scenario and doesn't it contradict the error message?
Thank you.
Looks like a bit of a defect...
In C++0x, numeric_limits will have everything marked with constexpr, meaning you will be able to use min() and max() as compile-time constants.
While the current standard lacks support here, for integral types Boost.IntegerTraits gives you the compile time constants const_min and const_max.
The problem arises from §9.4.2/4:
If a static data member is of const integral or const enumeration type, its declaration in the class definition can specify a constant-initializer which shall be an integral constant expression (5.19). In that case, the member can appear in integral constant expressions.
Note that it adds:
The member shall still be defined in a name- space scope if it is used in the program and the namespace scope definition shall not contain an initializer.
As others already mentioned numeric_limits min() and max() simply aren't integral constant expressions, i.e. compile time constants.
You want:
#include <limits>
struct A {
static const int ERROR_VALUE;
};
const int A::ERROR_VALUE = std::numeric_limits<int>::max();
Put the class/struct in a header and the definition in a .cpp file.
It doesn't contradict, because max is not defined static const. It's just a static member function. Functions can't be const, and static member functions can't have a const attached at the very right either.
There is also a double max() in the double version of the limits, and in C++03 it wouldn't work to say static double const max = .... So to be consistent, max() is a function for all versions of the limit template.
Now, it's known that max() not being able to be used like that is bad, and C++0x already solves it by making it a constexpr function, allowing your proposed usage.
I will try to answer you as much as I understood from your question:
1- If you want a static const int in your program to be initialized with a function:
int Data()
{
return rand();
}
class A
{
public :
static const int ee;
};
const int A::ee=Data();
This works on VS 2008
2- If you want to get max and min number for a given data type, then use these definitions
INT_MAX, INT_MIN, LONG_MAX and so on..
3- If however you need to use these wrt template type, then
hard code the templates yourself
template<>
int MaxData()
{
return INT_MAX;
}
and
template<>
long MaxData()
{
return LONG_MAX ;
}
and call them like this
int y=MaxData<int>();
4- and if you are only dealing with binary represented types only, then use this:
template <class T>
T MaxData(){
return ~(1<<((sizeof(T)*8)-1));
}
and this
template <class T>
T MinData(){
return (1<<((sizeof(T)*8)-1));
}
Hope this can help you..

Forward declaring an enum in C++

I'm trying to do something like the following:
enum E;
void Foo(E e);
enum E {A, B, C};
which the compiler rejects. I've had a quick look on Google and the consensus seems to be "you can't do it", but I can't understand why. Can anyone explain?
Clarification 2: I'm doing this as I have private methods in a class that take said enum, and I do not want the enum's values exposed - so, for example, I do not want anyone to know that E is defined as
enum E {
FUNCTIONALITY_NORMAL, FUNCTIONALITY_RESTRICTED, FUNCTIONALITY_FOR_PROJECT_X
}
as project X is not something I want my users to know about.
So, I wanted to forward declare the enum so I could put the private methods in the header file, declare the enum internally in the cpp, and distribute the built library file and header to people.
As for the compiler - it's GCC.
Forward declaration of enums is possible since C++11. Previously, the reason enum types couldn't be forward declared was because the size of the enumeration depended on its contents. As long as the size of the enumeration is specified by the application, it can be forward declared:
enum Enum1; // Illegal in C++03 and C++11; no size is explicitly specified.
enum Enum2 : unsigned int; // Legal in C++11.
enum class Enum3; // Legal in C++11, because enum class declarations have a default type of "int".
enum class Enum4: unsigned int; // Legal C++11.
enum Enum2 : unsigned short; // Illegal in C++11, because Enum2 was previously declared with a different type.
The reason the enum can't be forward declared is that, without knowing the values, the compiler can't know the storage required for the enum variable. C++ compilers are allowed to specify the actual storage space based on the size necessary to contain all the values specified. If all that is visible is the forward declaration, the translation unit can't know what storage size has been chosen – it could be a char, or an int, or something else.
From Section 7.2.5 of the ISO C++ Standard:
The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration. It is implementation-defined which integral type is used as the underlying type for an enumeration 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. The value of sizeof() applied to an enumeration type, an object of enumeration type, or an enumerator, is the value of sizeof() applied to the underlying type.
Since the caller to the function must know the sizes of the parameters to correctly set up the call stack, the number of enumerations in an enumeration list must be known before the function prototype.
Update:
In C++0X, a syntax for forward declaring enum types has been proposed and accepted. You can see the proposal at Forward declaration of enumerations (rev.3)
You can forward-declare an enum in C++11, so long as you declare its storage type at the same time. The syntax looks like this:
enum E : short;
void foo(E e);
....
enum E : short
{
VALUE_1,
VALUE_2,
....
}
In fact, if the function never refers to the values of the enumeration, you don't need the complete declaration at all at that point.
This is supported by G++ 4.6 and onwards (-std=c++0x or -std=c++11 in more recent versions). Visual C++ 2013 supports this; in earlier versions it has some sort of non-standard support that I haven't figured out yet - I found some suggestion that a simple forward declaration is legal, but your mileage may vary.
Forward declaring things in C++ is very useful because it dramatically speeds up compilation time. You can forward declare several things in C++ including: struct, class, function, etc...
But can you forward declare an enum in C++?
No, you can't.
But why not allow it? If it were allowed you could define your enum type in your header file, and your enum values in your source file. It sounds like it should be allowed, right?
Wrong.
In C++ there is no default type for enum like there is in C# (int). In C++ your enum type will be determined by the compiler to be any type that will fit the range of values you have for your enum.
What does that mean?
It means that your enum's underlying type cannot be fully determined until you have all of the values of the enum defined. Which means you cannot separate the declaration and definition of your enum. And therefore you cannot forward declare an enum in C++.
The ISO C++ standard S7.2.5:
The underlying type of an enumeration is an integral type that can represent all the enumerator values defined in the enumeration. It is implementation-defined which integral type is used as the underlying type for an enumeration 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. The value of sizeof() applied to an enumeration type, an object of enumeration type, or an enumerator, is the value of sizeof() applied to the underlying type.
You can determine the size of an enumerated type in C++ by using the sizeof operator. The size of the enumerated type is the size of its underlying type. In this way you can guess which type your compiler is using for your enum.
What if you specify the type of your enum explicitly like this:
enum Color : char { Red=0, Green=1, Blue=2};
assert(sizeof Color == 1);
Can you then forward declare your enum?
No. But why not?
Specifying the type of an enum is not actually part of the current C++ standard. It is a VC++ extension. It will be part of C++0x though.
Source
[My answer is wrong, but I've left it here because the comments are useful].
Forward declaring enums is non-standard, because pointers to different enum types are not guaranteed to be the same size. The compiler may need to see the definition to know what size pointers can be used with this type.
In practice, at least on all the popular compilers, pointers to enums are a consistent size. Forward declaration of enums is provided as a language extension by Visual C++, for example.
There is indeed no such thing as a forward declaration of enum. As an enum's definition doesn't contain any code that could depend on other code using the enum, it's usually not a problem to define the enum completely when you're first declaring it.
If the only use of your enum is by private member functions, you can implement encapsulation by having the enum itself as a private member of that class. The enum still has to be fully defined at the point of declaration, that is, within the class definition. However, this is not a bigger problem as declaring private member functions there, and is not a worse exposal of implementation internals than that.
If you need a deeper degree of concealment for your implementation details, you can break it into an abstract interface, only consisting of pure virtual functions, and a concrete, completely concealed, class implementing (inheriting) the interface. Creation of class instances can be handled by a factory or a static member function of the interface. That way, even the real class name, let alone its private functions, won't be exposed.
I am just noting that the reason actually is that the size of the enum is not yet known after forward declaration. Well, you use forward declaration of a struct to be able to pass a pointer around or refer to an object from a place that's referred to in the forward declared struct definition itself too.
Forward declaring an enum would not be too useful, because one would wish to be able to pass around the enum by-value. You couldn't even have a pointer to it, because I recently got told some platforms use pointers of different size for char than for int or long. So it all depends on the content of the enum.
The current C++ Standard explicitly disallows doing something like
enum X;
(in 7.1.5.3/1). But the next C++ Standard due to next year allows the following, which convinced me the problem actually has to do with the underlying type:
enum X : int;
It's known as an "opaque" enum declaration. You can even use X by value in the following code. And its enumerators can later be defined in a later redeclaration of the enumeration. See 7.2 in the current working draft.
I'd do it this way:
[in the public header]
typedef unsigned long E;
void Foo(E e);
[in the internal header]
enum Econtent { FUNCTIONALITY_NORMAL, FUNCTIONALITY_RESTRICTED, FUNCTIONALITY_FOR_PROJECT_X,
FORCE_32BIT = 0xFFFFFFFF };
By adding FORCE_32BIT we ensure that Econtent compiles to a long, so it's interchangeable with E.
You can wrap the enum in a struct, adding in some constructors and type conversions, and forward declare the struct instead.
#define ENUM_CLASS(NAME, TYPE, VALUES...) \
struct NAME { \
enum e { VALUES }; \
explicit NAME(TYPE v) : val(v) {} \
NAME(e v) : val(v) {} \
operator e() const { return e(val); } \
private:\
TYPE val; \
}
This appears to work:
http://ideone.com/TYtP2
If you really don't want your enum to appear in your header file and ensure that it is only used by private methods, then one solution can be to go with the PIMPL principle.
It's a technique that ensure to hide the class internals in the headers by just declaring:
class A
{
public:
...
private:
void* pImpl;
};
Then in your implementation file (.cpp), you declare a class that will be the representation of the internals.
class AImpl
{
public:
AImpl(A* pThis): m_pThis(pThis) {}
... all private methods here ...
private:
A* m_pThis;
};
You must dynamically create the implementation in the class constructor and delete it in the destructor and when implementing public method, you must use:
((AImpl*)pImpl)->PrivateMethod();
There are pros for using PIMPL. One is that it decouples your class header from its implementation, and there isn't any need to recompile other classes when changing one class implementation. Another is that is speeds up your compilation time, because your headers are so simple.
But it's a pain to use, so you should really ask yourself if just declaring your enum as private in the header is that much a trouble.
There's some dissent since this got bumped (sort of), so here's some relevant bits from the standard. Research shows that the standard doesn't really define forward declaration, nor does it explicitly state that enums can or can't be forward declared.
First, from dcl.enum, section 7.2:
The underlying type of an enumeration
is an integral type that can represent
all the enumerator values defined in
the enumeration. It is
implementation-defined which integral
type is used as the underlying type
for an enumeration 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. The value of
sizeof() applied to an enumeration
type, an object of enumeration type,
or an enumerator, is the value of
sizeof() applied to the underlying
type.
So the underlying type of an enum is implementation-defined, with one minor restriction.
Next we flip to the section on "incomplete types" (3.9), which is about as close as we come to any standard on forward declarations:
A class that has been declared but not defined, or an array of unknown size or of
incomplete element type, is an incompletely-defined object type.
A class type (such as "class X") might be incomplete at one point in a translation
unit and complete later on; the type "class X" is the same type at both points. The
declared type of an array object might be an array of incomplete class type and
therefore incomplete; if the class type is completed later on in the translation unit,
the array type becomes complete; the array type at those two points is the same type.
The declared type of an array object might be an array of unknown size and therefore be
incomplete at one point in a translation unit and complete later on; the array types at
those two points ("array of unknown bound of T" and "array of N T") are different
types. The type of a pointer to array of unknown size, or of a type defined by a typedef
declaration to be an array of unknown size, cannot be completed.
So there, the standard pretty much laid out the types that can be forward declared. Enum wasn't there, so compiler authors generally regard forward declaring as disallowed by the standard due to the variable size of its underlying type.
It makes sense, too. Enums are usually referenced in by-value situations, and the compiler would indeed need to know the storage size in those situations. Since the storage size is implementation defined, many compilers may just choose to use 32 bit values for the underlying type of every enum, at which point it becomes possible to forward declare them.
An interesting experiment might be to try forward declaring an enum in Visual Studio, then forcing it to use an underlying type greater than sizeof(int) as explained above to see what happens.
In my projects, I adopted the Namespace-Bound Enumeration technique to deal with enums from legacy and 3rd-party components. Here is an example:
forward.h:
namespace type
{
class legacy_type;
typedef const legacy_type& type;
}
enum.h:
// May be defined here or pulled in via #include.
namespace legacy
{
enum evil { x , y, z };
}
namespace type
{
using legacy::evil;
class legacy_type
{
public:
legacy_type(evil e)
: e_(e)
{}
operator evil() const
{
return e_;
}
private:
evil e_;
};
}
foo.h:
#include "forward.h"
class foo
{
public:
void f(type::type t);
};
foo.cc:
#include "foo.h"
#include <iostream>
#include "enum.h"
void foo::f(type::type t)
{
switch (t)
{
case legacy::x:
std::cout << "x" << std::endl;
break;
case legacy::y:
std::cout << "y" << std::endl;
break;
case legacy::z:
std::cout << "z" << std::endl;
break;
default:
std::cout << "default" << std::endl;
}
}
main.cc:
#include "foo.h"
#include "enum.h"
int main()
{
foo fu;
fu.f(legacy::x);
return 0;
}
Note that the foo.h header does not have to know anything about legacy::evil. Only the files that use the legacy type legacy::evil (here: main.cc) need to include enum.h.
It seems it can not be forward-declared in GCC!
An interesting discussion is here.
For VC++, here's the test about forward declaration and specifying the underlying type:
The following code is compiled OK.
typedef int myint;
enum T ;
void foo(T * tp )
{
* tp = (T)0x12345678;
}
enum T : char
{
A
};
But I got the warning for /W4 (/W3 does not incur this warning)
warning C4480: nonstandard extension used: specifying underlying type for enum 'T'
VC++ (Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86) looks buggy in the above case:
when seeing enum T; VC assumes the enum type T uses default 4 bytes int as underlying type, so the generated assembly code is:
?foo##YAXPAW4T###Z PROC ; foo
; File e:\work\c_cpp\cpp_snippet.cpp
; Line 13
push ebp
mov ebp, esp
; Line 14
mov eax, DWORD PTR _tp$[ebp]
mov DWORD PTR [eax], 305419896 ; 12345678H
; Line 15
pop ebp
ret 0
?foo##YAXPAW4T###Z ENDP ; foo
The above assembly code is extracted from /Fatest.asm directly, not my personal guess.
Do you see the
mov DWORD PTR[eax], 305419896 ; 12345678H
line?
the following code snippet proves it:
int main(int argc, char *argv)
{
union {
char ca[4];
T t;
}a;
a.ca[0] = a.ca[1] = a.[ca[2] = a.ca[3] = 1;
foo( &a.t) ;
printf("%#x, %#x, %#x, %#x\n", a.ca[0], a.ca[1], a.ca[2], a.ca[3] );
return 0;
}
The result is:
0x78, 0x56, 0x34, 0x12
After removing the forward declaration of enum T and move the definition of function foo after the enum T's definition: the result is OK:
The above key instruction becomes:
mov BYTE PTR [eax], 120 ; 00000078H
The final result is:
0x78, 0x1, 0x1, 0x1
Note the value is not being overwritten.
So using of the forward-declaration of enum in VC++ is considered harmful.
BTW, to not surprise, the syntax for declaration of the underlying type is same as its in C#. In pratice I found it's worth to save three bytes by specifying the underlying type as char when talking to the embedded system, which is memory limited.
My solution to your problem would be to either:
1 - use int instead of enums: Declare your ints in an anonymous namespace in your CPP file (not in the header):
namespace
{
const int FUNCTIONALITY_NORMAL = 0 ;
const int FUNCTIONALITY_RESTRICTED = 1 ;
const int FUNCTIONALITY_FOR_PROJECT_X = 2 ;
}
As your methods are private, no one will mess with the data. You could even go further to test if someone sends you an invalid data:
namespace
{
const int FUNCTIONALITY_begin = 0 ;
const int FUNCTIONALITY_NORMAL = 0 ;
const int FUNCTIONALITY_RESTRICTED = 1 ;
const int FUNCTIONALITY_FOR_PROJECT_X = 2 ;
const int FUNCTIONALITY_end = 3 ;
bool isFunctionalityCorrect(int i)
{
return (i >= FUNCTIONALITY_begin) && (i < FUNCTIONALITY_end) ;
}
}
2 : create a full class with limited const instantiations, like done in Java. Forward declare the class, and then define it in the CPP file, and instanciate only the enum-like values. I did something like that in C++, and the result was not as satisfying as desired, as it needed some code to simulate an enum (copy construction, operator =, etc.).
3 : As proposed before, use the privately declared enum. Despite the fact an user will see its full definition, it won't be able to use it, nor use the private methods. So you'll usually be able to modify the enum and the content of the existing methods without needing recompiling of code using your class.
My guess would be either the solution 3 or 1.
To anyone facing this for iOS/Mac/Xcode,
If you are facing this while integrating C/C++ headers in XCode with Objective-C, just change the extension of your file from .mm to .m
Because the enum can be an integral size of varying size (the compiler decides which size a given enum has), the pointer to the enum can also have varying size, since it's an integral type (chars have pointers of a different size on some platforms for instance).
So the compiler can't even let you forward-declare the enum and user a pointer to it, because even there, it needs the size of the enum.
You define an enumeration to restrict the possible values of elements of the type to a limited set. This restriction is to be enforced at compile time.
When forward declaring the fact that you will use a 'limited set' later on doesn't add any value: subsequent code needs to know the possible values in order to benefit from it.
Although the compiler is concerned about the size of the enumerated type, the intent of the enumeration gets lost when you forward declare it.
This way we can forward declare enum
enum A : int;
please refer the link for details.