구조체는 메모리에 어떻게 저장되어 있습니까?

Question

내 코드에 struct iof_header이 있고, 24 바이트의 너비가 될 것이라고 판단했습니다. 나는 sizeof (iof_header)를 수행하고 32 바이트 폭을 반환합니다.

질문 1 왜 24 바이트가 아닌 32 바이트입니까?

질문 2 구조체를 어떻게 메모리에 저장합니까?

질문 3 내가 모든 NULL입니다 바이트 내 구조체 중 하나 [4-8 & 20 ~ 24]을 만드는 모든 시간을 찾아 내 문자 배열이 분명를 참조하십시오. 배열은 다음과 같습니다. {4 bytes of BASEID_Code, 4 NULL bytes, 8 bytes of zeroed padding, 4 bytes of ASID_Code, 4 NULL bytes, 8 bytes of size} 내 unsigned __int32 회원의 끝에 NULL 바이트가 있습니다. 왜 이런 일이 발생합니까?

관련 컴파일이 가능합니까? 아마도 CPU가 이러한 데이터 유형을 더 빠르게 처리 할 수있게하는 효율성 문제일까요?

struct      iof_header 
{ 
    union 
    { 
     struct 
     { 
      unsigned __int32  BASEID_Code; 
      unsigned __int64  padding; 
      union 
      { 
       char     ASID_Type[4]; 
       unsigned __int32  ASID_Code; 
      }; 
      unsigned __int64  Size; 
     }header; 
     char     header_c[24]; 
    }; 
    iof_header() 
    { 
     header.ASID_Code = 0; 
     header.BASEID_Code = 0; 
     header.Size = 0; 
     header.padding = 0; 
    } 
}; 

Answer 1

왜 24 바이트가 아닌 32 바이트입니까?

각 맞춤 요구 사항을 충족하기 위해 각 __int64 회원 앞에서 패딩이 추가 되었기 때문일 수 있습니다.

구조체를 어떻게 메모리에 저장합니까?

멤버는 구조의 시작 위치를 기준으로 각 멤버를 올바르게 정렬하는 데 필요한 경우 패딩이 삽입 된 순서로 저장됩니다.

일부 컴파일러는 멤버를 "팩"하는 비표준 확장을 사용하므로 패딩이 삽입되지 않습니다. 예를 들어, GCC에서 구조 정의 뒤에 __attribute__((packed))을 넣을 수 있습니다.

아마도 CPU가 이러한 데이터 유형을 더 빠르게 처리 할 수있게 만드는 효율성이 있습니까?

예. 일부 프로세서에서는 정렬되지 않은 액세스가 느립니다. 다른 것들은 전혀 허용되지 않으며 둘 이상의 액세스로 에뮬레이션되어야합니다.

Answer 2

컴파일러는 정렬 요구 사항을 유지하기 위해 멤버 뒤에 패딩 바이트를 추가 할 수 있습니다. __int64 회원이 8 바이트로 정렬되어 있고 BASEID_Code과 padding 사이의 4 개의 채우기 바이트가 발생합니다.