Silly question: Why is there no "binary" integer constant specifier?

Except if you need to look at patterns in the binary values to create the subsequent value with. Yes it is easy to convert to hex but I don't understand why octal is represented but binary is not.  For instance if you need to know the extent of last 1 bit, the number of 1s, etc, looking at dozens of hex values, it makes it much more difficult than it needs to be.

EDIT: As an example, let's say you want to create a Gray code sequence (yes, there is a super simple algo for that, but this is just an example), so it is much easier to look at the binary values than the hex values. In my particular case, the sequence I need to create in not Gray code, but the same type of constraints apply where the next value is based on the locations of the bits in the previous values.

Yea, I was thinking along those lines too, but defining either an enum with the values, or just constants, something like:

enum Bits

{

   b00000000 = 0,

   b00000001,

   b00000010,

   ...

}

Or

const int b00000000 = 0;

const int b00000000 = 1;

Or if performance is not an issue, I can make an extention method to string so that I can do:

int bits = string.ToBits("000101101");

But you can't later use that in a switch/case statement.

OK, I originally missed what you meant. I'm using C#, btw. So when you say "write a simple preprocessor and run it before compilation", can you be a little bit more specific?  I have never done that before. If you are talking about destructively modifying the original source file, then it won't work in my case because I'd definitely need to be able to go back later and edit the binary table.

lensman wrote:

Are you trying to do somthing like:

public enum SECURITY_MASKS

{

    NO_ACCESS = 0,

    STANDARD_USER = 1 << 0,

    FINANCE_USER = 1 << 1,

    ADMIN_USER = 1 << 2

 }

I have similiar logic in several of my projects. Works like a champ.

Yes I do that all the time as well, but in this case it doesn't solve my particular problem. If you have multiple 1's then it becomes a mess and the vertical bits do not line up with each other, unless you also do the 0's.

AndyC wrote:

It doesn't take much to mentally "see" the binary patterns while looking at hex and the natural 4-bit groupings make it easy to be sure you're looking at the right bits. Much easier than looking at long binary strings.

Believe me, if you need to analyze horizontal and vertical patterns in an array of binary values, then having to mentally convert from hex for evey value is very counter-productive.  Yes I can convert mentally to binary, but after you have done a few, you forgot all the bit positions from 3 numbers ago.  It is just not a workable solution. I am talking about spanning dozens of values at a time. For eaxample, try to find a sequence of 10 or more consecutive random values in the table where the 4th significant bits all have the value of zero and the 13th significant bits all have the value of 1. Good luck using hex. Yes, it can be done, but it will slow you down. Looking at a sequence of bits will instantly give you your answer.

AndyC wrote:

My point is, given a long bit string with multiple bits set, it's a about a gazillion times easier to read/write hex and yet still be able to "see" the bit pattern. And I suspect that is why there isn't a simple way of defining constants in binary.

Yes, it is only a gazillion times easier if you are dealing with one value at a time.

So far my best solution has been to define an enum like this (as I mentioned earlier):

enum Bits

{ 

    b00000000 = 0,

    b00000001, 

    b00000010, ...

}

It is fast, and works in switch/case. The only problem is that for 16 bits it is a gigantic table. I could do something like:

table[0] = (int)Bits.b00101010 << 8 + (int)Bits.b11001011;

table[1] = (int)Bits.b01000010 << 8 + (int)Bits.b10001101;

...

I am also considering using strings (also mentioned earlier), but conversion from/to will be slow when there are a lot to convert. Two dictionaries, Dictionary<int, string> and Dictionary<string, int> could speed things up in this case.  Actually, converting from string to binary should be relaively fast, but from binary to string could be slow because of the string allocation (even if using StringBuilder), but the Dictionary<int, string> could help out here.