Why use hexadecimal constants?

Question

Sometimes I see Integer constants defined in hexadecimal, instead of decimal numbers. This is a small part I took from a GL10 class:

public static final int          


        

Answer 1

"It's obviously simpler to define 2914 instead of 0x0B62"

I don't know about that specific case, but quite often that is not true.

Out of the two questions:

• A) What is the bit value of 2914?
• B) What is the bit value of 0x0B62?

B will be answered more correctly faster by a lot of developmers. (This goes for similar questions as well)

---

0x0B62 (it is 4 hex digits long so it reprensents a 16-bit number)

• the bits of 0 = 0000
• the bits of B = 1011
• the bits of 6 = 0110
• the bits of 2 = 0010

->

0000101101100010

(I dare you to do the same with 2914.)

---

That is one reason for using the hex value, another is that the source of the value might use hex (the standard of a specification for example).

Sometimes I just find it silly, as in:

public static final int NUMBER_OF_TIMES_TO_ASK_FOR_CONFIRMATION = ...;

Would almost always be silly to write in hex, I'm sure there are some cases where it wouldn't.

Answer 2

When it comes to big numbers, representing them in hexadecimal makes them more readable, because they're more compact.

Also, sometimes it is significant for conversions to binary: a hexadecimal number can be very easy converted to binary. Some programmers like to do this, it helps when doing bit operations on the numbers.

As for the performance gain: no, there is none.

Answer 3

There is no performance gain.

However, if these constants correspond to certain bits underneath, most programmers prefer Hex (or even binary) to make that clear and more readable.

For example, one can easily see that GL_EXP2 has 2 bits on, the 1 bit and the 0x0800 bit (which is 2048 decimal). A decimal value of 2049 would be less clear.

Answer 4

Sometimes it's easier using bit-related algorithms. Other times, it deals with bit comparisons, as my statement in a comment, 4 bits (binary digits) convert to 1 hex letter, so, A3 = 10100011.

Other times, it's either fun or breaks the monotony, though people not familiar with hex may think that you are doing things with pointers

int data = 0xF00D;
if ( val != 0xC0FFEE )
{
   data = 0xDECAF;
}

I sometimes use it to check bounds of things like ints. For example, you can use 0x7FFFFFFF (0x80000000 works in many cases but the 0x7F... is safer) to get a max int bounds. It's handy for setting a very high error constant if you don't have a language that has something like MAX_INT. The technique scales as well, since for 64-bit, you can use 0x7FFFFFFFFFFFFFFF. You may notice that Android uses 0x7___ for R.id table look-ups.

I bet they are doing it for clarity's sake. You can easily use integers, but if you are familiar with hex, it's not bad. It looks like they are reserving x values for certain functions. In decimal, you would do something like 0-99 is errors, 100-199 for something else, and so forth. How they are doing it is scaled differently.

Performance-wise, you gain nothing at runtime since the compiler (even a lot of assemblers) converts whatever format to binary in the end, whether decimal, octal, hexadecimal, float, double, etc.

Answer 5

Ahh but 0xDECAFF is both prime (1460959), and a pleasent purple color (in RGB).

For Colors hex is MUCH more convenient.

FF FF FF is white 00 00 FF is blue FF 00 00 is red 00 FF 00 is green It's easy to see the color relationships as numbers (though the gamma and fidelity of the human eye tend to throw things off, but we'll ignore those inconvenient physical facts for pure mathamatical precision!

Answer 6

Hexadecimal is the closest readable format to binary format. This simplifies a lot bit operations for example