BUG: DEBUG member in enum in class syntax error C2059 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 
 [ 15 post ] 

 Relevant Pages 

1. help please error c2059 token error.

2. Debug vs Release enum bug..

3. Syntax problem: WSAAsyncSelect doesn't like callbacks that are members of a class

4. syntax error or compiler bug?

5. AFX_MSG_MAP contains unknown character syntax error (ms-bug?)

6. template bug or syntax error?

7. Problem upgrading from VC++ 6 to VC++.Net: error C2059: syntax error : 'empty declaration'

8. VC++5.0 Syntax Error in Template Class

9. VC7.1 - Error C2059 - pointer to array of structs

10. VisualC++.NET: errors C2144, C2660 & C2059

11. C++ Compiler error C2059

12. Crazy compiler : error C2059

 

 
Powered by phpBB® Forum Software