uint대신 수많은 길이 / 개수 속성 등이있는 클래스를 구현해 보았습니다 int. 그러나 그렇게하는 동안 아무도 그렇게하고 싶어하지 않는 것처럼 그렇게하는 것이 실제로 고통 스럽다는 것을 깨달았습니다.
정수 유형을 전달하는 거의 모든 것이를 반환 int하므로 여러 지점에서 캐스트가 필요합니다. StringBuffer버퍼 길이가 해당 클래스의 필드 중 하나에 기본 설정되어있는를 생성하고 싶었습니다 . 캐스트도 필요합니다.
그래서 int여기로 돌아 가야할지 궁금 했습니다. 어쨌든 전체 범위를 사용하지는 않습니다. 나는 단지 내가 처리하고있는 것이 단순히 부정적 일 수 없기 때문에 (만약 있다면 그것은 오류 일 것이다) 실제로 사용하는 것이 좋은 생각이라고 생각했다 uint.
추신 : 나는 이 질문을 보았고 이것은 적어도 프레임 워크 자체가 항상 사용하는 이유를 설명 int하지만, 심지어 자체 코드에서도 실제로 그것이 실제로 uint원하지 않는다고 생각하게 만드는 것이 실제로 번거 롭습니다 .
답변
uint음이 아닌 정수를 포함하는 변수를 엄격하게 사용해야하지만 항상 실행 가능하지 않은 이유 중 하나를 발견했습니다.
이 경우 캐스트를해야하는 가독성의 감소는 그만한 가치가 없다고 생각합니다.
답변
다른 답변에 uint를 공용 필드, 속성, 메서드, 매개 변수 등의 유형으로 사용하는 것은 공용 언어 사양 규칙을 위반하는 것이며 가능하면 피해야한다는 것을 추가 할 것입니다.
답변
음수 값은 종종 오류 상태를 알리는 데 사용되며 연산의 크기는 종종 함수 호출에 의해 반환됩니다. 따라서 음수 값은 예외 메커니즘에 의존하지 않고 오류를 나타낼 수 있습니다.
또한 .NET은 종종 직접적인 C 라이브러리를 기반으로 빌드되므로이 규칙을 계속하는 것이 좋습니다. 더 큰 인덱스 공간이 필요한 경우 다른 오류 신호 메커니즘에 대한 규칙을 위반할 수 있습니다.
답변
내 개인적인 느낌은 아마도 int에 충실해야한다는 것입니다. .NET이 어쨌든 사용할 수 없을 것 같은 숫자 범위를 되찾기 위해 거의 모든 단일 속성 액세스에 캐스트를 추가 할 가치가 없습니다.
답변
int를 사용하면 연산에서 정수 오버플로를 감지하는데도 도움이됩니다.
답변
IMO, 사용의 단점은 uint오류 조건을 모호하게한다는 것입니다. 다음 코드와 동일한 것은 좋지 않습니다.
if (len < 0)
terminate_program("length attained impossible value.");
물론 여러분의 프로그램은 처음부터 어떤 것도 잘못 계산해서는 안되지만 전파없이 수치 오류를 빠르게 감지하도록 작성해야한다고 생각합니다. MaxValue가 2 ^ 31이면 충분할 경우, 위에서 예시 한대로 int적절한 사용 System.Diagnostics.Debug.Assert()및 해당 오류 검사 와 함께 사용 합니다.
당신이 경우에 사용 uint와 함께 사용 checked언더 플로우 방지와 같은 결과를 얻을 수 있습니다. 그러나 어떤 목적으로 캐스트를 사용하는 기존 코드에 검사를 적용하는 것이 약간 어렵다는 것을 알았습니다.
답변
필요하지 않다면 상류에서 수영하지 마십시오. 캐스트로 코드를 작성하지 않으면 코드가 더 읽기 쉬워집니다. 또한 가능한 값이 int에 맞으면 int를 사용하는 것은 문제가되지 않습니다.
만약 당신이 int를 넘칠 까봐 두렵다면, 꼭 거기에 ..하지만 너무 일찍 최적화하지 마세요.
나는 캐스트 최소화의 향상된 가독성이 int를 사용하는 버그의 약간 높아진 위험보다 큽니다.
