www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - bit-level logic operations on enums

reply d coder <dlang.coder gmail.com> writes:
--0015175d67aa1d155304d6dc8b43
Content-Type: text/plain; charset=ISO-8859-1

Greetings

Currently DMD allows me to bit-or two enum variables, but not bit-and. For
example in the following code, DMD is OK with line 6, but gives an error
for line 9. I do not see any logic why DMD does that. Is it a bug or is it
intended.

BTW if I declare all a,b,c and d as "enum BING_e", then DMD gives errors
for both line 6 and 9.

Regards
- Puneet


enum BING_e: byte {NONE_BING = 0b00, FOO_BING = 0b01, // 1
    BAR_BING = 0b10, BOTH_BING = 0b11}                // 2
void main() {                                         // 3
  BING_e a = BING_e.FOO_BING;                         // 4
  BING_e b = BING_e.BAR_BING;                         // 5
  BING_e c = a | b;                                   // 6
  import std.stdio;                                   // 7
  writeln(c);                                         // 8
  BING_e d = a & b;                                   // 9
  import std.stdio;                                   // 10
  writeln(d);                                         // 11
}                                                     // 12

--0015175d67aa1d155304d6dc8b43
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><font face=3D"courier new, monospace">Greetings</font></div><div><font=
 face=3D"courier new, monospace"><br></font></div><div><font face=3D"courie=
r new, monospace">Currently DMD allows me to bit-or two enum variables, but=
 not bit-and. For example in the following code, DMD is OK with line 6, but=
 gives an error for line 9. I do not see any logic why DMD does that. Is it=
 a bug or is it intended.</font></div>

<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">BTW if I declare all a,b,c and d as &quot;enum =
BING_e&quot;, then DMD gives errors for both line 6 and 9.</font></div><div=

<font face=3D"courier new, monospace"><br></font></div><div><font face=3D"c= ourier new, monospace">Regards</font></div><div><font face=3D"courier new, = monospace">- Puneet</font></div><font face=3D"courier new, monospace"><div>= <font face=3D"courier new, monospace"><br> </font></div><div><font face=3D"courier new, monospace"><br></font></div>en= um BING_e: byte {NONE_BING =3D 0b00, FOO_BING =3D 0b01, // 1<br>=A0 =A0 BAR= _BING =3D 0b10, BOTH_BING =3D 0b11} =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// 2<br>= void main() { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 // 3<br> =A0 BING_e a =3D BING_e.FOO_BING; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 // 4<br>=A0 BING_e b =3D BING_e.BAR_BING; =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 // 5<br>=A0 BING_e c =3D a | b; =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // 6<br>=A0 import std.std= io; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // = 7<br> =A0 writeln(c); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 // 8<br>=A0 BING_e d =3D a &amp; b; =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // 9<br>=A0 import std.= stdio; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = // 10<br>=A0 writeln(d); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // 11<br> } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 // 12</font><br> --0015175d67aa1d155304d6dc8b43--
Mar 01 2013
next sibling parent FG <home fgda.pl> writes:
On 2013-03-01 13:56, d coder wrote:
 Currently DMD allows me to bit-or two enum variables, but not bit-and. For
 example in the following code, DMD is OK with line 6, but gives an error
 for line 9. I do not see any logic why DMD does that. Is it a bug or is it
 intended.

Strange. | and ^ work but & fails. The promotion from byte to int is unnecessary in any of those 3 ops. It works correctly for non-enums: byte x, y, z = 1; z = x | y; z = x ^ y; z = x & y; z = x >> y; // all OK z = x << y; z = x + y; z = x * y; z = x / y; // can't convert int to byte Not sure why byte enum would be handled any differently than simple byte.
Mar 01 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Friday, 1 March 2013 at 12:57:14 UTC, d coder wrote:
 Greetings

 Currently DMD allows me to bit-or two enum variables, but not 
 bit-and. For example in the following code, DMD is OK with line 
 6, but gives an error for line 9. I do not see any logic why 
 DMD does that. Is it a bug or is it intended.

 BTW if I declare all a,b,c and d as "enum BING_e", then DMD 
 gives errors for both line 6 and 9.

 enum BING_e: byte {NONE_BING = 0b00, FOO_BING = 0b01, // 1
     BAR_BING = 0b10, BOTH_BING = 0b11}                // 2
 void main() {                                         // 3
   BING_e a = BING_e.FOO_BING;                         // 4
   BING_e b = BING_e.BAR_BING;                         // 5
   BING_e c = a | b;                                   // 6
   import std.stdio;                                   // 7
   writeln(c);                                         // 8
   BING_e d = a & b;                                   // 9
   import std.stdio;                                   // 10
   writeln(d);                                         // 11
 }                                                     // 12

To do the binary operators it converts the flags to numbers, however you have to cast it for it to become a enum again, however this is unsafe as you could accidentally hold a value that has no name; //with your code BING_e c = cast(BING_e) (a | 0x10); //suppose to be 0b10 If you want to work with flags I have a implementation that I think is very good and simple. Note: If you have a flag that covers multiple bits like BOTH_BING, it must match ALL the bits to qualify. https://github.com/rtcvb32/Side-Projects/blob/master/flags.d
Mar 01 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Friday, 1 March 2013 at 13:41:27 UTC, Era Scarecrow wrote:
  To do the binary operators it converts the flags to numbers,

s/flags/enum(s)
Mar 01 2013
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 01 Mar 2013 07:56:21 -0500, d coder <dlang.coder gmail.com> wrote:

 Greetings

 Currently DMD allows me to bit-or two enum variables, but not bit-and.  
 For
 example in the following code, DMD is OK with line 6, but gives an error
 for line 9. I do not see any logic why DMD does that. Is it a bug or is  
 it
 intended.

It is a bug that line 6 is not an error: BING_e c = a | b; // OK (bug!) writeln(typeof(a | b).stringof); // int BING_e c2 = 0b11; // ERROR, cannot assign int value to enum BING_e (should be the message for 2 lines above as well) D does not (or at least should not) allow assignments of integers back to enumeration types. You have to cast. Any time an enumeration is involved in a math operation, it becomes an integer (as my code shows). The "correct" way to do this is not to store the result of an operation with flags as an enum, but rather as a uint (or ushort or ubyte). Then check flags using the enum. In other words, c and d in your code should be ubytes, not BING_e. The largest drawback to this approach is that typechecking for enums is gone when calling functions -- your function has to take a uint, not the enum, and random bits, other enum bits, etc can be passed in. Of course, technically, this is possible anyway, and often times certain flag sets are invalid. Impossible for the compiler to verify these things for you, you might want to use an in clause for the function to verify the bitset is correct. -Steve
Mar 01 2013
parent reply FG <home fgda.pl> writes:
On 2013-03-01 20:13, Steven Schveighoffer wrote:
 D does not (or at least should not) allow assignments of integers back to
 enumeration types.  You have to cast.

or use normal int enum instead of byte enum, if you have the space for it.
Mar 01 2013
parent FG <home fgda.pl> writes:
On 2013-03-01 20:56, Steven Schveighoffer wrote:
 or use normal int enum instead of byte enum, if you have the space for it.

It still fails if int is the enum base. The issue is not whether the bit pattern will fit in the base type, the issue is assigning an enum from int.

What fails? Are we talking something compiler-version-specific here? enum BING_e { ... } ... // rest the same as in original post BING_e c = a & b; // this works for me BING_e d = a & 1; // fails, and it should fail
Mar 01 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 01 Mar 2013 08:38:53 -0500, FG <home fgda.pl> wrote:

 Not sure why byte enum would be handled any differently than simple byte.

An enum is guaranteed by the compiler to be one of the specified values. The simple accounting kept by the compiler to prove whether one type will fit in another doesn't include enums, that is just prohibited, even if it seems like it should result in a valid enum value. -Steve
Mar 01 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 01 Mar 2013 14:32:11 -0500, FG <home fgda.pl> wrote:

 On 2013-03-01 20:13, Steven Schveighoffer wrote:
 D does not (or at least should not) allow assignments of integers back  
 to
 enumeration types.  You have to cast.

or use normal int enum instead of byte enum, if you have the space for it.

It still fails if int is the enum base. The issue is not whether the bit pattern will fit in the base type, the issue is assigning an enum from int. -Steve
Mar 01 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 01 Mar 2013 15:33:32 -0500, FG <home fgda.pl> wrote:

 On 2013-03-01 20:56, Steven Schveighoffer wrote:
 or use normal int enum instead of byte enum, if you have the space for  
 it.

It still fails if int is the enum base. The issue is not whether the bit pattern will fit in the base type, the issue is assigning an enum from int.

What fails? Are we talking something compiler-version-specific here? enum BING_e { ... } ... // rest the same as in original post BING_e c = a & b; // this works for me BING_e d = a & 1; // fails, and it should fail

My test code was incorrect. I had commented out the line that assigned c, and replaced with an assignment to an int (to test something else). In fact, any math on two or more enums is assignable back to an enum (for int or larger). I don't understand why this should be valid for int, but not for any other type. These make no sense, even in terms of bitfield flags, but the compiler accepts them: a << b; a * b; According to the spec, enums are integer promoted based on their base-type. But int isn't promoted, so apparently that enum is left alone. Then, when determining the type of an enum operation, if the two operands are of the same enum type (meaning, they haven't gone through any integer promotion), the result is the same enum type. So this unintuitively results in: enum A : int { a } enum B : byte { b } A a; B b; writeln(typeof(a | a).stringof); // => A writeln(typeof(b | b).stringof); // => int (byte is promoted to int) writeln(typeof(a | b).stringof); // => int writeln(typeof(a | 1).stringof); // => int writeln(typeof(b | 1).stringof); // => int So I guess it works according to the spec, but the spec makes no sense to me. I don't understand why int or uint (or larger) can be used as bitfields, but smaller types cannot. Nor do I understand why arbitrary math operations between enums are valid (can't think of a use case), while arbitrary math between enum and int is not. I would push for one of 4 behaviors, which make some sense to me: 1. Math operations between two enum values of the same type ALWAYS result in the same enum type regardless of base type (like int-based enums) 2. Math operations between two enum values of the same type ALWAYS result in the base type (full-scale enforcement of "enum only contains values from the identified list") 3. Operations between two enums or between an enum and an int, that result at compile-time in a valid member of the enum result in the enum type. Otherwise, the operation is converted to the base type. 4. Enums can be assigned any value from its base type, or any value implicitly convertible to that base type. As it stands now, the compiler makes a half-assed attempt to prevent invalid enum values, but fails miserably in some cases, and is overzealous in others, which is in fact worse than either one alone! At this point, you can't say anything about enums that is always valid except the manifest-constant usage of them. TDPL is puzzlingly silent on enum math. -Steve
Mar 01 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Friday, 1 March 2013 at 21:27:25 UTC, Steven Schveighoffer 
wrote:
 Then, when determining the type of an enum operation, if the 
 two operands are of the same enum type (meaning, they haven't 
 gone through any integer promotion), the result is the same 
 enum type.

 So this unintuitively results in:

 enum A : int { a }
 enum B : byte { b }

 A a;
 B b;
 writeln(typeof(a | a).stringof); // => A
 writeln(typeof(b | b).stringof); // => int (byte is promoted to 
 int)
 writeln(typeof(a | b).stringof); // => int
 writeln(typeof(a | 1).stringof); // => int
 writeln(typeof(b | 1).stringof); // => int

The only way the first makes sense is the compiler knows that it's the same value and is a no-op, thereby doesn't lose it's enum state; At which case b|b should do the same thing. However I'm quite sure the following is true, as otherwise it wouldn't make sense (Unless it knows the enum can only ever be 0 and doesn't matter?) writeln(typeof(a | A.a).stringof); // => int writeln(typeof(A.a | a).stringof); // => int
 I would push for one of 4 behaviors, which make some sense to 
 me:

 1. Math operations between two enum values of the same type 
 ALWAYS result in the same enum type regardless of base type 
 (like int-based enums)

Isn't this the same (or close enough) as 4?
 2. Math operations between two enum values of the same type 
 ALWAYS result in the base type (full-scale enforcement of "enum 
 only contains values from the identified list")

 3. Operations between two enums or between an enum and an int, 
 that result at compile-time in a valid member of the enum 
 result in the enum type.  Otherwise, the operation is converted 
 to the base type.

It might be okay to do it against compile-time known values as it can then confirm if the value is even possible, but this seems inconsistent, and can then break code if the enums values change.
 4. Enums can be assigned any value from its base type, or any 
 value implicitly convertible to that base type.

Then 'final switch' won't work, nor could you know if the value was valid at any point and enums would be easy to abuse.
 As it stands now, the compiler makes a half-assed attempt to 
 prevent invalid enum values, but fails miserably in some cases, 
 and is overzealous in others, which is in fact worse than 
 either one alone!  At this point, you can't say anything about 
 enums that is always valid except the manifest-constant usage 
 of them.

 TDPL is puzzlingly silent on enum math.

Regardless it should likely be consistent with how it handles math and binary operators and enums.
Mar 01 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 01 Mar 2013 17:24:22 -0500, Era Scarecrow <rtcvb32 yahoo.com>  
wrote:

 On Friday, 1 March 2013 at 21:27:25 UTC, Steven Schveighoffer wrote:
 Then, when determining the type of an enum operation, if the two  
 operands are of the same enum type (meaning, they haven't gone through  
 any integer promotion), the result is the same enum type.

 So this unintuitively results in:

 enum A : int { a }
 enum B : byte { b }

 A a;
 B b;
 writeln(typeof(a | a).stringof); // => A
 writeln(typeof(b | b).stringof); // => int (byte is promoted to int)
 writeln(typeof(a | b).stringof); // => int
 writeln(typeof(a | 1).stringof); // => int
 writeln(typeof(b | 1).stringof); // => int

The only way the first makes sense is the compiler knows that it's the same value and is a no-op, thereby doesn't lose it's enum state; At which case b|b should do the same thing. However I'm quite sure the following is true, as otherwise it wouldn't make sense (Unless it knows the enum can only ever be 0 and doesn't matter?) writeln(typeof(a | A.a).stringof); // => int writeln(typeof(A.a | a).stringof); // => int

I was sure too. It's not. Any operation between A types results in A. writeln(typeof(a + a).stringof); // => A writeln(typeof(a << a).stringof); // => A writeln(typeof(a * a).stringof); // => A
 I would push for one of 4 behaviors, which make some sense to me:

 1. Math operations between two enum values of the same type ALWAYS  
 result in the same enum type regardless of base type (like int-based  
 enums)

Isn't this the same (or close enough) as 4?

It would make math between enums and integers type as integers, which would then not be assignable back to the enum. In fact, this is exactly how it works for ints. Not so for smaller types. I'm just going for consistency.
 2. Math operations between two enum values of the same type ALWAYS  
 result in the base type (full-scale enforcement of "enum only contains  
 values from the identified list")

 3. Operations between two enums or between an enum and an int, that  
 result at compile-time in a valid member of the enum result in the enum  
 type.  Otherwise, the operation is converted to the base type.

It might be okay to do it against compile-time known values as it can then confirm if the value is even possible, but this seems inconsistent, and can then break code if the enums values change.

I'm ok with breaking code if the result is a more consistent enum feature.
 4. Enums can be assigned any value from its base type, or any value  
 implicitly convertible to that base type.

Then 'final switch' won't work, nor could you know if the value was valid at any point and enums would be easy to abuse.

You can already do this. See above. -Steve
Mar 01 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 01 Mar 2013 18:00:57 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 I was sure too.  It's not.  Any operation between A types results in A.

 writeln(typeof(a + a).stringof); // => A
 writeln(typeof(a << a).stringof); // => A
 writeln(typeof(a * a).stringof); // => A

I should add that in my test code (not the code posted previously), A is defined as: enum A { a = 2 } So the zero theory is out. All those result in a non-member value. -Steve
Mar 01 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Friday, 1 March 2013 at 23:00:58 UTC, Steven Schveighoffer 
wrote:
 I was sure too.  It's not.  Any operation between A types 
 results in A.

 writeln(typeof(a + a).stringof); // => A
 writeln(typeof(a << a).stringof); // => A
 writeln(typeof(a * a).stringof); // => A

It has to be a bug, as it doesn't make sense for it to be legal.
Mar 01 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 01 Mar 2013 19:22:14 -0500, Era Scarecrow <rtcvb32 yahoo.com>  
wrote:

 On Friday, 1 March 2013 at 23:00:58 UTC, Steven Schveighoffer wrote:
 I was sure too.  It's not.  Any operation between A types results in A.

 writeln(typeof(a + a).stringof); // => A
 writeln(typeof(a << a).stringof); // => A
 writeln(typeof(a * a).stringof); // => A

It has to be a bug, as it doesn't make sense for it to be legal.

Read the spec, carefully. It's implemented as designed. http://dlang.org/type.html Implicit conversion: "A enum can be implicitly converted to its base type, but going the other way requires an explicit conversion." But for integer promotion: "If a enum has as a base type one of the types in the left column, it is converted to the type in the right column." The left column referred to does not have anything 32-bit or above in it besides dchar. Remember that. Later on, regarding arithmetic operations: If one or both of the operand types is an enum after undergoing the [Integer promotion] conversions, the result type is: * If the operands are the same type, the result will be the (sic) that type. * If one operand is an enum and the other is the base type of that enum, the result is the base type. * If the two operands are different enums, the result is the closest base type common to both. A base type being closer means there is a shorter sequence of conversions to base type to get there from the original type. Note that if no integer promotion occurs (i.e. base type is 32 bits or above and not dchar), and you are adding A with A, both operands are of the same type, so "the result will be that type." Just bad design IMO. It should be fixed. -Steve
Mar 01 2013
prev sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 2 March 2013 at 00:36:19 UTC, Steven Schveighoffer 
wrote:
 Read the spec, carefully.  It's implemented as designed.

 http://dlang.org/type.html

 Implicit conversion: "A enum can be implicitly converted to its 
 base type, but going the other way requires an explicit 
 conversion."

 But for integer promotion:

 "If a enum has as a base type one of the types in the left 
 column, it is converted to the type in the right column."

 The left column referred to does not have anything 32-bit or 
 above in it besides dchar.  Remember that.

 Later on, regarding arithmetic operations:

 If one or both of the operand types is an enum after undergoing 
 the  conversions, the result type is:
 * If the operands are the same type, the result will be the 
 (sic) that type.
 * If one operand is an enum and the other is the base type of  
 that enum, the result is the base type.
 * If the two operands are different enums, the result is the 
 closest base type common to both. A base type being closer 
 means there is a shorter sequence of conversions to base type 
 to get there from the original type.
 Note that if no integer promotion occurs (I.e. base type is 32 
 bits or above and not dchar), and you are adding A with A, both 
 operands are of the same type, so "the result will be that 
 type."

I've heard more than once the spec changing to fit an implementation. Still seems wrong. The enum's converted (not promoted) to it's numeric version and cannot be converted back. The details quoted are regarding integer promotion. If it's intended to be that way (enums + math/binary operators = same enum type) then the spec is flat out wrong. Following the simple logic and feature for 'final switch' that it's guaranteed to handles ALL cases and combinations of what the enum could be (thus there's no default); but it can't handle the cases presented. An enum (unless forcibly cast) should always be valid; So anything that could potentially modify the enum can only result in it's base type.
 Just bad design IMO.  It should be fixed.

Agreed, needs to be fixed.
Mar 01 2013