4 ms·

Spot the error: ... [DayOfMonth(28)] D28 = 134217728L, [DayOfMonth(29)] D29 = 268435456L, [DayOfMonth(30)] D30 = 536870902L, [D

by NKCSS 10y ago

Spot the error: ... [DayOfMonth(28)] D28 = 134217728L, [DayOfMonth(29)] D29 = 268435456L, [DayOfMonth(30)] D30 = 536870902L, [DayOfMonth(31)] D31 = 1073741824L, [DayOfMonth(DayOfMonthAttribute.LastDayOfMonth)] Last = 2147483648L Vs ... [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...

olalonde 10y ago
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?
- NKCSS 10y ago
  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
- to3m 10y ago
  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...
  - olalonde 10y ago
    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.
bryondowd 10y ago
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.
- astrodust 10y ago
  At some point you forget a zero and it all goes to hell. Using 1 << n is far more concise.
  - bryondowd 10y ago
    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.

by NKCSS 10y ago

olalonde 10y ago

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?

NKCSS 10y ago
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
to3m 10y ago
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...
- olalonde 10y ago
  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.

bryondowd 10y ago

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.

astrodust 10y ago
At some point you forget a zero and it all goes to hell. Using 1 << n is far more concise.
- bryondowd 10y ago
  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.