서명되지 않은 INT 비교와 C ++ 열거

Question

나는 지금 내가 작업하고있는 코드에서 이것을 발견했으며 그것이 내가 가진 몇 가지 문제의 원인이라고 생각했다.

어딘가에 헤더에서 :

enum SpecificIndexes{
    //snip
    INVALID_INDEX = -1
};

그런 다음 나중에 - 초기화 :

nextIndex = INVALID_INDEX;

그리고 사용

if(nextIndex != INVALID_INDEX)
{
    //do stuff
}

코드를 디버깅하면 NextIndex의 값은 그대로 만들어지지 않았으며 (매우 크 았음), 나는 그것이 선언 된 것을 발견했습니다.

unsigned int nextIndex;

따라서 Invalid_Index의 초기 설정은 서명되지 않은 int를 과소 평가하여 막대한 숫자로 설정했습니다. 나는 그것이 문제를 일으키는 것이라고 생각했지만 더 자세히 살펴보면 테스트

if(nextIndex != INVALID_INDEX)

NextIndex가 "큰 +ve 값"이었을 때 IF의 본문을 정확하게 수행하지 않았습니다.

이 올바른지? 어떻게 이런 일이 일어나고 있습니까? 열거 값이 변수와 동일한 유형의 서명되지 않은 int로 암시 적으로 캐스팅되어 같은 방식으로 래핑됩니까?

Answer 1

모든 것에 예. 그것은 유효한 코드이며, 일반적으로 사용되는 라이브러리 측 C ++ 코드입니다.

그런 다음 열거는 INT에 서명되지만 서명되지 않은 INT로 암시 적으로 캐스트됩니다. 이제 컴파일러에 따라 경고를 줄 수 있지만 여전히 매우 일반적으로 사용되지만 유지 관리자에게 명확하게 캐스트해야합니다.

Answer 2

열거는 음수 값을 포함하는지 여부와 컴파일러의 느낌에 따라 서명 또는 서명되지 않은 적분 유형으로 표시 될 수 있습니다. 여기의 예에는 음수 값이 포함되어 있으므로 서명 된 적분 유형으로 표시되어야합니다.

서명되지 않은 유형과 부호없는 유형의 평등 비교는 안전하며 일반적으로 저자가 의도 한 바를 수행합니다. 서명 된 값은 서명되지 않은 것으로 변환되며 그 결과는 C ++ 표준에 의해 정의되며 직관적입니다 (적어도, 일단 당신은 일단 당신은 직관적입니다. 대상 유형을 알고 있습니다. 정수가 둘의 보완이 아닌 경우를 제외하고는 직관적이지 않지만 일반적으로 문제를 일으키지는 않습니다).

주문 비교는 오류가 발생할 가능성이 높습니다. 예를 들어:

SpecificIndexes value = INVALID_VALUE;
return (value >= 0);

거짓을 반환하지만 :

unsigned int value = INVALID_VALUE;
return (value >= 0);

진실을 반환합니다. 때때로 저자는 특히 "가치"유형이 사용 시점에서 그다지 명백하지 않은 경우 차이를 인식하지 못할 것입니다. 그러나 (값> = 0)은 팽팽한이기 때문에 컴파일러는 두 번째 예제에 대해 잘 경고 할 수 있습니다.

Answer 3

실제로, -1은 NextValue에 할당 될 때 동등한 서명되지 않은 값에 암시 적으로 캐스트됩니다. 동등한 서명은 동일한 비트 표현 (111111111111)을 갖는 값입니다 (이것은 서명되지 않은 최대 값입니다).

나중에 비교 진술에서 또 다른 암시 적 캐스트가 발생합니다.

그래서 이것은 지금 작동하지만 앞으로는 문제를 일으킬 수 있습니다. 서명 및 서명되지 않은 값을 혼합하는 것은 결코 좋은 생각이 아닙니다.

Answer 4

예, 열거가 서명되었다고 생각합니다. 변화

unsigned int nextIndex;

에게

int nextIndex;

그리고 귀하의 프로그램은 작동해야합니다.

Answer 5

C ++ 표준을 통해 구현은 열거에 서명 된 유형을 사용할 수 있지만 필요하지 않습니다. 따라서 일반적으로 음수를 열거에 넣는 것이 안전하다고 가정 할 수 없습니다.