는 sizeof 연산자

내가이 예상되지 및 결과 구조체 A A 구조체 thusly 히 정의 :는 sizeof 연산자

typedef struct _CONFIGURATION_DATA { 
    BYTE configurationIndicator; 
    ULONG32 baudRate; 
    BYTE stopBits; 
    BYTE parity; 
    BYTE wordLength; 
    BYTE flowControl; 
    BYTE padding; 
} CONFIGURATION_DATA;

이제, 내 계산에 의해, 그 구조체는 10 바이트입니다. 그러나 sizeof보고 길이는 16 바이트입니까? 왜 그런지 알아?

Windows DDK의 빌드 도구를 사용하여 컴파일 중입니다.

출처

2009-12-16 Kazar

강제 정렬? – jldupont

기억 : 구조체의 크기가 멤버 크기의 합과 같지 않을 수 있습니다. 구현은 멤버들과 마지막 멤버 이후에 패딩을 삽입 할 수 있습니다. 항상 옵셋으로 인해 이름으로 액세스 멤버에 액세스하므로 컴파일러 버전과 공급 업체간에 오프셋이 변경 될 수 있습니다. –

정렬.

사용

#pragma pack(1)

...struct goes here...

#pragma pack()

나는 또한 일을 재정렬 추천하고, 경우에게 필요한 패딩은 다음 예약 된 바이트, 있도록하는 멀티 바이트 정수형이 더 좋을 것이다 정렬. 이렇게하면 CPU가 더 빨리 처리되고 코드가 더 작아집니다.

출처

2009-12-16 10:52:06

그건 속임수 였어, 건배. – Kazar

많은 아키텍처가 잘못 정렬 된 액세스를 허용하지 않기 때문에 (컴파일러가 안전을 위해 바이트로드 및 저장을 사용해야 함) 대부분의 경우 성능 저하를 초래할 수있는 좋은 이유가있는 경우에만이 작업을 수행하십시오. –

참. 그러나 아키텍처가 지원하지 않을 때 컴파일러가 정렬되지 않은 정수 유형에 액세스하기위한 적절한 명령어를 생성 할 것으로 기대합니다. 파일, 통신 및 기타 IO에서 이진 데이터에 액세스하는 공통 패턴입니다. 반대로 컴파일러 버전/설정에 따라 변경되므로 정렬을 명시 적으로 지정하지 않으면 구조체를 작성하지 않는 것이 좋습니다. –

요소의 순서를 변경하십시오. ULONG부터 시작하여 BYTE를 시작하십시오. 이렇게하면 구조체의 메모리 정렬이 향상됩니다.

출처

2009-12-16 10:51:58 Rik

플랫폼에 따라 ULONG32이 4 바이트 경계에 정렬되어야하기 때문에 이는 패딩으로 인한 것입니다. struct의 시작과 끝이 정렬되어야하기 때문에 첫 번째와 마지막 BYTE은 각각 3 바이트로 채워집니다.

출처

2009-12-16 10:52:23 Thomas

측정하는 추가 크기는 컴파일러에서 도입 된 패딩입니다.

아마도 32 비트 시스템에서 작업하기 때문에 configurationIndicator과 baudRate 사이에 3 바이트의 패딩이 있고 구조체 끝에는 3 바이트의 패딩이 추가됩니다.

출처

2009-12-16 10:53:51 ddaa

는 sizeof 연산자

답변

관련 문제