2016-08-19 1 views
3

D 구조체의 정확한 레이아웃이 정의되어 있습니까? 즉, 정의 된 모든 멤버의 정확한 오프셋과 컴파일러 독립적 인 방식입니까? 이는 컴파일러가 필요에 따라 다행히도 또는 불행히도 컴파일러가 필드를 재정렬하여 작은 항목을 최적으로 포장하고 모든 오프셋을 최소화하는 것을 금지 할 수 있음을 의미합니다.D 구조체의 정확한 레이아웃이 정의되어 있습니까?

답변

5

실제로 D 컴파일러가 구조체의 멤버를 재정렬하는 것은 불법입니다 (클래스의 경우 임). 구조체가 특정 메모리 레이아웃을 필요로하는 저수준 항목에 사용될 수 있기 때문에 컴파일러가 구조체의 멤버를 다시 정렬하지 않는 것이 중요합니다. 또한 구조체가 C 코드와 상호 작용할 수 있어야하므로 C에서 얻을 수있는 내용과 일치해야합니다 (적어도 extern(C) 사용시). 따라서 구조체는 멤버를 재정렬하지 않습니다. 또한 align attribute을 통해 멤버 정렬을 지정할 수 있으므로 구조체의 레이아웃을 완전히 제어 할 수 있습니다.

이제 아키텍처에 따라 기본 레이아웃이 다를 수 있습니다 (예 : 64 비트 포인터가 32 비트 포인터보다 많은 공간을 차지하므로 구조체 멤버가 압축되는 방식에 영향을 미칩니다)하지만 사용자가 얻는 것과 일치해야합니다 그 아키텍처에 C.

+0

유용하고 명확한 게시물에 대해 많은 감사를드립니다. –

+0

단어의 홀수 주소와 같이 부적절하게 정렬 된 데이터가 잘못된 아키텍처 (예 : M68000, PDP-11?)의 경우 D 컴파일러가 다중 단일 바이트 가져 오기 또는 저장? –

+0

@CecilWard AFAIK, 아니 D 컴파일러는 현재 이러한 아키텍처를 지원하며 공식 사양에는 많은 좋은 정보가 있지만 레퍼런스 컴파일러의 기능이 실제로 사양 (및 dmd는 x86/x86_64) 인 경우가 너무 많습니다. . 따라서 gdc 나 ldc에 문제가 발생하지 않았다면 논의되지 않았을 것입니다. 대답은 D 컴파일러가 해당 C 컴파일러가 무엇이든 상관없이 수행 할 것이라고 예상하지만 잘 모르겠습니다. –

관련 문제