[질문] 그러고 보니까 축소형변환 궁금한 게 있는데

[C++(rustisbetterthancpp)]

int64_t -> int32_t으로 축소형변환되는 경우에는 바이트가 어느쪽부터 잘리는 건가? 이거 표준에 있나? 검색을 해봤는데 멍청이라 못 찾겠음.

암시적인 축소형변환의 경우 플랫폼 디펜던트하다고 clangd에서 경고 띄우는데 그러면 명시적인 축소형변환은 괜찮음?

[익명(skuld88)]

implementation defined 입니다. 표준에서 정해놓진 않아요. 일반적으론 endian 따라 달라지죠

[익명(skuld88)]

1. 명시적이건 암시적이건 똑같이 "위쪽 숫자"가 잘립니다. 2. 플랫폼에 따라 달라지는건 위쪽 숫자가 byte array로 봤을때 왼쪽 바이트냐 오른쪽 바이트냐 그 차이입니다.

[다믜(damhiya)]

endianness에 따라 byte array로 봤을 때 왼쪽/오른쪽중 어느쪽 바이트인지가 달라지는건 맞는데 여기서 굳이 언급될 이유는 없지 않나요

[익명(skuld88)]

본문에서 '바이트가 어느쪽부터 잘리는 건가' 라고 물어봐서요.

[다믜(damhiya)]

가령 64bit -> 32bit에서 lsb쪽 절반만 남는다고 하면 그냥 2^32으로 나머지 연산하는건데 굳이 byte열이 언급될 이유가 없지

[C++(rustisbetterthancpp)]

감사합니다

[다믜(damhiya)]

+ 표준 문서만 보면 signed에서 destination 표현범위를 넘는경우 위쪽숫자가 잘린다는 보장도 없어보임

[익명(skuld88)]

위쪽 바이트가 잘려요.
https://eel.is/c++draft/conv.integral

[익명(skuld88)]

the result is the unique value of the destination type that is congruent to the source integer modulo 2^N, where N is the width of the destination type.

[다믜(damhiya)]

아 표준이 바뀐건가 싶네요.
https://timsong-cpp.github.io/cppwp/n3337/conv.integral
여기 있는건 C++11 인데 signed면 다르다고 나와있음

[익명(skuld88)]

C++17까지는 말씀하신 게 맞습니다. 정확히는 C++20에서 signed 표현을 2의 보수 표현으로 통일하도록 규정했기 때문에 저렇게 바뀐 것이에요. (
https://en.cppreference.com/w/cpp/20)
그런데 상상할 수 있는 거의 모든 벤더가 2의 보수 표현을 쓰고 있었기 때문에 C++17까지는 '엄밀하게는 아니지만 실질적으로는 상관없는' 사항이었다고 보시면 될 것 같네요

[익명(skuld88)]

머신 엔디안은 std::endian::native로 확인해보면 됩니다

[다믜(damhiya)]

https://stackoverflow.com/questions/6752567/casting-a-large-number-type-to-a-smaller-type

[다믜(damhiya)]

implementation defined이긴 하지만 int32_t로 표현되는 값이라면 변하지 않아야 하기 때문에, 보통 나머지로 들어가지 않을까 싶은데

[C++(rustisbetterthancpp)]

감사합니다

[토끼주문(icyselec)]

저도 확실히 위쪽 바이트가 무조건 짤리는게 아니라 모듈러스 연산한다고 배웠음

[다믜(damhiya)]

대화를 이해하고 있는거임? 위쪽 바이트 짤린다는게 modulo 연산한다는거랑 같은 뜻인데