표준적인 C++의 클래스에 가상함수가 있다면
컴파일러는 그 클래스 객체의 맨 앞 4Byte가 가상함수테이블(VTable)을 가리키도록 만듭니다.
그래서 가상함수가 있는 클래스라면 맨처음 4바이트가 특별한 용도로 쓰이며
이 4바이트는 클래스의 크기에 부가되는 것입니다.
그러면 가상함수 테이블은 가상함수가 쓰인 순서대로 가상함수를 가리키는 포인트 4Byte가
가상함수 갯수만큼 존재하게 됩니다.

TObject는 표준적인 C++ 클래스가 아니라 델파이와의 호환성과 VCL을 위해서 존재하는
클래스의 가장 뿌리가 되는 조상입니다.
TObject에도 8개 정도의 가상함수가 존재합니다.
대표적으로 TObject의 소멸자 자체가
virtual __fastcall ~TObject();
식으로 가상함수로 존재합니다.

하지만 TObject와 같은 델파이 VCL의 호환성을 위해 존재하는, 즉 코드기어에 의해
이미 존재하는 클래스는 가상함수가 표준적인 C++클래스와 같은 방법으로 놓이지 않습니다.
새로 사용자가 부가하는 가상함수를 위해 자리를 비워놓고 있어야 하기 때문에
실제로 TObject의 자손들은 객체가 가르키는 첫번째 번지에 있는 가상함수 테이블을 가리키는 포인트를
주소를 보면, 가상함수 번지 리스트가 그 번지 밑으로 존재하게 됩니다.
다시 말해 TObject 경우 가상함수 테이블 번지에는 아무것도 없고 그 밑에 번지에
가상함수가 선언된 순서대로 놓여 있게 되는 구조를 가지고 있습니다.
이는 델파이 쪽도 같습니다.

만일 VCL 스타일 클래스라 하더라도 사용자가 새로 정의하는 virtual 함수는
표준적인 C++처럼 가상함수테이블의 시작번지부터 존재하게 됩니다.

이렇게 특이한 처리를 하는 이유는 COM Interface 때문입니다.
즉 COM이 VCL 클래스를 상속받아 만들어도 성립되게 하려면, 이런 식의 처리를 하지 않을 수 없는 이유입니다.
그래서 델파이의 경우 모든 클래스는 강제적으로 TObect의 자손이어야 함에도
TObject에서 상속받지 않은 표준적인 C++클래스와 호환을 유지할 수 있습니다.

빌더나 델파이 컴파일러는 델파이 클래스에 대해 이러한 특별한 처리를 따로 하고 있습니다.


ps. 팁이라고 하기는 거시기한데, 까먹을까봐 올려둡니다.