Hacker News Reader

Comment by NKCSS | Hacker News Reader

This might be fun to look through; first thing I saw that I never thought of before was how to define flag enums.

From https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/C...:

    // State flags
    enum EGlassRNState
    {
    	EGlassRNState_Initial     = 0,
    	EGlassRNState_Weakened    = 1 << 0,
    	EGlassRNState_Shattering  = 1 << 1,
    	EGlassRNState_Shattered   = 1 << 2,
    	EGlassRNState_ActiveFrags = 1 << 3
    };

Als a C# dev, I write Enum flags from time to time, but I always just write out the values; never thought of using bit-shifting to prevent typos :)

View on HN

This is pretty standard practice, in C# too. However, it's still somewhat prone to typos.

If you don't care about backward compatibility (i.e. the flags are used internally and never written anywhere), then a better method is actually to grab the value one line above and bit shift it by one. That way you can insert values in the middle and you won't have to change every single line (just two).

Yeah, but still there's possibility of failure there as you could paste in and forget to update the one below.

Honestly, flags should be a type. IIRC, the C# designers have admitted this was a mistake on their parts to continue C's ambiguity between flag enums and choice enums.

Crystal has a Flag attribute for enums (Flag enums):

http://crystal-lang.org/docs/syntax_and_semantics/enum.html

Nim supports sets which IMO is a much better solution: http://nim-lang.org/docs/manual.html#types-set-type

Taken from Pascal and other Wirthian languages. Nim actually looks vaguely Wirthish in some areas. Interesting.

Nim's author was originally a Turbo Pascal/Delphi programmer. A lot of Nim and its conventions (things like prefixing type names with T and members with F) come directly from Borland's Pascal dialect.

Ah, so a Set keyed with an Enum is functionally C-style "flags" then?

Pretty much. Here is an example:

    type
      EGlassRNState = enum
        EGlassRNState_Initial,
        EGlassRNState_Weakened,
        EGlassRNState_Shattering,
        EGlassRNState_Shattered,
        EGlassRNState_ActiveFrags

    proc hasGlassShattered(mState: set[EGlassRNState]): bool =
      EGlassRNState_Shattered in mState

    proc hasActiveFragments(mState: set[EGlassRNState]): bool =
      EGlassRNState_ActiveFrags in mState

    assert hasActiveFragments({EGlassRNState_Shattered, EGlassRNState_ActiveFrags})

The Linux kernel takes it a step farther:

#define BIT(nr) (1UL << (nr))

#define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG))

#define BIT_WORD(nr) ((nr) / BITS_PER_LONG)

#define BITS_TO_TYPE(nr, t) (((nr)+(t)-1)/(t))

Hacks like these make unfamiliar code quite hard to understand (I'm looking at you OpenCV).

Yeah. It gets easier to understand once you use ctags/etags to have a "go to definition" key while you're hovering over a symbol.

In the Go language, there is something called iota which is like a iterator that counts up from 0:

    type EGlassRNState int

    const (
        EGlassRNState_Initial EGlassRNState = 1 << iota
        EGlassRNState_Weakened
        EGlassRNState_Shattering
        EGlassRNState_Shattered
        EGlassRNState_ActiveFrags
    )

In python you could probably do

    def makeflag():
        flag = 1
        while True:
            yield flag
            flag = flag << 1
    flag = makeflag()
    E_GLASS_RN_STATE_INITIAL = next(flag)
    E_GLASS_RN_STATE_WEAKENED = next(flag)
    E_GLASS_RN_STATE_SHATTERING = next(flag)
    E_GLASS_RN_STATE_ACTIVE_FRAGS = next(flag) 

    flag2 = makeflag()
    UNRELATED_FLAG = next(flag2) 
    UNRELATED_FLAG = next(flag2)

Also no chance of fatfingering a number.

Another option is to assume at most 128 bits then do something like:

  >>> _bitflags = [1<<i for i in range(128)]
  >>> (E_GLASS_RN_STATE_INITIAL,
  ...  E_GLASS_RN_STATE_WEAKENED,
  ...  E_GLASS_RN_STATE_SHATTERING,
  ...  E_GLASS_RN_STATE_ACTIVE_FRAGS,
  ...  *rest) = _bitflags
  >>> E_GLASS_RN_STATE_ACTIVE_FRAGS
  8

For the sake of correctness, the first const should be 0 and the second should be `1 << (iota - 1)`.

Just don't fall into old habits without thinking and end up writing...

    enum MyEnum
    {
    	MyEnum_Foo   = 1 << 0,
    	MyEnum_Bar   = 1 << 1,
    	MyEnum_Baz   = 1 << 2,
    	MyEnum_Quux  = 1 << 4,
    	MyEnum_Xyzzy = 1 << 8
    };

Go has a great idiom for this, with the 'iota' keyword, which increments by one for each line in a block of declarations.

From the language spec:

  const ( // iota is reset to 0
  	a = 1 << iota  // a == 1
  	b = 1 << iota  // b == 2
  	c = 3          // c == 3  (iota is not used but still incremented)
  	d = 1 << iota  // d == 8
  )

"(iota is not used but still incremented)"

Seems bizarre. That's actually a pretty confusing idiom in that context.

While it is a bit odd, it is documented (and I've seen it used a few times in code).

Yeah this is classic shitty design from Go. One-off compiler hack that doesn't actually address any of the actual safety problems.

org/bitflags/bitflags/macro.bitflags!.html is much better.

https://doc.rust-lang.org/bitflags/bitflags/macro.bitflags!....

To save you guys two clicks.

Thanks. Phone clipboard failure on my part.

How does bit shifting prevent typos as opposed to just explicit numbering?

It may or may not. However, what's more important is the semantic significance.

You're making it clear these are flags and you're concerned with individual bits. 2, 4, 8 etc. are decimal numbers and mean something else i.e. "two", "four", "eight".

Does bitwise ORing the decimal numbers 2 and 4 really make sense? Not particularly, but combining bits at certain offset does.

Bit off-topic, but in C# at least you can mark your enums with the 'Flags' attribute to indicate it's a flags enum.

The odd thing here is that these don't seem to be flags.. can a glass be both shattered and shattering?

Time for a pull request? ;)

Maybe you read it wrong :)

See http://csharppad.com/

    // State flags
    enum EGlassRNState
    {
        EGlassRNState_Initial     = 0,
        EGlassRNState_Weakened    = 1 << 0,
        EGlassRNState_Shattering  = 1 << 1,
        EGlassRNState_Shattered   = 1 << 2,
        EGlassRNState_ActiveFrags = 1 << 3
    };
    foreach(var val in Enum.GetValues(typeof(EGlassRNState

))) { Console.WriteLine($"{val} -> {(int)val}"); }

Output:

    EGlassRNState_Initial -> 0
    EGlassRNState_Weakened -> 1
    EGlassRNState_Shattering -> 2
    EGlassRNState_Shattered -> 4
    EGlassRNState_ActiveFrags -> 8

I think he meant that in this context does not make sense for more than one value to be true at the same time , which is the reason you define enums this way, usually.

Not necessarily. Enums main application is to restrict a variable to a range of valid values. As to whether some other object may have one or more of these vales, enum makes no statement.

But then using bit fields makes no sense.

It can be used like this, no?

    writable = 001
    readable = 010
    readwrite = 011 (writable | readable)

Yes yes, but the point was, it can't be Shattering and Shattered at the same time ;)

I throw a baseball through a window, and set the window's state to both Shattered and Shattering. It's Shattered, for the purposes of "is this an intact pane of glass?" e.g. if I throw another baseball, it's not going to shatter again, and I can jump through it without any physical resistance (in the case of strong/thick glass, if it was still intact I might risk bouncing off if I'm at low velocity or mass).

But it's also still in the process of Shattering, so when I jump through it, I'm risking cuts, it's actively producing noise for someone to hear, that laser I'm shining at it will be fragmenting wildly rather than reflecting off/passing through/deflecting like it was before the glass started Shattering.

Ok, but it still doesn't make sense to use flags here, because according to your definition, a shattering window is always shattered.

Anyway, I don't think it's worth arguing design on this codebase because it is full of dirty things.

There are three distinct values: unshattered, shattering, and shattered which appear to correspond to 00, 01, and 10 with 11 being an unused state. This will always occur in boolean with 2 bits and 3 used values (unless someone stupidly gave it an undocumented purpose).

It could serve a dual function to describe what states are valid for a given piece of glass.

e.g.

EGlassRNState allowed = EGlassRNState_Initial | EGlassRNState_Shattered;

EGlassRNState current = EGlassRNState_Initial;

Spot the error:

    ...
    [DayOfMonth(28)]
    D28 = 134217728L,
    [DayOfMonth(29)]
    D29 = 268435456L,
    [DayOfMonth(30)]
    D30 = 536870902L,
    [DayOfMonth(31)]
    D31 = 1073741824L,
    [DayOfMonth(DayOfMonthAttribute.LastDayOfMonth)]
    Last = 2147483648L

    ...
    [DayOfMonth(28)]
    D28 = 1 << 28,
    [DayOfMonth(29)]
    D29 = 1 << 29,
    [DayOfMonth(30)]
    D30 = 1 << 31,
    [DayOfMonth(31)]
    D31 = 1 << 31,
    [DayOfMonth(DayOfMonthAttribute.LastDayOfMonth)]
    Last = 1 << 32

Hint: It's with D30 in both cases...

Wait, so you used to compute the bit shifted value in your calculator and type it out literally (in base 10) in your code? I could understand typing out the binary literal but this is weird. Or am I misunderstanding?

It's how all MS Press books that I have read have explained it in the past; same goes for .NET focused websites back in 2001-2004 (when I got started in .NET

It's the same number in decimal and binary :)

I might be a bit weird, but I know the powers of 2 up to 2^20 in decimal. They've just snuck in there over the years, along with 2^24 and 2^31. So if I need some powers of two I might well just type them out like that. I can recognise a few common combinations too... it is all much easier in hex though.

I should really get the full set up to 2^64 memorised...

That's an impressive feat but now that you know about the bit shifting trick, I suggest you start using it because most of us mortals don't instantly recognise large powers of 2 when they're written out in decimal :) I'm still kind of amazed that you learned how to do bit arithmetic without coming across that pattern.

Another take on this is using hex values. Not saying it's better or worse than bit shifting, but it is fairly clear to me. My current lead prefers this for flag definitions.

FIRST_FLAG = 0x00000001

SECOND_FLAG = 0x00000002

THIRD_FLAG = 0x00000004

FOURTH_FLAG = 0x00000008

FIFTH_FLAG = 0x00000010

SIXTH_FLAG = 0x00000020

SEVENTH_FLAG = 0x00000040

EIGHTH_FLAG = 0x00000080

NINTH_FLAG = 0x00000100

...

28TH_FLAG = 0x08000000

29TH_FLAG = 0x10000000

30TH_FLAG = 0x20000000

Of course, I've never needed more than 12 bits of flags concurrently.

EDIT: Bleh, it wiped out my white space. These should be aligned.

At some point you forget a zero and it all goes to hell. Using 1 << n is far more concise.

Probably true. But assuming they are aligned, as they should be, a missing 0 would be pretty obvious. The real gotcha would be accidentally leaving a character in the wrong column during a copy-paste job.

But really, I've only used this with two or three character hex codes, so it works out much better. 0x01 through 0x80 are pretty hard to mess up, and 0x001 through 0x800 isn't bad either.

But yeah, the bit shifting honestly is probably a better solution. Cleaner, more scale-able.

It's usually done to combine multiple flags using bitwise or, but I don't think it's the case here(unless glass can be shattered and not shattered at the same time). Or are you saying that you usually write 0, 1, 2, 4 and so on?

C# even has a (deprecated?) [Flags] attribute that will auto-number in this way.

Edit: I was mistaken, it still requires manually setting the numbers, it just adds neater ToString support: https://msdn.microsoft.com/en-us/library/system.flagsattribu...

It also enables Enum.HasFlag.

https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/63418e7c9...

C++14 supports binary literals, which makes it way more readable.

Shifting is used to define masks. Did you mean you actually type out mask values in base 10?

> Did you mean you actually type out mask values in base 10?

I believe that's what they meant. I worked in C# for many years, and many, many places wrote out bit masts in base 10 literals as no one realized they could just left-shift. Similarly, whenever I would use the ?? (null-coalescing) operator, the reviewer would inevitably point out my "syntax error", at which point I'd have to point them at the ~10th page of the nearest C# book to convince them that, yes, that is one of the valid operators -- and it's quite useful too!

Man, do I miss those first years of my career working in .NET -- dunno why I ever switched to OSS stuff.

Hex literals work pretty well for defining masks.

Reply on news.ycombinator.com