16 진수 상수를 사용하는 이유는 무엇입니까?

16 진수 상수를 사용하는 이유는 무엇입니까?

---

때로는 10 진수 대신 16 진수로 정의 된 정수 상수를 볼 수 있습니다. 이것은 GL10 수업에서 가져온 작은 부분입니다.

public static final int GL_STACK_UNDERFLOW = 0x0504;
public static final int GL_OUT_OF_MEMORY = 0x0505;
public static final int GL_EXP = 0x0800;
public static final int GL_EXP2 = 0x0801;
public static final int GL_FOG_DENSITY = 0x0B62;
public static final int GL_FOG_START = 0x0B63;
public static final int GL_FOG_END = 0x0B64;
public static final int GL_FOG_MODE = 0x0B65;

2914대신 정의하는 것이 분명히 더 간단 0x0B62하므로 성능상의 이점이 있습니까? 나는 그것을 변경하는 것이 컴파일러의 일이어야하므로 그렇게 생각하지 않는다.

---

조직적이고 시각적 인 청결을위한 것 같습니다. 16 진법은 10 진법보다 2 진법과 훨씬 더 단순한 관계를가집니다. 16 진법에서 각 숫자는 정확히 4 비트에 해당하기 때문입니다.

위에서 상수가 공통적으로 많은 숫자로 그룹화되는 방법에 주목하십시오. 십진수로 표현하면 공통 비트가 덜 명확합니다. 대신에 공통된 십진수가 있으면 비트 패턴이 동일한 정도의 유사성을 갖지 않습니다.

또한 많은 상황에서 비트 OR 상수를 함께 사용하여 플래그 조합을 만들 수 있어야합니다. 각 상수의 값이 0이 아닌 비트의 하위 집합 만 갖도록 제한되는 경우 다시 분리 할 수있는 방식으로 수행 할 수 있습니다. 16 진수 상수를 사용하면 각 값에서 어떤 비트가 0이 아닌지 명확하게 알 수 있습니다.

다른 두 가지 합리적인 가능성이 있습니다. 8 진수 또는 8 진수는 단순히 숫자 당 3 비트를 인코딩합니다. 그리고 이진 코드 십진수가 있는데, 각 숫자는 4 비트가 필요하지만 9 이상의 숫자 값은 금지됩니다. 이는 바이너리가 할 수있는 모든 가능성을 나타낼 수 없기 때문에 불리합니다.

---

"0x0B62 대신 2914를 정의하는 것이 분명히 더 간단합니다."

나는 그 특정한 경우에 대해 모르지만 사실이 아닙니다.

두 가지 질문 중 :

• A) 2914의 비트 값은 무엇입니까?
• B) 0x0B62의 비트 값은 무엇입니까?

B는 많은 개발자들이 더 정확하게 더 빨리 대답 할 것입니다. (비슷한 질문에도 해당됩니다)

---

0x0B62 (4 자리 16 진수이므로 16 비트 숫자를 나타냄)

• 0 = 0000의 비트
• B = 1011의 비트
• 6의 비트 = 0110
• 2의 비트 = 0010

->

0000101101100010

(저는 2914에 대해서도 똑같이 할 수 있습니다.)

---

이것이 16 진수 값을 사용하는 한 가지 이유이고, 또 다른 이유는 값의 소스가 16 진수 (예 : 사양의 표준)를 사용할 수 있기 때문입니다.

때로는 다음과 같이 어리석은 것으로 보입니다.

public static final int NUMBER_OF_TIMES_TO_ASK_FOR_CONFIRMATION = ...;

16 진수로 작성하는 것은 거의 항상 어리석은 일이지만 그렇지 않은 경우가 있다고 확신합니다.

---

예를 들어 16 진수 마스크를 적용 할 때 가독성 .

---

숫자를 나타내는 바이트 상수를 이동하도록 코드가 컴파일되기 때문에 10 진수와 16 진수 사이에는 성능상의 이점이 없습니다.

컴퓨터는 십진수가 아니라 (기껏해야) 이진수를 사용합니다. 16 진법은 이진법으로 매우 깔끔하게 매핑되지만, 십진수를 이진법으로 변환하려면 약간의 작업이 필요합니다.

16 진수가 빛나는 한 곳은 관련 항목이 많을 때입니다. 많은 항목이 비슷하지만 약간 다릅니다.

// These error flags tend to indicate that error flags probably
// all start with 0x05..
public static final int GL_STACK_UNDERFLOW = 0x0504;
public static final int GL_OUT_OF_MEMORY = 0x0505;

// These EXP flags tend to indicate that EXP flags probably
// all start with 0x08..
public static final int GL_EXP = 0x0800;
public static final int GL_EXP2 = 0x0801;

// These FOG flags tend to indicate that FOG flags probably
// all start with 0x0B.., or maybe 0x0B^.
public static final int GL_FOG_DENSITY = 0x0B62;
public static final int GL_FOG_START = 0x0B63;
public static final int GL_FOG_END = 0x0B64;
public static final int GL_FOG_MODE = 0x0B65;

십진수를 사용하면 서로 다르지만 관련된 많은 항목에서 비트의 상수 영역을 "알아 내기"어렵습니다.

---

0xFFFFFFFF또는 쓰시겠습니까 4294967295?

The first one much more clearly represents a 32 bit data type with all ones. Of course, many a seasoned programmer would recognize the latter pattern, and have a sneaking suspicion as to it's true meaning. However even in that case, it is much more prone to typing errors, etc.

---

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.

---

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

---

0xB62 equals 2914 :-)

For developers it is much easier to mentally picture the bit pattern of a constant when it is presented in hexadecimal than when it is presented as an base 10 integer.

This fact makes presentation in hexadecimal more suited for constants used in API's where bits and their positions (used as individual flags for instance) are relevant.

---

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!

---

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.

---

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.

ReferenceURL : https://stackoverflow.com/questions/10920432/why-use-hexadecimal-constants