enum handling change in VS 2005

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

re: enum handling change in VS 2005

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};
};

re: enum handling change in VS 2005

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

"Craig Klementowski" <nospam.craigklem@nospam.hotmail.com> wrote in message
news:%23w61KvNcEHA.3716@TK2MSFTNGP11.phx.gbl...[color=blue]
> 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
>
>[/color]

re: enum handling change in VS 2005

Thanks Ron. I'll get to cleaning up our code then.

Craig

"Ronald Laeremans [MSFT]" <ronaldl@online.microsoft.com> wrote in message
news:e6YQtGQcEHA.1248@TK2MSFTNGP11.phx.gbl...[color=blue]
> 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[/color]
and[color=blue]
> C++ standards.
>
> Ronald Laeremans
> Visual C++ team
>
> "Craig Klementowski" <nospam.craigklem@nospam.hotmail.com> wrote in[/color]
message[color=blue]
> news:%23w61KvNcEHA.3716@TK2MSFTNGP11.phx.gbl...[color=green]
> > 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[/color][/color]
versions[color=blue][color=green]
> > 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[/color][/color]
2005 -[color=blue][color=green]
> > 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
> >
> >[/color]
>
>[/color]

re: enum handling change in VS 2005

"Ronald Laeremans [MSFT]" <ronaldl@online.microsoft.com> wrote in message news:<e6YQtGQcEHA.1248@TK2MSFTNGP11.phx.gbl>...[color=blue]
> 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
>[/color]

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

re: enum handling change in VS 2005

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

"Ken Durden" <creepiecrawlies@hotmail.com> wrote in message
news:18c6b284.0407280655.5d0b4227@posting.google.c om...[color=blue]
> "Ronald Laeremans [MSFT]" <ronaldl@online.microsoft.com> wrote in message
> news:<e6YQtGQcEHA.1248@TK2MSFTNGP11.phx.gbl>...[color=green]
>> 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
>>[/color]
>
> 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[/color]

re: enum handling change in VS 2005

Yamake Takahashi wrote:[color=blue]
> 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 ...[/color]

That is what people do today to workaround the C++ limitations for enums.
[color=blue]
> This new enum stuff confuses me.[/color]

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.

--
Brandon Bray, Visual C++ Compiler http://blogs.msdn.com/branbray/
This posting is provided AS IS with no warranties, and confers no rights.

re: enum handling change in VS 2005

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

re: enum handling change in VS 2005

"Jeffrey B. Holtz" <jholtz@accuratetechnologies.com> skrev i meddelandet
news:937be330.0408240628.3712737e@posting.google.c om...[color=blue]
> 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.[/color]

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

[color=blue]
>
> Thanks
> Jeff[/color]