enum handling change in VS 2005

  • Thread starter Thread starter Craig Klementowski
  • Start date Start date
C

Craig Klementowski

All,

I've installed the VS 2005 Beta 1 and was trying to build our current
product. I get a compile error when enum value is specified with
classname::enumname::enumvalue. Seems the compiler does not want the
enumname there anymore. This was not a problem with any previous versions of
VS. I could not find any help in any of my programming books or in MSDN. Can
anyone explain the reasons to me? Is this behavior to stay?

class CMyEnumClass

{

public:

enum MyMode

{

MM_Mode1,

MM_Mode2,

MM_Mode3,

MM_Mode4

};

};

int _tmain(int argc, _TCHAR* argv[])

{

// CMyEnumClass::MyMode m = CMyEnumClass::MyMode::MM_Mode3;// in VS 2005 -
error C2825: 'CMyEnumClass::MyMode': must be a class or namespace when
followed by '::'

CMyEnumClass::MyMode m2 = CMyEnumClass::MM_Mode3;//ok in ALL

return 0;

}



Thanks!

Craig Klementowski
 
Actually, I never knew you could include the enum's name in the reference to
the enum, but it seems to be ok for vs2003. However, in my opinion, allowing
this would make the following case legal also, since you can differ which
"something" you want, like s::e1::something or s::e2::something.

struct s
{
enum e1 {something = 1};
enum e2 {something = 2};
};
 
The fact that the VC 7.1 compiler allowed this was a bug that we fixed for
the 2005 version. Enums are not scope qualified according to both the C and
C++ standards.

Ronald Laeremans
Visual C++ team
 
Thanks Ron. I'll get to cleaning up our code then.

Craig

Ronald Laeremans said:
The fact that the VC 7.1 compiler allowed this was a bug that we fixed for
the 2005 version. Enums are not scope qualified according to both the C and
C++ standards.

Ronald Laeremans
Visual C++ team

All,

I've installed the VS 2005 Beta 1 and was trying to build our current
product. I get a compile error when enum value is specified with
classname::enumname::enumvalue. Seems the compiler does not want the
enumname there anymore. This was not a problem with any previous versions
of
VS. I could not find any help in any of my programming books or in MSDN.
Can
anyone explain the reasons to me? Is this behavior to stay?

class CMyEnumClass

{

public:

enum MyMode

{

MM_Mode1,

MM_Mode2,

MM_Mode3,

MM_Mode4

};

};

int _tmain(int argc, _TCHAR* argv[])

{

// CMyEnumClass::MyMode m = CMyEnumClass::MyMode::MM_Mode3;// in VS 2005 -
error C2825: 'CMyEnumClass::MyMode': must be a class or namespace when
followed by '::'

CMyEnumClass::MyMode m2 = CMyEnumClass::MM_Mode3;//ok in ALL

return 0;

}



Thanks!

Craig Klementowski
Click to expand...
Click to expand...
 
Ronald Laeremans said:
The fact that the VC 7.1 compiler allowed this was a bug that we fixed for
the 2005 version. Enums are not scope qualified according to both the C and
C++ standards.

Ronald Laeremans
Visual C++ team
Click to expand...

Ron,

Given all the extensive language extensions provided as part of .NET,
I think it would be a very good idea to leave the enum scope
qualification as a language extension.

Not only does it make MC++ more similar to C#.NET, but it's simply a
good idea on its own regard. Lack of enum scoping frequently forces
name mutilation into the enum fields:

enum EColor
{
eColor_Red,
eColor_Blue,
}

This sucks in any case where you want to use the textual value of the
enum for printout purposes.

Finally, doesn't removing enum scope qualification in MC++ introduce
possibilities where MC++ will be unable to interact with enums defined
in C#.NET? Since C# supports enum scoping, it seems there could be
cases where duplicate enumerared values (potentially with different
meaning or numeric values) are defined in different enum types. C# can
handle this fine, but MC++ cannot?

Thanks,
-ken
 
Hi Ken,

enum class Foo {... } will act identical to an enum defined in C# or another
CLR language.
enum Foo { ... } will act as per the ANSI/ISO C and C++ standards.

If you want a non managed enum to behave the same it is fairly easy to write
a class in standard C++ that has the scoped behavior and use that instead.

Ronald
 
Yamake said:
If that's the case, people might as well use:

typedef unsigned int [enum_name];
const unsigned int [enum_values_0] = 0;
const unsigned int [enum_values_1] = 1;
// ... and so on ...
Click to expand...

That is what people do today to workaround the C++ limitations for enums.
This new enum stuff confuses me.
Click to expand...

You're not alone. Effectively, everyone is observing how enums are really
broken in C++. They are the way they are for compatibility with C. As with
most broken features in C++, compatibility with C is the culprit.

Interoperating with nearly every other language that has a better approach
to enums required us to introduce another kind of enum.
 
I have a DLL which exposes a class which has a function which returns
a enum defined inside the class. Does this mean that I will have to
pull the enum definition outside the class??

i.e.
------------(.H file)
class Temp
{
public:
enum RetCode
{
SUCCESS,
FAILURE
};

static RetCode CreateClass();
}
extern "C" Temp_API Temp::RetCode Temp_CreateClass();
------------(.CPP file)
extern "C" Temp_API Tesmp::RetCode Temp_CreateClass()
{
return Temp::RetCode::SUCCESS;
}

Now in VS2005 I get the error and if I remove the Temp::RetCode the
compiler does not recognize SUCCESS. No scope.

Thanks
Jeff
 
Jeffrey B. Holtz said:
I have a DLL which exposes a class which has a function which returns
a enum defined inside the class. Does this mean that I will have to
pull the enum definition outside the class??

i.e.
------------(.H file)
class Temp
{
public:
enum RetCode
{
SUCCESS,
FAILURE
};

static RetCode CreateClass();
}
extern "C" Temp_API Temp::RetCode Temp_CreateClass();
------------(.CPP file)
extern "C" Temp_API Tesmp::RetCode Temp_CreateClass()
{
return Temp::RetCode::SUCCESS;
}

Now in VS2005 I get the error and if I remove the Temp::RetCode the
compiler does not recognize SUCCESS. No scope.
Click to expand...

It should be just Temp::SUCCESS.

The RetCode isn't a part of the scope, but VC 6 & 7 didn't realize this.
This is a bug that has been fixed!

Bo Persson
 
Back
Top