🚀 go-pugleaf

In article <4fq7dc$pac@netlab.cs.rpi.edu>, 
P.v.Klaveren@bcs.cs.philips.com says...
>
>enum
>{
>   CSEQ_IDLE,
>   CSEQ_ERROR,
>   CSEQ_ABORT,
>   CSEQ_WAIT4RESPONSE
>};
>
>int state = 3;
>
>if (state == CSEQ_WAIT4RESPONSE)
>{
>    // this code is not executed!!!
>    ...
>}
>
>BOOL expr_is_valid = state == CSEQ_WAIT4RESPONSE;
>
>if (expr_is_valid)
>{
>    // this code IS executed!!!
>    ...
>}
>
>
>I know it is not recommended to compare integers with enumeration
>values, but why on earth is 'expr_is_valid' TRUE but seems
>'state == CSEQ_WAIT4RESPONSE' to result in FALSE (at least in a if
>expression calcuation)?
>

The code works fine on my C++ compiler (Visuall C++ 1.51).
i.e. both IF statments above get executed (as one would expect).

can you post a small complete example (with #include statments) that 
shows the problem? 

what compiler are you using? 

Nasser


      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

Peter van Klaveren (P.v.Klaveren@bcs.cs.philips.com) wrote:
: enum
: {
:    CSEQ_IDLE,
:    CSEQ_ERROR,
:    CSEQ_ABORT,
:    CSEQ_WAIT4RESPONSE
: };

: int state = 3;

: if (state == CSEQ_WAIT4RESPONSE)
: {
:     // this code is not executed!!!
:     ...
: }

   You're making the assumption that the compiler is numbering your enums
   sequentially from 0 - since the standard says nothing about how the
   compiler could number your enums it could very well be using 0x1, 0x2, 
   0x4, and 0x8.

: BOOL expr_is_valid = state == CSEQ_WAIT4RESPONSE;

: if (expr_is_valid)
: {
:     // this code IS executed!!!
:     ...
: }

: I know it is not recommended to compare integers with enumeration
: values, but why on earth is 'expr_is_valid' TRUE but seems
: 'state == CSEQ_WAIT4RESPONSE' to result in FALSE (at least in a if
: expression calcuation)?

   If I remember the leeway in the standard about enums was allowed so 
   the compiler could optimize enums in any fashion it choose (i.e. bit
   fields or char vs int)
{ If this is true this is a fairly obscure, important C incompatibility
  references anyone ? -mod}

: Anybody an idea?

: Peter.
:                                              \\\//
:                                             -(o o)-
: ==========================================ooO-(_)-Ooo======
: Peter van Klaveren, E-mail: P.v.Klaveren@bcs.cs.philips.com
: ===========================================================

:       [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
:       [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
:       [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
:       [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

--
CompuServ: 75511,65          "I don't know - I'm making this up as I go along." 
Internet: gstern@usa.net     Indiana Jones - Raiders of the Lost Ark

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

gstern@earth.usa.net (Greg Sternberg/PDS Inc) wrote:

> Peter van Klaveren (P.v.Klaveren@bcs.cs.philips.com) wrote:
> : enum
> : {
> :    CSEQ_IDLE,
> :    CSEQ_ERROR,
> :    CSEQ_ABORT,
> :    CSEQ_WAIT4RESPONSE
> : };
> 
> : int state = 3;
> 
> : if (state == CSEQ_WAIT4RESPONSE)
> : {
> :     // this code is not executed!!!
> :     ...
> : }
> 
>    You're making the assumption that the compiler is numbering your enums
>    sequentially from 0 - since the standard says nothing about how the
>    compiler could number your enums it could very well be using 0x1, 0x2, 
>    0x4, and 0x8.

From draft 7.2:

	The identifiers in an enumerator-list are declared as
	constants, and can  appear  wherever  constants  are  
	required.  If no enumerator-definitions with = appear, then
	the values of the corresponding constants begin at zero and
	increase by one as the enumerator-list is read from left to
	right.

The C standard (ISO 6.5.2.2) and ARM (7.2) also require this.


Michael M Rubenstein

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

gstern@earth.usa.net (Greg Sternberg/PDS Inc) writes:

>   You're making the assumption that the compiler is numbering your enums
>   sequentially from 0 - since the standard says nothing about how the
>   compiler could number your enums it could very well be using 0x1, 0x2, 
>   0x4, and 0x8.

It has always been the rule in C and C++ that if you do not supply
values for enumerators, they are numbered sequentially from zero.
You can find the rule in K&R1 (1978) and in the current draft
C++ standard (1996).
--
Steve Clamage, stephen.clamage@eng.sun.com

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

In article <4g1pj9$pqg@netlab.cs.rpi.edu>
gstern@earth.usa.net (Greg Sternberg/PDS Inc) writes:
>      You're making the assumption that the compiler is numbering your enums
>      sequentially from 0 - since the standard says nothing about how the
>      compiler could number your enums it could very well be using 0x1, 0x2, 
>      0x4, and 0x8.
>
>   { If this is true this is a fairly obscure, important C incompatibility
>     references anyone ? -mod}

No, of course it's not true. See [dcl.enum]. Enumerators start at zero
and go up by one.

      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]

gstern@earth.usa.net (Greg Sternberg/PDS Inc) wrote:

>Peter van Klaveren (P.v.Klaveren@bcs.cs.philips.com) wrote:
>: enum
>: {
>:    CSEQ_IDLE,
>:    CSEQ_ERROR,
>:    CSEQ_ABORT,
>:    CSEQ_WAIT4RESPONSE
>: };

>: int state = 3;

>: if (state == CSEQ_WAIT4RESPONSE)
>: {
>:     // this code is not executed!!!
>:     ...
>: }
IMO, the above is poor coding practice.
Enums have two uses, pick either one, but do not mix them:
Plan A (using enum to define constants):
  enum
  {
     CSEQ_IDLE = 0,
     CSEQ_ERROR = 1,
     CSEQ_ABORT = 2,
     CSEQ_WAIT4RESPONSE = 3
  };
should let you compare to ints

Plan B (using enum as an arbitrary set of codes):
  typedef enum
  {
     CSEQ_IDLE,
     CSEQ_ERROR,
     CSEQ_ABORT,
     CSEQ_WAIT4RESPONSE
  } States;

  States state = CSEQ_WAIT4RESPONSE;

  if (state == CSEQ_WAIT4RESPONSE) ...




      [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
      [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
      [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
      [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]