[java] Java가 서명되지 않은 정수를 지원하지 않는 이유는 무엇입니까?

Java가 부호없는 정수에 대한 지원을 포함하지 않는 이유는 무엇입니까?

예기치 않은 큰 입력에서 오버플로가 발생할 가능성이 적은 코드를 작성할 수 있다는 점을 감안할 때 이상한 생략 인 것 같습니다.

또한 부호없는 정수를 사용하는 것은 자체 문서화의 한 형태 일 수 있습니다. 부호없는 정수가 보유하려고 한 값이 절대 음수로 표시되지 않기 때문입니다.

마지막으로 부호없는 정수는 나누기와 같은 특정 작업에 더 효율적일 수 있습니다.

이것들을 포함하면 어떤 단점이 있습니까?



답변

이것은 단순성에 대한 Gosling 및 다른 사람들과인터뷰 에서 얻은 것입니다 .

Gosling : 저를 요즘으로 생각하지 않는 언어 디자이너로서 저에게 “간단한”이라는 의미는 J. Random Developer가 그의 머리 속에 스펙을 갖도록 기대할 수있었습니다. 예를 들어, Java는 그렇지 않다는 사실이 있습니다. 실제로 이러한 언어는 실제로 이해하지 못하는 많은 경우로 끝납니다. 서명되지 않은 C 개발자에 대한 퀴즈를 풀면 곧 C 개발자가 서명되지 않은 연산, 서명되지 않은 산술이 무엇인지 이해하는 사람이 거의 없다는 것을 알게 될 것입니다. 그런 것들이 C를 복잡하게 만들었습니다. Java의 언어 부분은 매우 간단하다고 생각합니다. 찾아야 할 라이브러리.


답변

선 사이를 읽으면 논리가 다음과 같다고 생각합니다.

  • 일반적으로 Java 디자이너는 사용 가능한 데이터 유형의 레퍼토리를 단순화하려고했습니다.
  • 일상적인 목적으로 서명 된 데이터 유형이 가장 일반적으로 필요하다고 느꼈습니다.
  • 특정 알고리즘을 구현하기 위해 부호없는 산술이 필요한 경우도 있지만 이러한 알고리즘을 구현할 프로그래머도 서명 된 데이터 유형으로 부호없는 산술을 수행하는 데 대한 지식이 있어야합니다.

대부분, 나는 그것이 합리적인 결정이라고 말했습니다. 아마도, 나는 :

  • 바이트를 부호없는 것으로 만들거나 적어도 하나의 데이터 유형에 대해 다른 이름을 가진 부호있는 / 부호없는 대안을 제공했습니다 (서명은 일관성을 유지하는 것이 좋지만 언제 부호있는 바이트가 필요합니까?)
  • ‘짧은’으로 없애 버렸습니다 (16 비트 부호있는 산술을 언제 마지막으로 사용 했습니까?)

그럼에도 불구하고 약간의 클루 징을 통해 최대 32 비트의 부호없는 값에 대한 작업은 그리 나쁘지 않으며 대부분의 사람들은 부호없는 64 비트 나누기 또는 비교가 필요하지 않습니다.


답변

이것은 오래된 질문이며 pat은 간단히 char을 언급했지만,이 길을 내려다 보는 다른 사람들을 위해 이것을 확장해야한다고 생각했습니다. Java 프리미티브 유형을 자세히 살펴 보겠습니다.

byte -8 비트 부호있는 정수

short -16 비트 부호있는 정수

int -32 비트 부호있는 정수

long -64 비트 부호있는 정수

char -16 비트 문자 (부호없는 정수)

하지만 char지원하지 않는 unsigned연산, 그것은 본질적으로 처리 할 수 있습니다 unsigned정수입니다. 산술 연산을 명시 적으로 다시로 캐스팅해야 char하지만 unsigned숫자 를 지정하는 방법을 제공합니다 .

char a = 0;
char b = 6;
a += 1;
a = (char) (a * b);
a = (char) (a + b);
a = (char) (a - 16);
b = (char) (b % 3);
b = (char) (b / a);
//a = -1; // Generates complier error, must be cast to char
System.out.println(a); // Prints ? 
System.out.println((int) a); // Prints 65532
System.out.println((short) a); // Prints -4
short c = -4;
System.out.println((int) c); // Prints -4, notice the difference with char
a *= 2;
a -= 6;
a /= 3;
a %= 7;
a++;
a--;

예, 부호없는 정수에 대한 직접적인 지원은 없습니다 (직접 지원이 있다면 대부분의 작업을 char로 다시 캐스팅 할 필요가 없습니다). 그러나 서명되지 않은 기본 데이터 유형이 반드시 존재합니다. 나는 부호없는 바이트도보고 싶었지만 메모리 비용을 두 배로 늘리고 대신 char을 사용하는 것이 가능한 옵션이라고 생각합니다.


편집하다

JDK8 거기위한 새로운 API는 다음 LongInteger헬퍼 메소드 제공하는 처리 longint부호 값으로 값.

  • compareUnsigned
  • divideUnsigned
  • parseUnsignedInt
  • parseUnsignedLong
  • remainderUnsigned
  • toUnsignedLong
  • toUnsignedString

또한 구아바 는 정수 유형에서 비슷한 작업을 수행하는 여러 가지 도우미 메서드를 제공하여 정수에 대한 기본 지원 부족으로 인한 격차를 해소 unsigned합니다.


답변

Java에는 서명되지 않은 유형이 있거나 최소한 하나 이상이 있습니다. char는 부호가없는 축약 형입니다. 고슬링이 변명하는 것이 무엇이든지간에 서명되지 않은 다른 유형이없는 이유는 실제로 그의 무지입니다.

또한 짧은 유형 : 반바지는 멀티미디어에 항상 사용됩니다. 그 이유는 단일 32 비트 부호없는 길이로 2 개의 샘플을 맞추고 많은 연산을 벡터화 할 수 있기 때문입니다. 8 비트 데이터와 부호없는 바이트도 마찬가지입니다. 벡터화를 위해 레지스터에 4 개 또는 8 개의 샘플을 맞출 수 있습니다.


답변

부호있는 정수와 부호없는 정수가 표현에 혼합되면 문제가 발생하기 시작하고 정보 손실 될 수 있습니다. 서명 된 정수로 Java를 제한하면 실제로 문제가 해결됩니다. 서명 된 / 서명되지 않은 전체 비즈니스에 대해 걱정할 필요가 없어서 기쁘지만, 때때로 바이트에서 8 비트를 놓치게됩니다.


답변

http://skeletoncoder.blogspot.com/2006/09/java-tutorials-why-no-unsigned.html

이 표준은 C 표준이 서명되지 않은 및 서명 된 int와 관련된 연산을 서명되지 않은 것으로 취급하기 때문에 정의한다고 말합니다. 음의 부호있는 정수가 부호없는 큰 int로 롤오버되어 버그가 발생할 수 있습니다.


답변

Java는 그대로 괜찮다고 생각하고 unsigned를 추가하면 많은 이익을 얻지 않고도 복잡하게 만들 수 있습니다. 단순화 된 정수 모델을 사용하더라도 대부분의 Java 프로그래머는 기본 숫자 유형의 작동 방식을 알지 못합니다. Java Puzzlers 라는 책을 읽고 어떤 오해가 생길 수 있는지 확인하십시오.

실용적인 조언에 관해서는 :

  • 값이 임의의 크기이며에 맞지 않으면를 int사용하십시오 long. long사용에 적합하지 않은 경우 BigInteger.

  • 공간을 절약해야 할 때 배열에만 더 작은 유형을 사용하십시오.

  • 정확히 64/32/16/8 비트가 필요한 경우 long/ int/ short/를 사용 byte하고 나누기, 비교, 오른쪽 이동 및 캐스팅을 제외하고 부호 비트에 대해 걱정하지 마십시오 .

“난수 생성기를 C에서 Java로 이식”에 대한 답변 도 참조하십시오 .