KR101827143B1 - 객체의 바이너리 호환성을 유지하는 컴퓨팅 장치 및 방법 - Google Patents

Abstract

객체 인터페이스 내의 고정 위치에 포인터를 삽입하고, 상기 포인터에 의해 참조되는 복수의 계층적 구조를 갖는 함수 테이블을 포함하는 객체 모델을 생성하는 컴퓨팅 장치가 제공된다. 상기 컴퓨팅 장치는 프로세서를 포함할 수 있다. 상기 프로세서는 객체(object) 인터페이스 내의 미리 지정된 위치에 복수의 계층적 구조를 갖는 함수 테이블을 가리키는 포인터를 생성하고, 상기 포인터에 의해 참조되고, 상기 객체에 관한 함수 테이블을 가리키는 제1 주소 및 상기 객체를 상속하는 제1 인터페이스에 관한 함수 테이블을 가리키는 제2 주소를 포함하는 제1 계층 가상 함수 테이블을 생성하고, 상기 제1 주소 또는 제2 주소에 의해 참조되고, 상기 제1 인터페이스의 이름과 상기 제1 인터페이스가 상속한 제2 인터페이스의 이름에 따라 계산되는 해시(hash)를 포함하고, 상기 객체의 바이너리 호환성을 유지하는 제2 계층 가상 함수 테이블을 생성할 수 있다.

Description

객체의 바이너리 호환성을 유지하는 컴퓨팅 장치 및 방법{COMPUTING APPARATUS AND METHOD FOR PROTECTING BINARY COMPATIBILITY OF OBJECT}

객체의 바이너리 호환성을 유지하는 컴퓨팅 장치에 연관된다. 보다 구체적으로, C++ 언어에 대응하는 객체의 바이너리 호환성을 유지하는 컴퓨팅 장치에 연관된다.

오늘날 많은 소프트웨어들이 재활용성과 컴포넌트(component)들의 조립이 쉽다는 이유에서 컴포넌트 기반으로 개발되고 있다. 컴포넌트 기반의 소프트웨어들이 이용되는 경우, 사용자들은 소프트웨어 개발에 소용되는 비용과 시간을 줄일 수 있고, 조합을 통하여 새로운 소프트웨어를 쉽게 개발할 수 있다.

다만, 이러한 컴포넌트 기반의 소프트웨어들은 C++ 기반 컴포넌트의 바이너리 호환성이 제한될 수 있다. C++ 언어에서 변수, 함수, 클래스를 동적으로 공유하기 위해서는 C 언어 기반 동적 라이브러리 방식을 이용하거나 컴파일러에서 지원하는 공유 방식 중 하나를 이용할 수 있다. C 언어 기반 동적 라이브러리 방식은 클래스를 직접 공유할 순 없지만, 실행 파일과 동적 라이브러리가 동일한 헤더의 추상 클래스를 참조하고, 추상 클래스를 구현한 객체 인스턴스의 주소를 전달하여 간접적으로 클래스를 공유한다. 컴파일러가 지원하는 공유 방식에서 동적 라이브러리는 클래스를 공유할 수 있지만, 동일하지 않은 컴파일러 간에는 호환되지 않는다.

C++ 객체의 바이너리 호환성을 유지하기 위한 방법으로는 COM, CCC, DynObj, C++ 호환 맞춤형 언어인 ZL 등이 존재한다. COM의 경우, C++ 언어 등을 지원하지만 Windows 환경에서만 동작하고 컴파일러가 COM을 지원해야 하는 특징이 존재한다. 또한, CCC는 클래스가 헤더로만 구성된 라이브러리로 손쉽게 바이너리 호환성을 유지할 수 있는 C++ 코드의 작성을 지원할 수 있지만, C++ 11 표준을 지원하는 컴파일러에서만 사용할 수 있다는 특징이 있다. DynObj는 플러그인 형식으로 많이 사용되어 오랜 기간 사용 되었으나, 최신 컴파일러에서 정상적으로 동작하지 않는 경향이 존재한다. 또한, C++ 호환 맞춤형 언어인 ZL은 GCC에 대한 호환성만을 제공하고 다중 상속을 지원하지 않는다.

바이너리 호환성 문제는 객체의 메서드(method)를 제대로 호출하지 못하거나 심하게는 시스템을 죽이는 상황을 야기한다. 컴포넌트 간 바이너리 호환성 문제를 해결하기 위해 모든 컴파일러에서 호환될 수 있는 객체 구조가 필요하다.

이하에서 설명되는 실시예를 통해 C++ 기반 실행 파일과 동적 라이브러리 간 객체 공유를 위해서, BiCOMC(Binary Compatibility Object Model for C++)을 지원하는 컴퓨팅 장치 및 방법이 제공된다. 상기 컴퓨팅 장치는 BiCOMC을 이용하여 컴포넌트의 인터페이스와 메서드 오버로딩, 오버라이딩(overriding)과 예외 처리 등을 제공하고, 객체의 바이너리 호환성을 유지할 수 있다.

일측에 따르면, 객체 인터페이스 내의 고정 위치에 포인터를 삽입하고, 상기 포인터에 의해 참조되는 복수의 계층적 구조를 갖는 함수 테이블을 포함하는 객체 모델을 생성하는 컴퓨팅 장치가 제공된다. 상기 컴퓨팅 장치는 프로세서를 포함할 수 있다. 상기 프로세서는 객체(object) 인터페이스 내의 미리 지정된 위치에 복수의 계층적 구조를 갖는 함수 테이블을 가리키는 포인터를 생성하고, 상기 포인터에 의해 참조되고, 상기 객체에 관한 함수 테이블을 가리키는 제1 주소 및 상기 객체를 상속하는 제1 인터페이스에 관한 함수 테이블을 가리키는 제2 주소를 포함하는 제1 계층 가상 함수 테이블을 생성하고, 상기 제1 주소 또는 제2 주소에 의해 참조되고, 상기 제1 인터페이스의 이름과 상기 제1 인터페이스가 상속한 제2 인터페이스의 이름에 따라 계산되는 해시(hash)를 포함하고, 상기 객체의 바이너리 호환성을 유지하는 제2 계층 가상 함수 테이블을 생성할 수 있다.

일실시예에 따르면, 상기 제1 계층 가상 함수 테이블은 테이블은 상기 제1 인터페이스의 상속 횟수를 포함하는 뎁스(depth) 정보를 포함하는 것을 특징으로 할 수 있다.

다른 일실시예에 따르면, 상기 제1 계층 가상 함수 테이블은 상기 객체에 연관되는 버전 정보를 포함하고, 상기 버전 정보를 이용하여 상기 객체의 바이너리 호환성을 유지할 수 있다.

또 다른 일실시예에 따르면, 상기 제1 계층 가상 함수 테이블은 복수의 상기 제1 인터페이스 내의 메서드 선언 순서에 따라 순차적으로 배치된 복수의 상기 제2 주소를 포함할 수 있다.

또 다른 일실시예에 따르면, 상기 제2 계층 가상 함수 테이블은 상기 제1 인터페이스의 메서드 서명에 따라 계산되는 서브해시(subhash)를 포함하고, 상기 객체의 바이너리 호환성을 유지할 수 있다. 또한, 상기 제2 계층 가상 함수 테이블은 상기 제1 인터페이스에 연관되는 메서드의 이름, 상기 메서드의 반환 형태 및 상기 메서드의 파라미터 형태 중 적어도 하나를 상기 메서드 서명으로서 이용하여 계산되는 상기 서브해시를 포함할 수 있다.

다른 일측에 따르면, 복수의 포인터와 넥스트 오프셋(next offset)을 이용하여 구현되는 다중 상속을 지원하는 컴퓨팅 장치가 제공된다. 상기 컴퓨팅 장치는 프로세서를 포함할 수 있다. 상기 프로세서는 객체 인터페이스 내의 미리 지정된 위치에 상기 객체가 상속한 복수 개의 인터페이스 개수에 대응하는 복수 개의 포인터를 생성하고, 상기 복수 개의 포인터 중 제1 포인터에 의해 참조되고, 상기 객체에 관한 함수 테이블을 가리키는 제1 주소, 상기 객체를 상속하는 제1 인터페이스에 관한 함수 테이블을 가리키는 제2 주소 및 상기 제1 포인터 이후에 배치된 제2 포인터에 관한 위치를 나타내는 제1 넥스트 오프셋(next offset)을 포함하는 제1 계층 가상 함수 테이블을 생성하고, 상기 제1 주소 또는 제2 주소에 의해 참조되고, 상기 제1 인터페이스의 이름과 상기 제1 인터페이스가 상속한 제2 인터페이스의 이름에 따라 계산되는 해시(hash)를 포함하고, 상기 객체의 바이너리 호환성을 유지하는 제2 계층 가상 함수 테이블을 생성할 수 있다.

일실시예에 따르면, 상기 복수 개의 포인터 각각은 대응하는 인터페이스에 관한 복수의 계층적 구조를 갖는 함수 테이블을 가리킬 수 있다.

다른 일실시예에 따르면, 상기 프로세서는 상기 제2 포인터 이후에 배치된 포인터가 존재하지 않는 경우에, 상기 제2 포인터가 가리키는 상기 제1 계층 가상 함수 테이블 내의 제2 넥스트 오프셋이 상기 제1 포인터를 가리키도록 지정하는 것을 특징으로 할 수 있다. 또한, 상기 프로세서는 상기 제1 포인터의 위치에 대응하는 제1 바이트값에서 상기 제2 포인터의 위치에 대응하는 제2 바이트값을 제거한 음수를 상기 제2 넥스트 오프셋에 입력하는 것을 특징으로 할 수 있다.

또 다른 일실시예에 따르면, 상기 제1 계층 가상 함수 테이블은 상기 제1 인터페이스의 상속 횟수를 포함하는 뎁스(depth) 정보 및 상기 객체에 연관되는 버전 정보를 포함하고, 상기 버전 정보를 이용하여 상기 객체의 바이너리 호환성을 유지하는 것을 특징으로 할 수 있다.

도 1은 일실시예에 따른 객체 인터페이스의 클래스 다이어그램을 도시한다.
도 2는 일실시예에 따른 가상 함수 테이블의 구조를 도시하는 예시도이다.
도 3은 다른 일실시예에 따른 복수 개의 인터페이스를 상속한 객체 인터페이스의 가상 함수 테이블 구조를 도시하는 예시도이다.
도 4는 일실시예에 따른 컴포넌트의 클래스 다이어그램을 도시한다.
도 5는 일실시예에 따른 로봇 컴포넌트 구성의 예시도이다.

실시예들에 대한 특정한 구조적 또는 기능적 설명들은 단지 예시를 위한 목적으로 개시된 것으로서, 다양한 형태로 변경되어 실시될 수 있다. 따라서, 실시예들은 특정한 개시형태로 한정되는 것이 아니며, 본 명세서의 범위는 기술적 사상에 포함되는 변경, 균등물, 또는 대체물을 포함한다.

제1 또는 제2 등의 용어를 다양한 구성요소들을 설명하는데 사용될 수 있지만, 이런 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 해석되어야 한다. 예를 들어, 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소는 제1 구성요소로도 명명될 수 있다.

어떤 구성요소가 다른 구성요소에 "연결 되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다.

단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 설명된 특징, 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것이 존재함으로 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 해당 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가진다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미를 갖는 것으로 해석되어야 하며, 본 명세서에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

도 1은 일실시예에 따른 객체 인터페이스의 클래스 다이어그램을 도시한다.

도 1을 참조하면, 본 실시예에 따른 컴퓨팅 장치가 생성하는 객체(object) 인터페이스가 도시된다. 상기 객체 인터페이스는 퍼블릭 에어리어(public area) 내에서 공개되며, 여러 객체에서 사용될 수 있도록 멤버 변수를 포함하지 않을 수 있다. 일실시예로서, 상기 객체 인터페이스는 포인터 변수(또는 포인터)(vftptr)(110)를 포함할 수 있다. 보다 구체적으로, 객체 인터페이스는 가상 함수 테이블을 가리키는 포인터(110)를 포함할 수 있다. 상기 가상 함수 테이블은 객체 인터페이스에 의해 오버라이딩된 실제 메서드의 주소를 저장할 수 있다.

다른 일실시예로서, 객체 인터페이스는 객체에 의해 생성된 실행 코드로부터 해제 될 수 있도록 하는 destroy() 메서드를 포함할 수 있다. 객체를 공유하고 이용하는 과정에서, 객체를 생성하는 실행 코드(또는 실행 파일 또는 동적 라이브러리)와 해제하는 실행 코드가 상이할 수 있다. 예시적으로, 단순하게 C++의 delete 연산자를 이용해 객체를 해제하면, 상기 객체를 생성한 실행 코드로부터 메모리를 해제할 수 없기 때문에 정상적인 메모리 해제가 이루어지지 않을 수 있다. 따라서 본 실시예에 상응하는 컴퓨팅 장치는 객체 인터페이스 내에 destroy() 메서드를 포함시킬 수 있다.

또 다른 일실시예로서, 객체 인터페이스는 객체를 복제할 수 있도록 지원하는 clone() 메서드를 포함할 수 있다. 본 실시예에 따라 공유된 객체는 인터페이스 형태로 공개되기 때문에 객체의 원형을 알 수 없고, C++의 복사 생성자를 통한 복제를 할 수 있다. 따라서 본 실시예에 상응하는 컴퓨팅 장치는 객체 인터페이스 내에 clone() 메서드를 포함시킬 수 있다.

일실시예로서, 구현 클래스에서 인터페이스의 메서드를 오버라이딩하는 경우에, 가상 함수 테이블에 저장되는 메서드 주소의 순서는 선언 순서와 동일하게 관리될 수 있다. 그에 따라, 한번 공개된 인터페이스의 메서드 순서가 변경되는 것이 제한될 수 있다. 또한, 인터페이스에 메서드를 추가하는 것은 순서가 바뀌지 않는 범위 내에서만 허용될 수 있다.

또 다른 일실시예로서, 컴퓨팅 장치는 ErrorDetail 인터페이스(120)를 생성할 수 있다. 모든 메서드는 예외를 발생시킬 수 있다. 본 실시예의 경우에, 예외는 ErrorDetail 인터페이스(120)로 던져질 수 있다. ErrorDetail 인터페이스(120)는 오류 값을 가져오는 value(), 오류의 분류를 가져오는 category() 및 오류의 설명을 가져오는 message() 메서드 중 적어도 하나를 포함할 수 있다.

구현된 클래스는 인터페이스를 상속하여 구현되지 않은 메서드를 오버라이딩 할 수 있다. 하나의 가상 함수 테이블은 상속한 하나의 인터페이스의 내용을 포함할 수 있다. 가상 함수 테이블은 클래스 별로 고유한 영역에 생성되고, 동일한 인터페이스를 상속하는 서로 다른 클래스들은 서로 다른 가상 함수 테이블을 참조할 수 있다.

도 2는 일실시예에 따른 가상 함수 테이블의 구조를 도시하는 예시도이다.

도 2를 참조하면, 계층적 구조의 함수 테이블을 포함하는 가상 함수 테이블의 구조가 도시된다. 예시적으로, 가상 함수 테이블은 뎁스(depth) 정보, 버전(version) 정보, 넥스트 오프셋(next offset), 객체 함수 테이블(Object Function Table), 인터페이스 함수 테이블(Interface Function Table) 등을 포함하는 제1 계층 가상 함수 테이블(210) 및 해시(hash), 서브해시(subhash) 등을 포함하는 인터페이스 정보(interface information) 및 함수 주소를 포함하는 제2 계층 가상 함수 테이블(221, 222, 223)을 포함할 수 있다. 컴퓨팅 장치에 의해 생성되는 BiCOMC의 객체는 객체 인터페이스를 상속할 수 있다. 또한, 객체 인터페이스 내의 포인터(vftptr)는 가상 함수 테이블을 가리킬 수 있다. 본 실시예에 따른 가상 함수 테이블은 하나의 인터페이스에 대해 오버라이딩된 메서드 주소와 인터페이스 정보를 포함할 수 있다. 일실시예로서, 가상 함수 테이블 내의 한 행의 크기는 void*의 크기를 갖는 것으로 정의하자.

일실시예로서, 가상 함수 테이블은 객체로부터 현재의 인터페이스까지의 상속 횟수를 나타내는 뎁스(depth) 정보를 포함할 수 있다. 예시적으로, 구현된 클래스에서 직접 상속한 인터페이스가 객체 인터페이스이면 뎁스의 크기는 0이 될 수 있다.

다른 일실시예로서, 가상 함수 테이블은 객체에 연관되는 버전(version) 정보를 포함할 수 있다. 버전 정보에 따라 현재의 BiCOMC 버전과 추후 확장될 BiCOMC의 버전이 식별될 수 있다. 예시적으로, 동일한 버전을 갖는 객체는 상호 간에 호환성이 유지될 수 있다.

또 다른 일실시예로서, 넥스트 오프셋(next offset)은 인터페이스를 다중 상속한 객체에서 다른 가상 함수 테이블을 가리키는 포인터의 위치를 나타내는 값일 수 있다. 넥스트 오프셋에 관한 보다 자세한 설명은 다중 상속에서 가상 함수 테이블 구조를 나타내는 도면과 함께 기재될 것이다.

또 다른 일실시예로서, 객체 함수 테이블(Object FT 또는 Object Function Table)은 객체에 연관되는 메서드 주소가 저장되는 함수 테이블의 주소를 나타낼 수 있다. 본 실시예에서, 모든 인터페이스는 객체 인터페이스를 상속하기 때문에 가장 먼저 객체의 함수 테이블 주소가 가상 함수 테이블 내에서 위치할 수 있다. 상기 객체 인터페이스 이후에, 상속 순서에 따라 인터페이스의 함수 테이블 주소가 위치할 수 있다.

제2 계층 가상 함수 테이블(221, 222, 223)은 인터페이스 정보와 복수 개의 함수 주소를 포함할 수 있다. 일실시예로서, 제2 계층 가상 함수 테이블(221, 222, 223) 내에는 객체 함수 테이블에 연관되는 제2 계층 가상 함수 테이블(221)이 존재할 수 있다. 다른 일실시예로서, 제2 계층 가상 함수 테이블(222, 223) 내에는 인터페이스 함수 테이블에 연관되는 제2 계층 가상 함수 테이블(222, 223)이 존재할 수 있다. 인터페이스 함수 테이블에 연관되는 제2 계층 가상 함수 테이블(222, 223)은 오버라이딩된 메서드의 실제 주소와 인터페이스 정보를 포함할 수 있다. func. y-th addr.(y=1 … M)에는 메서드의 주소가 저장될 수 있다. 이 경우에, 메서드 주소는 메서드의 선언 순서와 동일한 순서로 저장될 수 있다.

또한, 제2 계층 가상 함수 테이블(221, 222, 223) 각각에 포함되는 인터페이스 정보(interface info. = interface information)에는 해시, 서브해시, 메서드의 개수, 메서드의 이름 및 메서드의 서명 정보 중 적어도 하나가 포함될 수 있다.

일실시예로서, 인터페이스 정보의 해시는 기설정된 비트의 해시 값을 나타낼 수 있다. 예시적으로, 상기 기설정된 비트는 64비트를 나타낼 수 있다. 해시는 인터페이스의 이름과 상속한 다른 인터페이스의 이름에 따라 계산될 수 있다. 예시적으로, 제1 인터페이스와 제2 인터페이스의 해시가 같다는 것은 인터페이스의 이름과 상속 관계가 동일한 것의 나타낼 수 있다.

다른 일실시예로서, 인터페이스 정보의 서브 해시는 기설정된 비트의 서브해시 값을 나타낼 수 있다. 마찬가지로, 상기 기설정된 비트는 64비트를 나타낼 수 있다. 서브해시는 인터페이스의 메서드 서명에 따라 계산될 수 있다. 보다 구체적으로, 상기 서브해시는 인터페이스의 메서드의 이름, 상기 메서드의 반환 형태, 상기 메서드의 파라미터 형태 중 적어도 하나를 이용하여 계산될 수 있다. 예시적으로, 서브 해시가 같다는 것은 인터페이스의 메서드 선언이 동일하다는 것을 나타낼 수 있다.

다만, 상기 해시와 상기 서브해시의 크기는 void*의 크기가 상이할 수 있다. 컴퓨팅 장치는 아래의 수학식 1에 따라 계산된 크기로서 공간을 할당하고, 낮은 주소로부터 기설정된 비트만큼 나누어 해시 공간 또는 서브해시 공간을 이용할 수 있다. 해시와 서브해시의 공간 뒤에 인터페이스 정보의 세 번째 행이 시작될 수 있다.

일실시예로서, func. count는 메서드의 개수를 나타낼 수 있다. 또한, interface name은 인터페이스의 이름을 나타낼 수 있다. 보다 구체적으로, 인터페이스 이름은 UTF-8 형식의 널로 끝나는(null-terminated) 문자열을 나타낼 수 있다.

다른 일실시예로서, func. y-th sig.(y=1, … , M)는 메서드의 선언 순서에 따른 메서드 서명이 위치하고, UTF-8 형식의 널로 끝나는 문자열을 나타낼 수 있다.

도 3은 다른 일실시예에 따른 복수 개의 인터페이스를 상속한 객체 인터페이스의 가상 함수 테이블 구조를 도시하는 예시도이다.

도 3을 참조하면, 복수의 포인터(311, 321, 331)를 포함하는 객체 인터페이스와 각각의 포인터(311, 321, 331)에 연관되는 가상 함수 테이블(312, 322, 332)이 도시된다. 예시적으로, 본 실시예에서는 세 개의 인터페이스를 다중 상속하는 객체의 가상 함수 테이블의 구조가 도시되지만, 해당 숫자는 다른 실시예의 범위를 제한하거나 한정하는 것으로 해석되어서는 안 될 것이다. 예시적으로, 두 개의 인터페이스를 다중 상속하는 객체의 가상 함수 테이블 또는 네 개 이상의 인터페이스를 다중 상속하는 객체의 가상 함수 테이블 또한 구현 가능한 실시예일 것이다.

본 실시예와 같이, 하나의 객체가 세 개의 인터페이스를 상속하는 경우에 객체 인터페이스 내에는 세 개의 포인터(311, 321, 331)가 존재할 수 있다. 낮은 주소에 존재하는 제1 포인터(311)가 가리키는 제1 가상 함수 테이블(312)은 순서상 가장 앞선 테이블을 나타낼 수 있다. 일실시예로서, 제1 가상 함수 테이블(312)의 기설정된 행에는 자신을 가리키는 제1 포인터(311)와 다음의 제2 포인터(321) 사이의 위치 차이를 나타내는 제1 넥스트 오프셋(313)이 포함될 수 있다. 보다 구체적으로, 본 실시예에서 제1 넥스트 오프셋(313)은 제1 포인터(311)와 제2 포인터(321)의 위치 차이에 해당되는 4를 저장할 수 있다. 또한, 제3 가상 함수 테이블(332) 내에 존재하는 제3 넥스트 오프셋(333)은 제3 포인터(313)와 가장 앞에 순서하는 제1 포인터(311)의 위치 차이에 대응하는 -8을 저장할 수 있다.

도 4는 일실시예에 따른 컴포넌트의 클래스 다이어그램을 도시한다.

도 4를 참고하면, 본 실시예의 BiCOMC에 따라 생성된 컴포넌트의 클래스 다이어그램이 도시된다. BiCOMC에 따라 생성된 객체는 컴파일러가 생성한 객체 구조와 다르기 때문에 종래의 static_cast나 dynamic_cast와 같은 캐스팅 방식으로는 정상적인 캐스팅을 수행하기 어려울 것이다. 그에 따라, BiCOMC 개체를 캐스팅할 수 있는 방법이 필요하다. 표 1에는 BiCOMC 객체를 다른 인터페이스로 캐스팅하는 예시적인 알고리즘이 도시된다.

1.	Target* cast(Object* object) {
2.	tTable =Target interface's virtual function table
3.	tDepth = targetTable[0]
4.	fcIndex = ceil(16 / sizeof(void*))
5.	p = object
6.	do {
7.	table = p->vftptr
8.	if (tTable[1] != table[1] || tDepth > table[0]) {
9.	p = p + table[2]
10.	continue
11.	}
12.	isCompatible = true
13.	for (i = 0; i < tDepth + 1; ++i) {
14.	tInfo = tTable[i + 3][0]
15.	info = table[i + 3][0]
16.	tCount = tInfo[fcIndex]
17.	if (tCount > info[fcIndex]) {
18.	isCompatible = false
19.	break
20.	}
21.	if (hash of tInfo != hash of info) {
22.	isCompatible = false
23.	break;
24.	}
25.	if (subhash of tInfo != subhash of info) {
26.	tSigs = tInfo[fcIndex + 1]
27.	sigs = info[fcIndex + 1]
28.	for (j = 0; j < tCount + 1; ++j) {
29.	if (strcmp(tSigs[j], sigs[j]) != 0) {
30.	isCompatible = false
31.	break
32.	}
33.	}
34.	if (!isCompatible) break
35.	}
36.	}
37.	if (isCompatible) return (Target*) p
38.	p = p + table[2]
39.	} while (p != object)
40.	return null
41.	}

상기 표 1에 도시된 캐스팅 방법은 객체 인터페이스 형으로 입력 받은 객체로부터 가상 함수 테이블을 가져오고, 캐스팅 목표 인터페이스의 가상 함수 테이블과 비교하여 호환 가능한 객체로 판단된 경우에 캐스팅하는 방식이 도시된다. 예시적으로, 호환이 되지 않는 객체일 경우에는 널(null)이 반환될 수 있다. 본 실시예에 따른 캐스팅 방법을 수행하는 컴퓨팅 장치는 인터페이스의 상속 관계에서 제일 하위에 있는 인터페이스부터 검사를 시작하여 최상위 인터페이스인 오브젝트 인터페이스까지 검사를 실행할 수 있다.

도 4에서 도시된 Comp_1의 클래스는 제1 인터페이스(410)와 제3 인터페이스(430)를 제공하는 컴포넌트의 하나일 수 있다. 제1 인터페이스(410)는 void mth_1(int), int mth_2()로 구성될 수 있다. 또한, 제3 인터페이스(430)는 제2 인터페이스(420)를 상속하고, void mth_1(), int mth_2(int)로 구성될 수 있다.

상기 표 1에 도시된 9 번째 라인 및 38 번째 라인에는 다중 상속을 위한 캐스팅 방법이 도시된다. 또한, 상기 표 1의 21 번째 라인에서부터 24 번째 라인에는 해시 값을 비교하여 인터페이스의 이름과 상속 관계를 검사하는 실시예가 도시된다. 상기 표 1의 25 번째 라인에서부터 35 번째 라인에는 서브해시를 비교하여 같을 경우에 호환 인터페이스로서 검출하고, 다를 경우에는 인터페이스 정보 내의 메서드 서명을 추가로 조회하여 호환 유무를 검사하는 실시예가 도시된다.

도 4에서 제1 인터페이스(410)와 제3 인터페이스(430)는 객체 인터페이스(440)를 상속한다. 본 실시예에서 사용된 인터페이스의 정의는 아래의 표 2와 같이 정의될 수 있다.

1.	BICOMC_INTERFACE(Interface_1)
2.	BICOMC_DECL_METHOD_1(mth_1, void(int));
3.	BICOMC_DECL_METHOD_0(mth_2, int());
4.	BICOMC_INTERFACE_END(Interface_1);
5.
6.	BICOMC_INTERFACE(Interface_2)
7.	BICOMC_DECL_METHOD_0(mth_1, void());
8.	BICOMC_INTERFACE_END(Interface_2)
9.
10.	BICOMC_INTERFACE(Interface_3, Interface_2)
11.	BICOMC_DECL_METHOD_1(mth_2, int(int));
12.	BICOMC_INTERFACE_END(Interface_3)

표 2의 BICOMC_INTERFACE 전처리 매크로는 인터페이스를 정의할 수 있고, 최대 2 개의 파라미터를 포함할 수 있다. 제1 파라미터는 인터페이스의 이름일 수 있다. 제2 파라미터는 인터페이스가 상속하려는 부모 인터페이스의 이름일 수 있다. 제2 파라미터가 생략된 경우, 상기 인터페이스는 객체 인터페이스를 기본으로 상속할 수 있다.

또한, 표 2의 BICOMC_DECL_METHOD_# 전처리 매크로는 인터페이스의 메서드를 선언하고, '#'는 메서드의 파라미터 수를 의미할 수 있다. 이 매크로는 2 개의 파라미터를 가지고, 제1 파라미터는 메서드의 이름, 제2 파라미터는 메서드의 함수 형태를 나타낼 수 있다.

아래의 표 3은 표 2에 따라 전처리된 C++ 코의 변환 과정을 나타낸다.

1.	class Interface_1 : public Object {
2.	...
3.	void mth_1(int p1) {
4.	void* r;
5.	if (ErrorDetail* e = vftptr[4][1](this, r, p1)
6.	throw e;
7.	}
8.	...
9.	int mth_2() {
10.	int r;
11.	if (ErrorDetail* e = vftptr[4][2](this, r))
12.	throw e;
13.	return r;
14.	}
15.	}
16.	...
17.	class Interface_3 : public Interface_2 {
18.	...
19.	int mth_2(int p1) {
20.	int r;
21.	if (ErrorDetail* e = vftptr[5][1](this, r, p1)
22.	throw e;
23.	return r;
24.	}
25.	}

표 2에서 설명된 인터페이스의 정의는 C++의 전처리 과정을 거쳐 표 3과 같이 C++ 코드로 변환된다. 상기 표 2의 BICOMC_INTERFACE 매크로는 입력된 인터페이스와 관련된 C++ 코드를 작성할 수 있다.

일실시예로서, 표 3의 1 번째 라인 및 17 번째 라인에 표시되어 있듯이, C++ 코드를 작성하는 컴퓨팅 장치는 class interface_1 및 class interface_3을 각각 생성하고, 제2 파라미터로 받은 부모 인터페이스를 상속하는 public object, public interface_2 코드를 생성할 수 있다.

또한, 상기 컴퓨팅 장치는 BICOMC_DECL_METHOD_# 매크로를 이용하여 입력된 이름, 반환형, 파라미터를 갖는 메서드를 작성할 수 있다. 상기 표 2의 2 번째 라인, 3 번째 라인 및 11 번째 라인 각각은 표 3의 3 번째 라인에서부터 7 번째 라인, 9 번째 라인에서부터 14 번째 라인 및 19 번째 라인으로부터 24번째 라인 각각으로 변환될 수 있다. 보다 구체적으로, 컴퓨팅 장치는 객체 인터페이스 내의 포인터가 가리키고 있는 가상 함수 테이블로부터 인터페이스의 상속 깊이와 인터페이스 메서드의 선언 순번을 획득하고, 상기 표 3의 5 번째 라인, 11 번째 라인 및 21 번째 라인과 같은 함수의 주소를 가져와 오버라이딩한 실제 메서드를 호출할 수 있다. 상기 메서드들은 아래의 표 4와 같은 함수 형으로 변환되어 저장될 수 있다.

ErrorDetail*(*)(I*, R*, P_1, P_2, ..., P_N)

상기 표 4에 기재된 함수 형에서 제1 파라미터 I*는 인터페이스 형의 객체 주소, 제2 파라미터 R*는 메서드의 반환 값을 받을 변수의 주소를 나타낼 수 있다. 그 외의 파라미터들(P_1, P_2, ..., P_N)은 메서드의 파라미터들을 나타낼 수 있다. 상기 함수 형으로 저장된 메서드는 동일한 함수 호출 규약으로 호출 되며, 호출 과정에서 발생하는 예외를 직접 던지지 않고 예외 정보를 ErrorDetail 인터페이스 형으로 반환할 수 있다. 상기 컴퓨팅 장치는 반환 받은 예외 정보를 상기 표 3의 6 번째 라인, 12 번째 라인 및 22 번째 라인과 같이 메서드의 C++ 코드에서 throw를 통해 던질 수 있다. 메서드를 호출한 코드에서는 try-catch 문을 이용하여 이러한 예외들을 처리할 수 있는 효과를 기대할 수 있다.

1.	class Comp_1 : public Interface_1 , public Interface_3 {
2.	BICOMC_OVERRIDE(Interface_1, Interface_3)
3.	BICOMC_OVER_METHOD(destroy, void());
4.	BICOMC_OVER_METHOD(mth_1, void());
5.	BICOMC_OVER_METHOD(mth_1, void(int));
6.	BICOMC_OVER_METHOD(mth_2, int());
7.	BICOMC_OVER_METHOD(mth_2, int(int));
8.	BICOMC_OVERRIDE_END()
9.	public:
10.	Comp_1() : BICOMC_OVERRIDE_INIT() { ... }
11.	void destroy() { delete this; }
12.	void mth_1() { ... }
13.	void mth_1(int p) { ... }
14.	int mth_2() { ... }
15.	int mth_2(int p1) { ... }
16.	};

상기 표 4는 상기 표 2를 구현한 형태의 일실시예이다. 본 실시예에 따른 컴퓨팅 장치는 상기 표 2의 인터페이스를 상속하여 Comp_1 클래스를 정의하고, 메서드를 오버라이딩할 수 있다. 인터페이스의 상속은 상기 표 1의 1 번째 라인과 같이 기본적인 C++의 상속 형식을 따를 수 있다. 상기 컴퓨팅 장치는 BICOMC_OVERRIDE와 BICOMC_OVER_METHOD 전처리 매크로를 이용하여 오버라이딩할 함수를 결정할 수 있다. 또한, BICOMC_OVERRIDE는 클래스가 상속하는 모든 인터페이스의 목록을 입력 받을 수 있다. 또한, BICOMC_OVER_METHOD는 클래스가 상속하는 모든 인터페이스의 목록을 입력 받을 수 있다. BICOMC_OVER_METHOD는 BICOMC_DECL_METHOD와 동일하게 메서드의 이름과 서명을 입력 받을 수 있다.

1.	class Comp_1 : public Interface_1 , public Interface_3 {
2.	...
3.	bool overrideMethod() {
4.	...
5.	typedef Comp_1 C;
6.	Interface_1::vftptr[3][1] = &Method<void(C::*)(), &destroy>::call;
7.	Interface_3::vftptr[3][1] = &Method<void(C::*)(), &destroy>::call;
8.	Interface_1::vftptr[4][1] = &Method<void(C::*)(int), &mth_1>::call;
9.	Interface_3::vftptr[4][1] = &Method<void(C::*)(), &mth_1>::call;
10.	Interface_1::vftptr[4][2] = &Method<int(C::*)(), &mth_2>::call;
11.	Interface_3::vftptr[5][1] = &Method<void(C::*)(int), &mth_2>::call;
12.	...
13.	}
14.	bool const holder;
15.	public:
16.	Comp_1() : holder(overrideMethod()) { ... }
17.	...
18.	};

매크로로 작성된 오버라이딩 표현은 C++ 전처리 과정을 거쳐 상기 표 6과 같이 C++ 코드로 변환될 수 있다. BICOMC_OVERRIDE는 overrideMethod()를 생성하게 되고, Comp_1의 객체가 생성될 때 한 번 호출되어 메서드를 오버라이딩할 수 있다. 상기 표 6의 3 번째 라인 내지 7 번째 라인과 같이 BICOMC_OVER_METHOD 매크로는 상기 표 6의 6 번째 라인 내지 11 번째 라인으로 변환될 수 있다. 상기 C++ 코드는 오버라이딩할 메서드가 선언된 인터페이스의 포인터가 가리키는 가상 함수 테이블에 구현 메서드를 상기 표 4와 같은 함수 형으로 변환하여 주소를 저장할 수 있다.

도 5는 일실시예에 따른 로봇 컴포넌트 구성의 예시도이다.

도 5를 참조하면, 로봇 컴포넌트는, 외부 물체를 움직일 수 있는 머니퓰레이터 컴포넌트(Manipulator Comp)(510), 로봇의 이동을 담당하는 모바일 컴포넌트(Mobile Comp)(520)와 두 컴포넌트들을 관리하는 제어 컴포넌트(App Comp)(530)로 구성될 수 있다. 머니퓰레이터 컴포넌트(510)는 GCC 5.2로 컴파일된 이후 머니퓰레이터를 제어할 수 있다. 또한, 모바일 컴포넌트(520)는 MSVC 14로 컴파일된 후 로봇의 이동 기능을 제어할 수 있다. 또한, 제어 컴포넌트(530)는 MSVC 10으로 컴파일 된 후, 모바일 컴포넌트(520)와 머니퓰레이터 컴포넌트(510)를 제어하면서 로봇의 동작을 관리할 수 있다. 제어 컴포넌트(530)는 모바일 컴포넌트(520)를 IMobile 인터페이스(521)로 접근하고, 머니퓰레이터 컴포넌트(510)를 IManipulator 인터페이스(511)로 접근할 수 있다. 상기 IMobile 인터페이스(521) 및 상기 IManipulator 인터페이스(511)의 정의는 아래의 표 7과 같이 정의될 수 있다.

1.	BICOMC_INTERFACE(IMobile)
2.	BICOMC_DECL_METHOD_1(stop, void(int mode))
3.	BICOMC_DECL_METHOD_2(move , void(double xPos, double yPos))
4.	...
5.	BICOMC_INTERFACE_END(IMobile)
6.
7.	BICOMC_INETERFACE(IManipulator)
8.	BICOMC_DECL_METHOD_1(stop, void(int mode))
9.	BICOMC_DECL_METHOD_3(move , void(double const* angles , double const* times, int size))
10.	...
11.	BICOMC_INETERFACE_END(IManipulator)

상기 표 7과 같이, IMobile은 로봇의 이동을 제어하기 위한 인터페이스로 stop(), move() 등의 메서드를 정의하고 있다. IManipulator는 로봇의 머니퓰레이터를 움직이기 위한 인터페이스로 stop(), move() 등의 메서드가 선언될 수 있다.

아래의 표 8에는 상기 표 7의 인터페이스를 활용하여 컴포넌트인 MobileComp를 정의한 알고리즘이 도시된다.

1.	class MobileComp : public IMobile {
2.	BICOMC_OVERRIDE(IMobile)
3.	BICOMC_OVER_METHOD(stop, void(int mode))
4.	BICOMC_OVER_METHOD(move, void(double xPos, double yPos))
5.	…
6.	BICOMC_OVERRIDE_END()
7.	…
8.	void stop(int mode) { ... }
9.	void move(float x, float y) { ... }
10.	void drive(float x, float y) {...}
11.	};

상기 표 8을 참조하면, IMobile을 상속한 뒤, BICOMC_OVERRIDE 매크로를 통해 오버라이딩할 stop(), move() 등이 명시된다. 상기 표 8에서 도시된 알고리즘과 유사한 방법에 따라, Manipulator Comp 역시 아래의 표 9와 같이 정의될 수 있다.

1.	class ManipulatorComp : public IManipulator {
2.	BICOMC_OVERRIDE(IManipulator)
3.	BICOMC_OVER_METHOD(stop, void(int mode))
4.	BICOMC_OVER_METHOD(move, void(double const* angles, double const* times, int size))
5.	BICOMC_OVER_METHOD(drive, void(double const* angles, double const* times, int size))
6.	BICOMC_OVERRIDE_END()
7.	...
8.	void stop(int mode) { ... }
9.	void move(double const* angles, double const* times, int size) { ... }
10.	void drive(double const* angles, double const* times, int size) {...}
11.	};

또한, 본 실시예에 따른 BiCOMC을 이용하는 컴퓨팅 장치는 아래의 표 10과 같이 제어 컴포넌트(530)를 정의할 수 있다.

1.	class AppComp {
2.	IMobile* pMobile
3.	IManipulator* pManipulator
4.	…
5.	void main() {
6.	pMobile->drive(0.5, 0.0);
7.	...
8.	pManipulator->stop(0);
9.	...
10.	}
11.	};

제어 컴포넌트(530)는 머니퓰레이터 컴포넌트(510)와 모바일 컴포넌트(520)를 사용하기 위해 IMobile 및 IManipulator 인터페이스 형 변수를 선언할 수 있다. pMobile 포인터에 실제 모바일 컴포넌트(520)의 주소를 저장하고, 마찬가지로 pManipulator 포인터에 머니퓰레이터 컴포넌트(510)의 주소를 저장할 수 있다. 그에 따라, 제어 컴포넌트(530)는 저장된 pMobile과 pManipulator 변수의 메서드를 호출하여 해당 컴포넌트의 기능을 이용할 수 있다.

본 실시예에 따를 때, C++ 기반 실행 파일과 동적 라이브러리 간 객체 공유를 지원하는 BiCOMC(Binary Compatibility Object Model for C++)이 제공될 수 있다. BiCOMC을 지원하는 컴퓨팅 장치는 컴포넌트의 인터페이스와 메서드의 오버로딩, 오버라이딩 및 예외 처리를 지원할 수 있다. 종래 방식과 대비할 때 컴파일러 간의 상호 호환성을 높일 수 있고, 또한 런타임 시 호출 시간이 개선되는 효과를 기대할 수 있다.

이상에서 설명된 실시예들은 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치, 방법 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPGA(field programmable gate array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 애플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치, 또는 전송되는 신호 파(signal wave)에 영구적으로, 또는 일시적으로 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 실시예의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.

이상과 같이 실시예들이 비록 한정된 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기를 기초로 다양한 기술적 수정 및 변형을 적용할 수 있다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.

Claims (13)

1. 프로세서를 포함하고, 상기 프로세서는:
   객체(object) 인터페이스 내의 함수 테이블을 가리키는 포인터와 ErrorDetail 인터페이스를 생성하고,
   상기 포인터에 의해 참조되고, 상기 객체에 관한 함수 테이블을 가리키는 제1 주소 및 상기 객체를 상속하는 제1 인터페이스에 관한 함수 테이블을 가리키는 제2 주소를 포함하는 제1 계층 가상 함수 테이블을 생성하고,
   상기 제1 주소 또는 제2 주소에 의해 참조되고, 상기 제1 인터페이스의 이름과 상기 제1 인터페이스가 상속한 제2 인터페이스의 이름에 따라 계산되는 해시(hash), 메서드의 선언 순서에 따라 생성되는 복수의 메서드 서명 및 상기 제1 인터페이스 내의 복수의 메서드 서명에 따라 계산되는 서브해시(subhash)를 포함하고, 상기 객체의 바이너리 호환성을 유지하는 제2 계층 가상 함수 테이블을 생성하고,
   상기 객체의 바이너리 호환성을 유지하기 위해 상기 서브해시를 비교하고, 상기 복수의 메서드 서명을 조회하여 호환 유무를 검사하고,
   상기 ErrorDetail 인터페이스는 적어도 하나의 메서드로부터 생성된 예외가 반환되고, 상기 적어도 하나의 메서드로부터 오류 값을 가져오는 value(), 오류의 분류를 가져오는 category() 및 오류의 설명을 가져오는 message() 메서드 중 적어도 하나를 포함하는 컴퓨팅 장치.
2. 제1항에 있어서,
   상기 제1 계층 가상 함수 테이블은 상기 제1 인터페이스의 상속 횟수를 포함하는 뎁스(depth) 정보를 포함하는 것을 특징으로 하는 컴퓨팅 장치.
   
3. 제1항에 있어서,
   상기 제1 계층 가상 함수 테이블은 상기 객체에 연관되는 버전 정보를 포함하고, 상기 버전 정보를 이용하여 상기 객체의 바이너리 호환성을 유지하는 것을 특징으로 하는 컴퓨팅 장치.
   
4. 삭제
5. 제1항에 있어서,
   상기 제2 계층 가상 함수 테이블은 상기 제1 인터페이스에 연관되는 메서드의 이름, 상기 메서드의 반환 형태 및 상기 메서드의 파라미터 형태 중 적어도 하나를 상기 메서드 서명으로서 이용하여 계산되는 상기 서브해시를 포함하는 것을 특징으로 하는 컴퓨팅 장치.
   
6. 제1항에 있어서,
   상기 제1 계층 가상 함수 테이블은 복수의 상기 제1 인터페이스 내의 메서드 선언 순서에 따라 순차적으로 배치된 복수의 상기 제2 주소를 포함하는 컴퓨팅 장치.
   
7. 프로세서를 포함하고, 상기 프로세서는:
   객체 인터페이스 내에 상기 객체가 다중상속한 복수 개의 인터페이스 개수에 대응하는 복수 개의 포인터를 생성하고,
   상기 복수 개의 포인터 중 제1 포인터에 의해 참조되고, 상기 객체에 관한 함수 테이블을 가리키는 제1 주소, 상기 객체를 상속하는 제1 인터페이스에 관한 함수 테이블을 가리키는 제2 주소 및 상기 제1 포인터 이후에 배치된 제2 포인터에 관한 위치를 나타내는 제1 넥스트 오프셋(next offset)을 포함하는 제1 계층 가상 함수 테이블을 생성하고,
   상기 제1 주소 또는 제2 주소에 의해 참조되고, 상기 제1 인터페이스의 이름과 상기 제1 인터페이스가 상속한 제2 인터페이스의 이름에 따라 계산되는 해시(hash)를 포함하고, 상기 객체의 바이너리 호환성을 유지하는 제2 계층 가상 함수 테이블을 생성하고,
   상기 제1 포인터의 위치에 대응하는 제1 바이트값에서 상기 제2 포인터의 위치에 대응하는 제2 바이트값을 제거한 음수를 제2 넥스트 오프셋에 입력하고,
   상기 제2 포인터 이후에 배치된 포인터가 존재하지 않는 경우에 상기 제2 포인터가 가리키는 상기 제1 계층 가상 함수 테이블 내의 상기 제2 넥스트 오프셋이 상기 제1 포인터를 가리키도록 지정하는 컴퓨팅 장치.
   
8. 제7항에 있어서,
   상기 복수 개의 포인터 각각은 대응하는 인터페이스에 관한 복수의 계층적 구조를 갖는 함수 테이블을 가리키는 것을 특징으로 하는 컴퓨팅 장치.
   
9. 삭제
10. 삭제
11. 제7항에 있어서,
    상기 제2 계층 가상 함수 테이블은 상기 제1 인터페이스의 메서드 서명에 따라 계산되는 서브해시(subhash)를 포함하고, 상기 객체의 바이너리 호환성을 유지하는 것을 특징으로 하는 컴퓨팅 장치.
    
12. 제11항에 있어서,
    상기 제2 계층 가상 함수 테이블은 상기 제1 인터페이스에 연관되는 메서드의 이름, 상기 메서드의 반환 형태 및 상기 메서드의 파라미터 형태 중 적어도 하나를 상기 메서드 서명으로서 이용하여 계산되는 상기 서브해시를 포함하는 것을 특징으로 하는 컴퓨팅 장치.
    
13. 제7항에 있어서,
    상기 제1 계층 가상 함수 테이블은 상기 제1 인터페이스의 상속 횟수를 포함하는 뎁스(depth) 정보 및 상기 객체에 연관되는 버전 정보를 포함하고, 상기 버전 정보를 이용하여 상기 객체의 바이너리 호환성을 유지하는 것을 특징으로 하는 컴퓨팅 장치.

Images