Hacker News Reader

Comment by darkxanthos | Hacker News Reader

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

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...

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.

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.

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?

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;

Time for a pull request? ;)

Reply on news.ycombinator.com