BUG: DEBUG member in enum in class syntax error C2059
Author |
Message |
Austin David Franc #1 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
The following code compiles with a syntax error in VC.Net Beta 1 on the enum line but compiles fine under VC6 class CEventView : public CListViewEx { protected: CEventView(); // protected constructor used by dynamic creation DECLARE_DYNCREATE(CEventView) // Attributes public: // Operations public: enum Source { UNKNOWN = 0, ESP = 1, DEBUG = 2, WEB = 3, ANNOUNCE = 4 }; The error being reported is:- D:\Visual Studio.NET\RGTERM\1.0\EventView.h(26): error C2059: syntax error : '=' If I rename the DEBUG member, it works.
|
Mon, 09 Jun 2003 20:46:20 GMT |
|
 |
Ian Darlin #2 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
Quote: > The following code compiles with a syntax error in VC.NET Beta 1 on the enum > line but compiles fine under VC6 > class CEventView : public CListViewEx > { > protected: > CEventView(); // protected constructor used by dynamic > creation > DECLARE_DYNCREATE(CEventView) > // Attributes > public: > // Operations > public: > enum Source { UNKNOWN = 0, ESP = 1, DEBUG = 2, WEB = 3, ANNOUNCE = > 4 }; > The error being reported is:- > D:\Visual Studio.NET\RGTERM\1.0\EventView.h(26): error C2059: syntax > error : '=' > If I rename the DEBUG member, it works.
DEBUG is probably #define'd somewhere in one of the headers - and if it is defined as: #define DEBUG then the preprocessed source will go to the compiler looking like: enum Source { UNKNOWN = 0, ESP = 1, = 2, WEB = 3, ANNOUNCE = 4 }; Hence the syntax error. Try not using identifiers that might already be used globally (especially preprocessor stuff). DEBUG and it's variants _DEBUG, _DEBUG_, etc, are fairly commonly used, so it's best to avoid them if possible. -- Ian Darling
|
Mon, 09 Jun 2003 21:24:43 GMT |
|
 |
Austin David Franc #3 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
I hade already guessed that was be the problem, however the point is this worked in VS6 and therefore there is a change to the headers that is going to break allot of code out there (potentially). Your suggestion of "Try not using identifiers that might already be used globally ..." is not practical because "any" identifier I choose may in the future be put into a header and cause my code to fail. Where does one draw the line? The fault I believe lies with the header (or whatever) defining a macro DEBUG, this should have been named more carefully. Does the ANSI standard not stipulate that all non-ANSI definitions should use the _ prefix to avoid future clashes? Perhaps this is an ANSI standard macro, in which case I loose. I can work around the error by adding a #undef DEBUG. I accept that DEBUG was probably the worst name I could have chosen (for potential conflicts), although it is the one that has most meaning (is most sensible) in the context in which it is used.
Quote:
> > The following code compiles with a syntax error in VC.NET Beta 1 on the > enum > > line but compiles fine under VC6 > > class CEventView : public CListViewEx > > { > > protected: > > CEventView(); // protected constructor used by dynamic > > creation > > DECLARE_DYNCREATE(CEventView) > > // Attributes > > public: > > // Operations > > public: > > enum Source { UNKNOWN = 0, ESP = 1, DEBUG = 2, WEB = 3, ANNOUNCE = > > 4 }; > > The error being reported is:- > > D:\Visual Studio.NET\RGTERM\1.0\EventView.h(26): error C2059: syntax > > error : '=' > > If I rename the DEBUG member, it works. > DEBUG is probably #define'd somewhere in one of the headers - and if it is > defined as: > #define DEBUG > then the preprocessed source will go to the compiler looking like: > enum Source { UNKNOWN = 0, ESP = 1, = 2, WEB = 3, ANNOUNCE = 4 }; > Hence the syntax error. > Try not using identifiers that might already be used globally (especially > preprocessor stuff). DEBUG and it's variants _DEBUG, _DEBUG_, etc, are > fairly commonly used, so it's best to avoid them if possible. > -- > Ian Darling
|
Mon, 09 Jun 2003 22:16:48 GMT |
|
 |
Hurcan Gokce Solte #4 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
Quote: > I hade already guessed that was be the problem, however the point is this > worked in VS6 and therefore there is a change to the headers that is going > to break allot of code out there (potentially). > Your suggestion of "Try not using identifiers that might already be used > globally ..." is not practical because "any" identifier I choose may in the > future be put into a header and cause my code to fail. Where does one draw > the line?
You may try not using all CAPITALIZED letters for your enums and if you use proper class scoping , there is less likely to be a collision with MACROs or with other Enums.
|
Mon, 09 Jun 2003 22:56:20 GMT |
|
 |
Ian Darlin #5 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
Quote: > I hade already guessed that was be the problem, however the point is this > worked in VS6 and therefore there is a change to the headers that is going > to break allot of code out there (potentially). > Your suggestion of "Try not using identifiers that might already be used > globally ..." is not practical because "any" identifier I choose may in the > future be put into a header and cause my code to fail. Where does one draw > the line?
Well, I would suggest not using uppercase names for anything outside of the preprocessor - that way you reduce the number of potential conflicts considerably, and some preprocessors pick up if you try and redefine a macro definition without undefing it first: Uder VC6, you can do: #define FRED #define FRED without a problem, but: #define FRED 1 #define FRED 2 Crops up error C4005. I personally would have defined that enum as: enum source { unknown = 0, esp = 1, debug = 2, web = 3, announce = 4 }; Add capitalisation to taste. That way, debug can be kept as debug, as it will never conflict with any vaguely sensible preprocessor macro, as the whole thing is case-sensitive anyway. The convention that only preprocessor macros should be entirely uppercase makes it a bit more obvious that something is a macro, rather than an actual C/C++ construct. Quote: > The fault I believe lies with the header (or whatever) defining a macro > DEBUG, this should have been named more carefully.
Well, it probably should have stayed as _DEBUG (which seems to be what Microsoft tend to use). Bear in mind this is still Beta 1 - so it may change back anyway. Quote: > Does the ANSI standard not stipulate that all non-ANSI definitions should > use the _ prefix to avoid future clashes? Perhaps this is an ANSI standard > macro, in which case I loose.
Not sure about that, although DEBUG is probably fairly common - so I would suggest it's more of a de-facto standard than a de-jure one. Quote: > I can work around the error by adding a #undef DEBUG.
That's far from a perfect solution, as other headers later on may (try to) define it back again, and so you may end up with all sorts of compiler errors. -- Ian Darling
|
Mon, 09 Jun 2003 23:06:20 GMT |
|
 |
Chris Nas #6 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
It's best to follow the convention that all upper case symbols only used for preprocessor symbols. It avoids this problem when a new #define is added to a header you are using. -- Chris Nash Taskforce Software Ltd Quote:
> Subject: Re: DEBUG member in enum in class syntax error C2059 > Date: Thu, 21 Dec 2000 13:24:43 -0000 > Lines: 45 > Organization: Blass PLC > X-Priority: 3 > X-MSMail-Priority: Normal > X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
> Newsgroups: microsoft.public.dotnet.languages.vc > NNTP-Posting-Host: 212.125.69.106 > Path: tkmsftngp01!tkmsftngp05 > Xref: tkmsftngp01 microsoft.public.dotnet.languages.vc:695
> > The following code compiles with a syntax error in VC.NET Beta 1 on the > enum > > line but compiles fine under VC6 > > class CEventView : public CListViewEx > > { > > protected: > > CEventView(); // protected constructor used by dynamic > > creation > > DECLARE_DYNCREATE(CEventView) > > // Attributes > > public: > > // Operations > > public: > > enum Source { UNKNOWN = 0, ESP = 1, DEBUG = 2, WEB = 3, ANNOUNCE = > > 4 }; > > The error being reported is:- > > D:\Visual Studio.NET\RGTERM\1.0\EventView.h(26): error C2059: syntax > > error : '=' > > If I rename the DEBUG member, it works. > DEBUG is probably #define'd somewhere in one of the headers - and if it is > defined as: > #define DEBUG > then the preprocessed source will go to the compiler looking like: > enum Source { UNKNOWN = 0, ESP = 1, = 2, WEB = 3, ANNOUNCE = 4 }; > Hence the syntax error. > Try not using identifiers that might already be used globally (especially > preprocessor stuff). DEBUG and it's variants _DEBUG, _DEBUG_, etc, are > fairly commonly used, so it's best to avoid them if possible. > -- > Ian Darling
|
Mon, 09 Jun 2003 23:24:19 GMT |
|
 |
Austin David Franc #7 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
Hello Hurcan Quote: > You may try not using all CAPITALIZED letters for your enums and if you > use proper class scoping , > there is less likely to be a collision with MACROs or with other Enums.
I think not using capitals would be a sensible suggestion, and indeed I normally follow that rule. I felt at the time that using capitals was sensible as an ENUM is a bit like a MANIFEST, but accept the increased potential of risk of clash. Not sure what you mean by using proper class scoping, perhaps you could elaborate with an example. Cheers ()z
|
Tue, 10 Jun 2003 00:23:33 GMT |
|
 |
Austin David Franc #8 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
Hello Hurcan Quote: > You may try not using all CAPITALIZED letters for your enums and if you > use proper class scoping , > there is less likely to be a collision with MACROs or with other Enums.
I think not using capitals would be a sensible suggestion, and indeed I normally follow that rule. I felt at the time that using capitals was sensible as an ENUM is a bit like a MANIFEST, but accept the increased potential of risk of clash. Not sure what you mean by using proper class scoping, perhaps you could elaborate with an example. Cheers ()z
|
Tue, 10 Jun 2003 00:23:19 GMT |
|
 |
Austin David Franc #9 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
Hello Hurcan Quote: > You may try not using all CAPITALIZED letters for your enums and if you > use proper class scoping , > there is less likely to be a collision with MACROs or with other Enums.
I think not using capitals would be a sensible suggestion, and indeed I normally follow that rule. I felt at the time that using capitals was sensible as an ENUM is a bit like a MANIFEST, but accept the increased potential of risk of clash. Not sure what you mean by using proper class scoping, perhaps you could elaborate with an example. Cheers ()z
|
Tue, 10 Jun 2003 00:22:58 GMT |
|
 |
Austin David Franc #10 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
Hello Hurcan Quote: > You may try not using all CAPITALIZED letters for your enums and if you > use proper class scoping , > there is less likely to be a collision with MACROs or with other Enums.
I agree that avoiding use of all capitals would be a sensible standardisation, the thought was that an ENUM being used in situations where traditionally a MANIFEST would be used, that using UPPERCASE made sense. I can accept that I increase the risk of symbol/macro clashes and so will revise this code and my thinking. I am not sure what you mean when you say I should use proper class scoping, perhaps you could elaborate with an example. Cheers ()z
|
Tue, 10 Jun 2003 00:27:13 GMT |
|
 |
Austin David Franc #11 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
Hi Ian Quote: > Well, I would suggest not using uppercase names for anything outside of the > preprocessor - that way you reduce the number of potential conflicts > considerably, and some preprocessors pick up if you try and redefine a macro > definition without undefing it first:
Agreed. Sensible suggestion, I will revise my coding style. Quote: > Uder VC6, you can do: > #define FRED > #define FRED > without a problem, but: > #define FRED 1 > #define FRED 2 > Crops up error C4005.
This is not the issue here though is it. It's a clash between a macro and an ENUM. [snip] Quote: > > The fault I believe lies with the header (or whatever) defining a macro > > DEBUG, this should have been named more carefully. > Well, it probably should have stayed as _DEBUG (which seems to be what > Microsoft tend to use). Bear in mind this is still Beta 1 - so it may > change back anyway.
This is the root cause of my problem - moving goal posts. I think this should be corrected, unless there is a v.good reason for the change. [snip] Quote: > > I can work around the error by adding a #undef DEBUG. > That's far from a perfect solution, as other headers later on may (try to) > define it back again, and so you may end up with all sorts of compiler > errors.
Agreed - it was a quick solution so that I could move on an see what other migration issues I may encounter. IMHO - The "best" solution is the not using all upper case. The "correct" solution is MS putting it back as it was. Therefore I suggest that both solutions should be implemented. Cheers
|
Tue, 10 Jun 2003 00:32:45 GMT |
|
 |
Austin David Franc #12 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
Hi Chris Agreed - General consensus seems to be to avoid all upper case for all non-pre-processor code. A rule I generally use anyway (C on Unix), but decided to stray in this case - doh!
Quote: > It's best to follow the convention that all upper case symbols only used for > preprocessor symbols. It avoids this problem when a new #define is added to a > header you are using. > -- > Chris Nash > Taskforce Software Ltd
> > Subject: Re: DEBUG member in enum in class syntax error C2059 > > Date: Thu, 21 Dec 2000 13:24:43 -0000 > > Lines: 45 > > Organization: Blass PLC > > X-Priority: 3 > > X-MSMail-Priority: Normal > > X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 > > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
> > Newsgroups: microsoft.public.dotnet.languages.vc > > NNTP-Posting-Host: 212.125.69.106 > > Path: tkmsftngp01!tkmsftngp05 > > Xref: tkmsftngp01 microsoft.public.dotnet.languages.vc:695
message
> > > The following code compiles with a syntax error in VC.NET Beta 1 on the > > enum > > > line but compiles fine under VC6 > > > class CEventView : public CListViewEx > > > { > > > protected: > > > CEventView(); // protected constructor used by dynamic > > > creation > > > DECLARE_DYNCREATE(CEventView) > > > // Attributes > > > public: > > > // Operations > > > public: > > > enum Source { UNKNOWN = 0, ESP = 1, DEBUG = 2, WEB = 3, ANNOUNCE = > > > 4 }; > > > The error being reported is:- > > > D:\Visual Studio.NET\RGTERM\1.0\EventView.h(26): error C2059: syntax > > > error : '=' > > > If I rename the DEBUG member, it works. > > DEBUG is probably #define'd somewhere in one of the headers - and if it is > > defined as: > > #define DEBUG > > then the preprocessed source will go to the compiler looking like: > > enum Source { UNKNOWN = 0, ESP = 1, = 2, WEB = 3, ANNOUNCE = 4 }; > > Hence the syntax error. > > Try not using identifiers that might already be used globally (especially > > preprocessor stuff). DEBUG and it's variants _DEBUG, _DEBUG_, etc, are > > fairly commonly used, so it's best to avoid them if possible. > > -- > > Ian Darling
|
Tue, 10 Jun 2003 00:40:51 GMT |
|
 |
Jonathan Caves [MSFT #13 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
The underlying problem (leaving aside macro naming conventions) seems to be due to the definition of a DEBUG macro in atldef.h - I'll get in touch with the ATL team and I'll try to find out why they added this macro without a leading underscore as the lactk of an underscore definitely puts the macro name in the user "namespace" and not in the reserved implementor "namespace". Jonathan Caves
Quote: > Hi Chris > Agreed - General consensus seems to be to avoid all upper case for all > non-pre-processor code. A rule I generally use anyway (C on Unix), but > decided to stray in this case - doh!
> > It's best to follow the convention that all upper case symbols only used > for > > preprocessor symbols. It avoids this problem when a new #define is added > to a > > header you are using. > > -- > > Chris Nash > > Taskforce Software Ltd
> > > Subject: Re: DEBUG member in enum in class syntax error C2059 > > > Date: Thu, 21 Dec 2000 13:24:43 -0000 > > > Lines: 45 > > > Organization: Blass PLC > > > X-Priority: 3 > > > X-MSMail-Priority: Normal > > > X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 > > > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
> > > Newsgroups: microsoft.public.dotnet.languages.vc > > > NNTP-Posting-Host: 212.125.69.106 > > > Path: tkmsftngp01!tkmsftngp05 > > > Xref: tkmsftngp01 microsoft.public.dotnet.languages.vc:695
> message
> > > > The following code compiles with a syntax error in VC.NET Beta 1 on > the > > > enum > > > > line but compiles fine under VC6 > > > > class CEventView : public CListViewEx > > > > { > > > > protected: > > > > CEventView(); // protected constructor used by dynamic > > > > creation > > > > DECLARE_DYNCREATE(CEventView) > > > > // Attributes > > > > public: > > > > // Operations > > > > public: > > > > enum Source { UNKNOWN = 0, ESP = 1, DEBUG = 2, WEB = 3, > ANNOUNCE = > > > > 4 }; > > > > The error being reported is:- > > > > D:\Visual Studio.NET\RGTERM\1.0\EventView.h(26): error C2059: > syntax > > > > error : '=' > > > > If I rename the DEBUG member, it works. > > > DEBUG is probably #define'd somewhere in one of the headers - and if it > is > > > defined as: > > > #define DEBUG > > > then the preprocessed source will go to the compiler looking like: > > > enum Source { UNKNOWN = 0, ESP = 1, = 2, WEB = 3, ANNOUNCE = 4 }; > > > Hence the syntax error. > > > Try not using identifiers that might already be used globally > (especially > > > preprocessor stuff). DEBUG and it's variants _DEBUG, _DEBUG_, etc, are > > > fairly commonly used, so it's best to avoid them if possible. > > > -- > > > Ian Darling
|
Tue, 10 Jun 2003 01:53:06 GMT |
|
 |
Austin David Franc #14 / 15
|
 BUG: DEBUG member in enum in class syntax error C2059
Hi Jonathan This was the reason for the post, not to get a workaround but to highlight the problem. I am basically doing an early migration test for our VC6 projects. I have started with a small project and found several issues - not surprising being Beta 1 Thanx for recognising the real issue - lets hope there is no good reason for the change and that it is put back as _DEBUG, then we don't have to go around modifying all our code when we move to VC7. I still agree with the other suggestions that reserving all uppercase names for macro's is a good convention to use. Regards
Quote: > The underlying problem (leaving aside macro naming conventions) seems to be > due to the definition of a DEBUG macro in atldef.h - I'll get in touch with > the ATL team and I'll try to find out why they added this macro without a > leading underscore as the lactk of an underscore definitely puts the macro > name in the user "namespace" and not in the reserved implementor > "namespace". > Jonathan Caves
> > Hi Chris > > Agreed - General consensus seems to be to avoid all upper case for all > > non-pre-processor code. A rule I generally use anyway (C on Unix), but > > decided to stray in this case - doh!
> > > It's best to follow the convention that all upper case symbols only used > > for > > > preprocessor symbols. It avoids this problem when a new #define is added > > to a > > > header you are using. > > > -- > > > Chris Nash > > > Taskforce Software Ltd
> > > > Subject: Re: DEBUG member in enum in class syntax error C2059 > > > > Date: Thu, 21 Dec 2000 13:24:43 -0000 > > > > Lines: 45 > > > > Organization: Blass PLC > > > > X-Priority: 3 > > > > X-MSMail-Priority: Normal > > > > X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 > > > > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
> > > > Newsgroups: microsoft.public.dotnet.languages.vc > > > > NNTP-Posting-Host: 212.125.69.106 > > > > Path: tkmsftngp01!tkmsftngp05 > > > > Xref: tkmsftngp01 microsoft.public.dotnet.languages.vc:695
> > message
> > > > > The following code compiles with a syntax error in VC.NET Beta 1 on > > the > > > > enum > > > > > line but compiles fine under VC6 > > > > > class CEventView : public CListViewEx > > > > > { > > > > > protected: > > > > > CEventView(); // protected constructor used by > dynamic > > > > > creation > > > > > DECLARE_DYNCREATE(CEventView) > > > > > // Attributes > > > > > public: > > > > > // Operations > > > > > public: > > > > > enum Source { UNKNOWN = 0, ESP = 1, DEBUG = 2, WEB = 3, > > ANNOUNCE = > > > > > 4 }; > > > > > The error being reported is:- > > > > > D:\Visual Studio.NET\RGTERM\1.0\EventView.h(26): error C2059: > > syntax > > > > > error : '=' > > > > > If I rename the DEBUG member, it works. > > > > DEBUG is probably #define'd somewhere in one of the headers - and if > it > > is > > > > defined as: > > > > #define DEBUG > > > > then the preprocessed source will go to the compiler looking like: > > > > enum Source { UNKNOWN = 0, ESP = 1, = 2, WEB = 3, ANNOUNCE = 4 }; > > > > Hence the syntax error. > > > > Try not using identifiers that might already be used globally > > (especially > > > > preprocessor stuff). DEBUG and it's variants _DEBUG, _DEBUG_, etc, > are > > > > fairly commonly used, so it's best to avoid them if possible. > > > > -- > > > > Ian Darling
|
Tue, 10 Jun 2003 03:58:34 GMT |
|
|
|