I. The ABI of the dynamic link librarythe compatibility of a dynamic-link library is due to the ABI (Application binary interface) of the library, which is similar to the API, but includes provisions such as the stack structure of function calls, symbolic naming, parameter rules, and memory distribution of data structures.
two. Behavior that causes the dynamic link library to be incompatible
- Delete an export class;
- Changing the inheritance hierarchy of an exported class
- Changing template parameters for templates
- Delete an export function
- Change the inline property of a function
- Change the signature of a function
- Add a virtual function to a non-virtual base class or to a class that does not contain virtual functions
- Change the declaration order of virtual functions
- ......
three. Generally does not cause the dynamic link library incompatible behavior
- Add a non-virtual function
- Delete non-virtual functions that are not called by the inline function
- Change the default parameters of a function
- Add a new static data member
- To export a new parameter
- Add or remove a friend declaration
- ......
Four. Detailed content (English)For more information, refer to: https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++Note about ABI
this text applies to most C + + ABIs used by compilers which KDE can is built with. I T is mostly based on The itanium C + + ABI Draft, which is used by the GCC C + + compiler since version 3.4 in all PLATFO RMS 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).
Some of the constraints specified here is not an apply to a given compiler. The goal are to list the most restrictive set of conditions when writing Cross-platform C + + code, meant to be compiled With several different compilers.
This page was updated when new binary incompatibility issues was found.
The Do ' 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.
- exeption:if that leads to the compiler choosing a larger underlying type for the enum, that makes the CHA Nge binary-incompatible. Unfortunately, compilers has some leeway to choose the underlying type, so from an api-design perspective it ' s Recommende D to add a Max .... enumerator with a explicit large value ( =255 , =1<<15 , etc) to Create an interval of numeric enumerator values that's guaranteed to fit into the chosen underlying type, whatever that M Ay be.
- reimplement virtual functions defined in the primary base Class hierarchy (that's, virtuals defined in the first Non-virtual base class, or in that class ' s first non-virtual base class, and so forth) if it was safe that programs linked with the prior version of the library C All 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.
- exception:if The overriding function has a covariant return type, it's only a binary-compatible chan GE if the more-derived type have always the same pointer address as the less-derived one. if in doubt Ride with a covariant return type.
- Change a inline function or make a inline function non-inline if It is safe this programs linked with the prior Version of the library call the old implementation. This is tricky and might are dangerous. Think twice before doing it.
- Remove private non-virtual functions if they is not called by any inline functions (and has never been).
- Remove private static members if they is not called by any inline functions (and has never been).
- 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 is 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, with bits for short, and bits for int, etc.)
- Add the Q_object macro to a class if the class already inherits from Qobject
- Add a q_property, q_enums or Q_flags macro as that is only modifies the meta-object generated by MOC and not the class itself
You cannot ...
- For existing classes:
- Unexport or remove an exported class.
- Change the class hierachy on any (add, remove, or reorder base classes).
- For template classes:
- The change of the template arguments in any (add, remove or reorder).
- 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).
- Add an overload (BC, but not sc:makes &func ambiguous), adding overloads to already overloaded functions are Ok (any use of &func already needed a cast).
- 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)
- Changing the Const/volatile qualifiers of the function
- Changing the access rights to some functions or data members, for example from private to public. With some compilers, this information is part of the signature. If you need to make a private function protected or even public and 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 is apply to the function itself.
- Extending a function with another parameter, even if this parameter have a default argument. See below for a suggestion on what to avoid this issue
- Changing the return type in any
- Exception:non-member functions declared with extern "C" can change parameter types (be very careful).
- For virtual member functions:
- Add a virtual function to a class that doesn ' t has any virtual functions or virtual bases.
- Add new virtual functions to non-leaf classes as this would break subclasses. Note that a class designed to being subclassed by applications are 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 was intended to remain binary compatible O N Windows. Doing so could reorder existing virtual functions and break binary compatibility.
- The order of the virtual functions in the class declaration.
- Override an existing virtual function if this function is not in the primary base class (first non-virtual base class, or The primary base class ' s primary base class and upwards).
- Override an existing virtual function if the overriding function have a covariant return type for which the more-derived Ty PE have 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:
- remove or unexport it
- < Span style= "font-size:18px" >change its type
- change its cv-qualifiers
- 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 a existing function, you NE Ed to add a new function instead with the new parameters. In this case, want to add a short note that the functions shall is merged with a default argument in later ver Sions of the library:
void functionname< Span style= "Color:rgb (0,110,40)" > ( 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 should follow these rules:
- Add D-pointer. See below.
- 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 ' I Mplementation.
- Make all constructors non-inline.
- Write Non-inline implementations of the copy constructor and assignment operator unless the class cannot be copied by Valu E (e.g. classes inherited from Qobject can ' t be)
Copyright, welcome reprint, reproduced Please indicate the source, thank you
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
C + + dynamic-link library compatibility
