2015. 11. 11. 00:48

Policies/Binary Compatibility Issues With C++ (C++ 에서 이진 호환성 문제들) - 1

Policies/Binary Compatibility Issues With C++ - 1

출처 : https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#Definition

Definition (정의)

A library is binary compatible, if a program linked dynamically to a former version of the library continues running with newer versions of the library without the need to recompile.

재컴파일할 필요 없이 이전 버전의 라이브러리에서 새 버전의 라이브러리를 동적으로 연결할 수 있다면, 그 라이브러리는 이진 호환성(바이너리 컴패터빌리티) 이 있다고 합니다.

If a program needs to be recompiled to run with a new version of library but doesn't require any further modifications, the library is source compatible.

만약 재컴파일은 필요로 하지만, 어떠한 수정 없이도 새 버전의 라이브러리를 만들어서 실행할 수 있다면, 그 라이브러리는 소스 호환성 (소스 컴패터빌리티) 이 있다고 합니다.

Binary compatibility saves a lot of trouble. It makes it much easier to distribute software for a certain platform. Without ensuring binary compatibility between releases, people will be forced to provide statically linked binaries. Static binaries are bad because they

이진 호환성은 많은 문제점들을 덜어 줍니다. 특정 플랫폼을 위한 소프트웨어를 배포하는 작업이 쉬워 집니다. 출시 제품들간에 이진 호환성을 보장하지 않고서는, 사람들은 정적(스태틱) 으로 연결된 라이브러리 제공해야만 할 것입니다. 정적 라이브러리는 좋지 않는데 그 이유는

  • waste resources (especially memory)
    자원을 낭비합니다. (특히 메모리)
  • don't allow the program to benefit from bugfixes or extensions in the libraries
    프로그램이 라이브러리의 문제 수정이나 확장성에서 잇점을 얻는 것을 허용하지 않습니다.

In the KDE project, we will provide binary compatibility within the life-span of a major release for the core libraries (kdelibs, kdepimlibs).

KDE 프로젝트에서는, 우리는 핵심 라이브러리(kdelibs, kdepimlibs) 에 대해 운영 기한(수명) 내의 중요 버전들에 대해서는 이진 호환성을 제공할 것입니다.

Note about ABI (ABI 에 관한 참고)

This text applies to most C++ ABIs used by compilers which KDE can be built with. It is mostly based on the Itanium C++ ABI Draft, which is used by the GCC C++ compiler since version 3.4 in all platforms it supports. Information about Microsoft Visual C++ mangling scheme mostly comes from this article on calling conventions (it's the most complete information found so far on MSVC ABI and name mangling).

이 글은 KDE 를 만드는 컴파일러에 의해 새용되는 대부분의 C++ ABI (응용프로그램 이진 인터페이스)들에 해당됩니다. 거의 모든 플랫폼을 지원하는 GCC C++ 컴파일러 버전 3.4 이상을 이용하는 아이테니엄 C++ ABI 원고의 내용에 기반 합니다. 마이크로소프트 비주얼 C++ 맹글링 스킴(임의로 이름을 변경하는 규칙)에 대한 정보는 이 글의 호출 규약에서 유래합니다. (MSVC ABI 과 네임 맹글링에 대해서는 현재까지 가장 완벽한 정보 입니다.)

Some of the constraints specified here may not apply to a given compiler. The goal here is to list the most restrictive set of conditions when writing cross-platform C++ code, meant to be compiled with several different compilers.

여기에 명시된 제약의 일부는 사용하는 컴파일러에 적용되지 않을 수 있습니다. 이 글의 목적은 크로스-플랫폼 C++ 을 작성할 때, 몇몇 다른 컴파일러들에 의해 컴파일 될 수 있게 하기 위한 대부분의 제약 사항들의 묶음 입니다.

This page is updated when new binary incompatibility issues are found.

이 문서는 새로운 이진 비호환성 문제가 발견되면 갱신 됩니다.

The Do's and Don'ts / 해도 되는 것과 하면 안 되는 것들

You can...

당신은 아래의 것들을 할 수 있습니다... (준수 사항)

  • add new non-virtual functions including signals and slots and constructors.
    시그널과 슬롯 그리고 생성자를 포함하는 비-가상 함수들을 추가
  • add a new enum to a class.
    클래스에 새로운 열거형 변수 추가
  • append new enumerators to an existing enum.
    존재하는 열거형 변수 목록에 새 열거자 추가
    • Exception: if that leads to the compiler choosing a larger underlying type for the enum, that makes the change binary-incompatible. Unfortunately, compilers have some leeway to choose the underlying type, so from an API-design perspective it's recommended to add a Max.... enumerator with an explicit large value (=255=1<<15, etc) to create an interval of numeric enumerator values that is guaranteed to fit into the chosen underlying type, whatever that may be.
      예외 : 열거형 변수에 대해 내재된 형태보다 더 큰 범위로 컴파일러가 선택하게 한다면, 이는 이진-비호환성으로 만들 것입니다. 불행히도 컴파일러들은 내재된 형태의 범위를 자유롭게 발꿀 수 있으므로, API-설계 관점에서 어떠한 값이 들어와도 주어진 내재된 형태의 범위내 값이 들어갈 수 있음을 보장하기 위해, 명시적으로 큰 값(=255, =1<<15 등) 을 넣는 방법으로 최대값(Max) 을 추가하는 것이 권장됩니다.
  • reimplement virtual functions defined in the primary base class hierarchy (that is, virtuals defined in the first non-virtual base class, or in that class's first non-virtual base class, and so forth) if it is safe that programs linked with the prior version of the library call the implementation in the base class rather than the derived one. This is tricky and might be dangerous. Think twice before doing it. Alternatively see below for a workaround.
    1차 부모 클래스 구조에서 정의된 가상 함수를 재정의 (다시 말해, 첫 비-가상 부모 클래스에서 정의된 가상 함수들 또는 그 클래스의 첫 비-가상 부모 클래스의 가상 함수들, 그리고 반복...), 만약 상속 받은 클래스보다 부모 클래스 내의 구현물(함수) 을 호출하는 이전 버전의 라이브러리와 링크하는 것이 안전하다면, 이것은 영리한 방법이나 문제가 될 수 있습니다. 작업을 하기 전에 한번 더 생각하시기 바랍니다. 대안으로 다음의 제2 해결책을 참고하시기 바랍니다.

    • Exception: if the overriding function has a covariant return type, it's only a binary-compatible change if the more-derived type has always the same pointer address as the less-derived one. If in doubt, do not override with a covariant return type.
      예외 : 만약 오버라이드 함수가 공변 반환 형식(부모 클래스의 메소드를 자식 클래스에서 오버라이드 할 때 반환 자료 형을 자식 클래스의 형태가 아닌 부모 클래스 메소드의 반환형을 상속 받는 자료형으로 사용해도 된다는 성질)을 가진다면, 더-상속 받은 자료형이 덜 상속받은 자료형과 같은 포인터 주소를 가질 때에만 이진-호환성을 가진 변경이 됩니다. 작업에 의심이 간다면, 공변 반환 형식으로 오버라이드 하지 마시기 바랍니다.
  • change an inline function or make an inline function non-inline if it is safe that programs linked with the prior version of the library call the old implementation. This is tricky and might be dangerous. Think twice before doing it.
    만약 예전 구현물을 호출하는 라이브러리의 이전 버전을 연결하는 것이 안전하다면, 인라인 함수 또는 인라인 함수를 비-인라인 (일반) 함수 형태로 변경하는 것. 영리한 방법이나, 위험할 수 있습니다. 하기 전에 한 번 더 생각해서 진행 바랍니다.
  • remove private non-virtual functions if they are not called by any inline functions (and have never been).
    어떠한 인라인 함수에 의해 (그리고 한 번도) 불려지지 않았다면, 프라이빗(private) 비-가상 함수들을 삭제
  • remove private static members if they are not called by any inline functions (and have never been).
    어떠한 인라인 함수에 의해 (그리고 한 번도) 불려지지 않았다면, 프라이빗(private) 정적 맴버들을 삭제
  • add new static data members.
    새로운 정적 자료 맴버들을 추가
  • change the default arguments of a method. It requires recompilation to use the actual new default argument values, though.
    메소드에 기본 인자를 변경. 하지만, 실제 기본 인자값이 사용될려면 재컴파일이 요구됩니다.
  • add new classes.
    새 클래스 추가
  • export a class that was not previously exported.
    이전에 내보내지지 않았던 클래스를 내보내기
  • add or remove friend declarations to classes.
    클래스에 대한 프랜드 선언 추가 또는 삭제
  • rename reserved member types
    예약된 맴버 자료형들의 이름을 변경
  • extend reserved bit fields, provided this doesn't cause the bit field to cross the boundary of its underlying type (8 bits for char & bool, 16 bits for short, 32 bits for int, etc.)
    주어진 자료형의 비트 경계 (문자형과 2진형의 8비트, short 형 정수의 16비트, int 형 정수의 32비트) 영향을 주지 않는 여분의 비트 영역 확장
  • add the Q_OBJECT macro to a class if the class already inherits from QObject
    QObject 형에 이미 상속을 받았다면, Q_OBJECT 매크로 추가
  • add a Q_PROPERTY, Q_ENUMS or Q_FLAGS macro as that only modifies the meta-object generated by moc and not the class itself
    클래스 자신이 아닌 메타-오브젝트에 의해 변경되는 Q_PROPERTY, Q_ENUMS 또는 Q_FLAGS 매크로


You cannot...

당신은 아래 것들을 해서는 안됩니다... (금기 사항)

  • For existing classes:
    이미 존재하는 클래스에 대해

  • For template classes:
    템플릿 클래스에 대해
  • For existing functions of any type:
    이미 존재하는 어떠한 자료형의 함수들에 대해
    • unexport it.
      내보내기 취소
    • remove it.
      제거
      • Remove the implementation of existing declared functions. The symbol comes from the implementation of the function, so this is effectively the function.
        존재하는 선언된 함수들의 구현 내용을 제거. 심볼은 함수의 구현물에서 나오므로 이런 동작은 함수에 영향을 줍니다.
    • inline it (this includes moving a member function's body to the class definition, even without the inline keyword).
      인라인 함수로 만들기 (inline 키워드를 쓰지 않더라도, 클래스의 정의에 함수의 본문이 이동하는 것도 포함합니다.)
    • add an overload (BC, but not SC: makes &func ambiguous), adding overloads to already overloaded functions is ok (any use of &func already needed a cast).
      오버로드 함수 추가 (부모 클래스 - Base Class : BC 에 해당, 자식 클래스 - Second Class : SC 는 아님: &func 를 모호하게 만듦), 이미 오버로드 된 함수에 오버로드 함수를 또 추가하는 것은 괜찮음 (&func 에는 이미 캐스팅이 필요해짐)
    • change its signature. This includes:
      특징(시그너처) 변경. 다음을 포함합니다.
      • changing any of the types of the arguments in the parameter list, including changing the const/volatile qualifiers of the existing parameters (instead, add a new method)
        이미 있는 const / volatile 수식자를 포함하는 파라미터 목록에 있는 인수의 자료형을 변경 (대신 새 메소드를 추가는 됨)
      • changing the const/volatile qualifiers of the function
        함수의 const/volatile 수식자를 변경
      • changing the access rights to some functions or data members, for example from private to public. With some compilers, this information may be part of the signature. If you need to make a private function protected or even public, you have to add a new function that calls the private one.
        예를 들어 프라이빗을 퍼블릭형으로 바꾸는 거와 같이, 자료 맴버들이나 몇몇 함수들의 접근 권한들을 변경 몇몇 컴파일러에게는 이것 또한 특징 정보의 일부가 될 수 있습니다. 만약 프라이빗 함수를 프로텍티드나 퍼블릭형으로 변경하고 싶다면, 프라리빗 함수를 호출하는 새로운 함수를 추가 해야합니다.
      • changing the CV-qualifiers of a member function: the const and/or volatile that apply to the function itself.
        맴버 함수의 CV-수식자를 변경: const 그리고/또는 volatile 을 함수 자신에게 붙인 수식자
      • extending a function with another parameter, even if this parameter has a default argument.See below for a suggestion on how to avoid this issue
        기본 인수를 가지고 있어도, 다른 파라미터를 가지고 함수를 확장(상속) 하는 행위. 아래에 이 문제를 피하는 방법을 참고 바랍니다.
      • changing the return type in any way
        어떠한 방법으로도 반환 형을 변경하는 행위
      • Exception: non-member functions declared with extern "C" can change parameter types (be very careful).
        예외: extern "C" 로 선언한 비-맴버형 함수들은 파라미터 형태들을 변경할 수 있습니다. (아주 조심해야합니다.)
  • For virtual member functions:
    가상 맴버 함수들에 대해서
    • add a virtual function to a class that doesn't have any virtual functions or virtual bases.
      가상 함수나 가상 부모들을 가지고 있지 않은 클래스에 가상 함수를 추가
    • add new virtual functions to non-leaf classes as this will break subclasses. Note that a class designed to be subclassed by applications is always a non-leaf class. See below for some workarounds or ask on mailing lists.
      단말(마지막) 클래스가 아닌 것에 새 가상함수를 추가하는 것은 자식 클래스들을 망가뜨릴 수 있습니다. 응용프로그램이 사용하는 자식 클래스는 항상 단말 클래스입니다. 아래 메일링 리스트에 문의 온 내용 또는 몇몇 해결 책을 참고하시기 바랍니다.
    • add new virtual functions for any reason, even to leaf classes, if the class is intended to remain binary compatible on Windows. Doing so may reorder existing virtual functions and break binary compatibility.
      어떠한 이유든, 단말 클래스라도 윈도우에 호환이 되는 이진 호환성을 목적으로 했을 때, 새 가상 함수들을 추가하는 행위. 이러한 작업은 기존의 가상 함수의 구조를 변경하고, 이진 호환성을 깨게 합니다.
    • change the order of virtual functions in the class declaration.
      클래스 선언에 있는 가상 함수의 순서를 변경
    • override an existing virtual function if that function is not in the primary base class (first non-virtual base class, or the primary base class's primary base class and upwards).
      1차 부모 클래스에 존재하지 않는 가상 함수를 오버라이드 하기 (첫번째 비-가상 부모 클래스 또는 그것의 1차 부모 클래스, 그리고 그 이후)
    • override an existing virtual function if the overriding function has a covariant return type for which the more-derived type has a pointer address different from the less-derived one (usually happens when, between the less-derived and the more-derived ones, there's multiple inheritance or virtual inheritance).
      더-상속 받은 자료형이 덜-상속 받은 자료형과 다른 포인터 주소를 가진 공변 반환 형 오버라이딩 함수라면, 그 함수가 기존의 가상 함수를 오버라이딩 하기 (다중 상속 또는 가상 상속으로 인해 덜-상속 받은 것과 더-상속 받은 것 사이에는 보통 일어납니다.)
    • Remove a virtual function, even if it is a reimplementation of a virtual function from the base class
      부모 클래스에서 온 가상 함수를 재구현화 했음에도 불구하고 이 가상 함수를 제거
  • For static non-private members or for non-static non-member public data:
    정적 넌프라이빗 맴버들 또는 비-정적 넌-맴버 퍼블릭 자료(변수)들에 대해

  • For non-static members:
    비-정적 맴버들에 대해
    • add new, data members to an existing class.
      이미 존재하는 클래스에 맴버들을 추가
    • change the order of non-static data members in a class.
      클래스에 비-정적 자료 맴버들의 순서를 변경
    • change the type of the member, except for signedness
      부호성(+, -)을 제외하고, 자료형을 변경
    • remove existing non-static data members from an existing class.
      이미 존재하는 클래스의 비-정적 자료 맴버들을 제거


If you need to add extend/modify the parameter list of an existing function, you need to add a new function instead with the new parameters. In that case, you may want to add a short note that the two functions shall be merged with a default argument in later versions of the library:
기존의 함수들의 파라미터 목록을 확장/수정하고 싶다면, 대체 파라미터를 가진 새 함수를 추가할 필요가 있습니다. 이 때는, 그 두 함수들이 이후 버전의 라이브러리에서 기본 파라미터를 가진 새 함수로 합쳐져야 한다고 짧은 표기를 해도 됩니다.

void functionname( int a );
void functionname( int a, int b ); //BCI: merge with int b = 0


You should...
당신은 아래의 것들을 해야 합니다...

In order to make a class to extend in the future you should follow these rules:
나중을 위해 클래스를 확장하려면, 아래의 규칙을 따라야 합니다.

  • add d-pointer. See below.
    d-포인터를 추가합니다. 아래 참조
  • add non-inline virtual destructor even if the body is empty.
    본문이 비어 있어도 넌-인라인 가상 파괴자를 추가
  • reimplement event in QObject-derived classes, even if the body for the function is just calling the base class' implementation.
    부모 클래스의 구현내용을 호출만 하는 것이 전부여도, QObject 를 상속 받은 클래스에서 event 를 다시 구현하기
  • make all constructors non-inline.
    모든 생성자들을 인-라인으로 만듦
  • write non-inline implementations of the copy constructor and assignment operator unless the class cannot be copied by value (e.g. classes inherited from QObject can't be)
    값을 복사 못하지 않는다면 (복사 할수 있다면) (예. QObject 로 상속 받은 클래스들은 못함) , 복사 생성자와 할당 연산자의 넌-인라인 형태로 작성

(다음 글에 계속 됩니다...)

Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.