18-1-마.구조체의 정렬
구조체의 멤버들은 선언된 순서대로 인접한 번지에 배치된다. 첫 번째 멤버가 오프셋 0에 오고 두 번째 멤버가 첫 번째 멤버의 길이만큼 뒤쪽의 오프셋에 자리를 잡는 식이다. 그래서 구조체의 총 크기는 구조체에 속한 멤버들의 총 크기와 같다. 과연 그런지 다음 예제로 테스트해 보자.
|
예 제 : StructAlign |
#include <Turboc.h>
struct tag_st1
{
char c;
double d;
};
tag_st1 st1={'A',1.234};
void main()
{
printf("addr=%p, &c=%p, &d=%p, size=%d\n",&st1,&st1.c,&st1.d,sizeof(st1));
}
tag_st1 구조체에는 1바이트의 문자형 멤버 하나와 8바이트의 실수형 멤버 하나가 포함되어 있으며 그래서 구조체의 총 크기는 9바이트가 되어야 한다. 그러나 sizeof연산자로 st1 구조체의 실제 크기를 조사해 보면 16바이트라는 결과가 나온다. 어째서 이런 결과가 나오는 것일까? 그 이유는 물리적인 기계의 성능을 최대한 끌어 올리기 위해서 컴파일러가 구조체를 메모리에 배치할 때 두 가지 사항을 고려하여 번지를 잡기 때문이다.
첫 번째로 구조체가 시작될 번지(base)를 고를 때 가급적이면 16바이트 경계에서 시작하도록 한다. 왜냐하면 최신 CPU들은 속도 증가를 위해 캐시를 사용하는데 캐시의 단위가 16바이트로 되어 있기 때문이다. 캐시 크기의 배수 위치에 구조체를 배치하면 이 구조체를 자주 액세스할 때 캐시 용량을 덜 차지하면서도 빠르게 액세스할 수 있다. 만약 16바이트 경계의 양쪽에 걸치게 되면 캐시도 많이 차지할 뿐더러 액세스 속도도 느려질 것이다.
두 번째로 구조체의 멤버를 배치할 때 멤버의 오프셋도 액세스하기 유리한 위치로 조정한다. 별다른 지정이 없으면 멤버의 크기에 따라 자연스러운 경계 위치에 맞추도록 되어 있는데 예를 들어 int는 4바이트, double은 8바이트 경계에 맞춘다. 그래서 위 예제의 경우 c가 1바이트를 차지하고 난 후 d는 다음 8바이트 경계에 배치되므로 c와 d사이에 7바이트는 버려지고 사용되지 않는다. 이렇게 사용되지 않고 버려지는 공간을 패딩(Padding) 이라고 한다.
설사 두 멤버의 순서를 바꾸어서 d를 먼저 배치하고 c를 뒤에 배치해도 마찬가지로 c뒤쪽의 7바이트가 버려진다. c위치에서 구조체가 끝나므로 이 경우는 굳이 패딩을 쓰지 않아도 될 것 같지만 이렇게 할 경우 구조체의 배열을 만들 때 두 번째 요소의 d가 8바이트 경계에 올 수 없을 것이다. 배열의 첨자 연산이 가능하기 위해서는 배열 요소는 인접해 있어야 한다. 그래서 요소 사이에 패딩을 넣지 못하며 구조체 내부에 패딩을 둘 수밖에 없다.
컴파일러는 CPU가 메모리를 최대한 빠른 속도로 액세스할 수 있도록 구조체의 베이스와 멤버의 오프셋을 조정해서 배치하는데 이를 구조체의 정렬(alignment)이라고 한다. 자료를 크기순으로 나열하는 정렬(Sort)과는 번역만 같으며 뜻은 다르다. 개발자들은 일반적으로 구조체의 정렬 방식에 대해 몰라도 별 문제가 없다. 왜냐하면 변수가 어떤 메모리에 배치되는가는 원칙적으로 컴파일러 마음이며 개발자는 변수명으로 그 번지의 내용을 읽고 쓰기 때문이다. 또한 멤버의 오프셋이 어떻게 설정되든간에 코드에서는 st1.c, st1.d 연산문으로 멤버를 액세스할 수 있으며 . 연산자는 컴파일러가 정한 오프셋을 정확하게 찾아 준다.
구조체의 정렬 기능에 의해 액세스 속도는 빨라지지만 효율을 위해 버려지는 메모리가 있다는 점이 다소 안타까워 보일 것이다. 그러나 위의 tag_st1은 이런 효과를 극대화해서 보여주기 위해 1바이트 멤버 다음에 8바이트 멤버를 의도적으로 배치했을 뿐이지 현실적으로 구조체의 멤버들은 대부분 int, unsigned, char [ ] 등이기 때문에 걱정하는 것만큼 메모리가 낭비되지는 않는다.
만약 메모리를 꼭 절약하고 싶다면 예를 들어 tag_st1 arst[10000] 따위의 큰 배열을 만들어야 한다면 옵션을 조정하여 구조체의 정렬 방식을 변경할 수 있다. 비주얼 C++ 6.0의 경우 프로젝트 설정 대화상자의 C/C++ 탭에서 Code Generation 카테고리를 선택하면 아래쪽에 Struct member alignment라는 옵션을 볼 수 있다.
디폴트는 8바이트 단위로 정렬하도록 되어 있으며 1, 2, 4, 8, 16 등 2의 거듭승으로 정렬값을 변경할 수 있다. 비주얼 C++ 7.0의 경우도 비슷한 위치에서 이 옵션을 찾을 수 있으며 gcc 등의 명령행 컴파일러들도 관련 옵션을 모두 제공한다. 컴파일러 옵션이 한글화되어 있지만 그렇다고 해서 이 옵션들이 쉬워지지는 않는 것 같다.
컴파일러는 이 옵션에서 지정한 정렬값 n과 멤버의 크기값 중 작은 쪽에 맞추어 두 번째 멤버 이후의 오프셋을 결정한다. 물론 첫 번째 멤버는 항상 오프셋 0인 구조체 선두 번지에서 시작한다. 이 옵션을 바꿔 가며 위 예제를 다시 컴파일해 보면 정렬값 n에 따라 구조체의 크기와 두 번째 멤버의 시작 번지가 달라지는 것을 확인할 수 있다.
|
정렬값 |
결과 |
|
1 |
addr=00426A30, &c=00426A30, &d=00426A31, size=9 |
|
2 |
addr=00426A30, &c=00426A30, &d=00426A32, size=10 |
|
4 |
addr=00426A30, &c=00426A30, &d=00426A34, size=12 |
|
8 |
addr=00426A30, &c=00426A30, &d=00426A38, size=16 |
|
16 |
addr=00426A30, &c=00426A30, &d=00426A38, size=16 |
정렬값에 따라 st1 구조체가 메모리에 어떻게 배치되는지 그려 보자.
정렬값을 1로 주면 모든 멤버를 1바이트의 경계에 맞춤으로써 정렬을 하지 않게 되며 따라서 구조체의 크기는 멤버의 크기와 정확하게 같아진다. 정렬값이 2인 경우 두 번째 멤버 d가 2바이트의 배수 위치에 오도록 하기 위해 c다음의 1바이트를 버리며 4인 경우는 3바이트가 버려지고 8인 경우 7바이트를 버린다. 정렬값이 16인 경우는 정렬값보다 d의 크기 8이 더 작으므로 8의 배수에 맞춰지고 정렬값이 8인 경우와 같아진다.
구조체 정렬 기능에 의해 멤버들이 구조체 내의 어느 오프셋에 배치될지는 미리 예측하기 어렵다. 설사 계산 가능하다 하더라도 옵션을 바꾸면 오프셋이 다시 바뀔 수 있으므로 암산으로 계산한 오프셋을 사용하는 것은 바람직하지 않다. 만약 특정 멤버가 배치된 오프셋을 조사하고 싶다면 stddef.h에 다음과 같이 정의되어 있는 offsetof 매크로 함수를 사용한다.
#define offsetof(s,m) (size_t)&(((s *)0)->m)
첫 번째 인수로 구조체, 두 번째 인수로 멤버의 이름을 주면 이 멤버가 실제로 배치된 오프셋을 리턴한다. 어째서 그렇게 되는지는 매크로 내용을 직접 분석해 보아라. 다음 예제로 이 매크로의 동작을 테스트해 보자.
|
예 제 : offsetof |
#include <Turboc.h>
#include <stddef.h>
void main()
{
struct Node {
int a;
double b;
char c[16];
Node *prev;
Node *next;
};
Node A, B;
printf("a의 오프셋 = %d\n",offsetof(Node,a));
printf("b의 오프셋 = %d\n",offsetof(Node,b));
printf("c의 오프셋 = %d\n",offsetof(Node,c));
printf("prev의 오프셋 = %d\n",offsetof(Node,prev));
printf("next의 오프셋 = %d\n",offsetof(Node,next));
}
실행 결과는 다음과 같다.
a의 오프셋 = 0
b의 오프셋 = 8
c의 오프셋 = 16
prev의 오프셋 = 32
next의 오프셋 = 36
만약 구조체 전체가 아니라 특정 멤버 앞쪽의 멤버만 복사하고 싶다면 이 멤버의 오프셋을 알아야 하는데 이때 offsetof 매크로가 유용하게 사용된다. 예를 들어 A 구조체의 링크 정보는 빼고 실제 데이터만 B로 복사하고 싶다면 memcpy(&B,&A,offsetof(Node,prev)); 하면 된다.
현대의 컴퓨터 환경에서 메모리는 아주 흔한 자원이 되어 버렸으며 그래서 속도를 위해서라면 메모리 얼마쯤을 버리는 것은 크게 문제 삼지 않는 분위기이다. 최신 컴파일러들의 최적화 옵션은 가급적 속도를 높이는 쪽으로 맞춰져 있으며 구조체를 정렬하는 것도 속도를 높이기 위한 방편중의 하나로 이해하면 된다. 컴파일러 내부에서 일어나는 일이므로 신경쓰고 싶지 않다면 알아서 잘 하겠거니라고 생각해도 무방하되 단 sizeof(st1)이 꼭 9가 아닐 수도 있다는 것 정도는 상식적으로 알아 두도록 하자.
구조체의 크기를 꼭 알아야 하는 경우는 사실 그리 흔하지 않다. 물론 아주 가끔이기는 하지만 정렬된 크기를 정확하게 알아야 하는 경우도 있다. 이런 경우 쓰라고 만들어 놓은 연산자가 바로 sizeof 연산자이다. 구조체의 크기가 필요하면 반드시 sizeof 연산자를 사용해야 하며 구조체가 간단하다고 해서 대충 암산으로 구한 상수를 바로 쓰는 것은 지극히 위험하다.