둘 다 32 비트 (Windows LLP64)인데 왜`long &`에서`int &`로 reinterpret_cast가 필요합니까?

Question

크로스 플랫폼 환경에서 Qt로 작업하고 있습니다. 그리고 우리는 다음과 같은 문제를 겪고 있습니다. Windows에서 int과 long int은 모두 32 비트 정수입니다. 64 비트 MacOS 및 Linux의 경우 int은 32 비트이고 long int은 64 비트입니다 (https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models 참조).

따라서 플랫폼 간 라이브러리는 자체 고정 비트 typedef를 제공하는 경향이 있습니다. Windows에서 Qt는 quint32을 unsigned int으로 정의하고 unsigned long 개의 정수를 사용하지 않습니다. 또 다른 라이브러리는 Uint32을 unsigned long으로 정의합니다. 따라서 두 가지 모두 실제로 32 비트 부호없는 정수이지만 다른 원시 데이터 유형을 갖습니다.

지금, 우리가 사실 인하지 unsigned long에 대해 정의되는 QDataStream 사업자에 대해 불평 ++ QDataStreamUint32 데이터 및 놀랍게도 (여부) quint32에 대해 정의 직렬화, 비주얼 C를 사용하려고하는 것이, 어떻게 Qt는 때문에 거의 동일한 unsigned int을 대신 사용합니다. 내가 reinterpret_cast해야합니까 이유 :

확인, 해결 방법은

#ifdef Q_OS_WIN 
inline QDataStream & operator >> (QDataStream & stream, Uint32 & value) 
{ return stream >> reinterpret_cast<quint32 &>(value); } 

inline QDataStream & operator << (QDataStream & stream, Uint32 value) 
{ return stream << quint32(value); } 
#endif // def Q_OS_WIN 

내 질문을 제공하는 것입니까? 나는 데이터 타입이 실제로 동일하다는 것을 이해했기 때문에 static_cast으로 더 편하게 느낄 것이다. 여기 용이 있을까요?

Answer 1

int 및 long은 동일한 속성이 다른 경우에도 다른 데이터 유형입니다.

operator>>은 엄격한 별칭 위반으로 인해 정의되지 않은 동작을 일으 킵니다. 코드를 작성하는 올바른 방법은 다음과 같습니다

inline QDataStream & operator >> (QDataStream & stream, Uint32 & value) 
{ 
    quint32_t v; 
    stream >> v; 
    value = v; 
    return stream; 
} 

(참고 : 읽기 실패에 0에 값을 설정하는 것을 나는 QDataStream 있으리라 믿고있어 >> C++ (11) IStream을 같은 속성이 있습니다 >>에서 ; 그렇지 않다면 읽음에 실패하면 value = v;이 실행되지 않도록 분기를 포함해야합니다.

operator<<은 값 변환이므로 static_cast을 사용할 수 있습니다. 사실 operator<<을 완전히 생략 할 수 있어야합니다.

귀하가 궁금해하는 문제는 표준화 된 프로젝트를 사용하지 않고 자체 typedef를 구성하는 프로젝트의 결과입니다. 불행하게도 프로젝트가 표준화 된 유형으로 이동하기로 결정할 때까지는 처리해야 할 것입니다. 두 사람 모두 uint32_t을 사용한 경우이 문제가 발생하지 않습니다.