Différence entre API et ABI

API: Interface de programme D'Application

C'est L'ensemble des types/variables/fonctions publics que vous exposez à partir de votre application/Bibliothèque.

En C/C++ c'est ce que vous exposez dans les fichiers d'en-tête que vous livrez avec l'application.

ABI: interface binaire D'Application

C'est ainsi que le compilateur construit une application.
Il définit les choses (mais n'est pas limité à):

• comment les paramètres sont passés aux fonctions (registres / pile).
• qui nettoie les paramètres de la pile (appelant / appelé).
• où la valeur de retour est placée pour le retour.
• comment les exceptions se propagent.

Je rencontre surtout ces termes dans le sens D'un changement incompatible avec L'API ou D'un changement incompatible avec L'ABI.

Un changement D'API est essentiellement l'endroit où le code qui aurait été compilé avec la version précédente ne fonctionnera plus. Cela peut se produire parce que vous avez ajouté un argument à une fonction ou changé le nom de quelque chose d'accessible en dehors de votre code local. Chaque fois que vous changez un en-tête, et cela vous oblige à changer quelque chose dans un .C/.fichier cpp, vous avez fait un changement D'API.

Un Le changement ABI est l'endroit où le code qui a déjà été compilé contre la version 1 ne fonctionnera plus avec la version 2 d'une base de Code (généralement une bibliothèque). Ceci est généralement plus délicat à suivre que les changements incompatibles avec L'API, car quelque chose d'aussi simple que l'ajout d'une méthode virtuelle à une classe peut être incompatible avec ABI.

J'ai trouvé deux ressources extrêmement utiles pour déterminer ce qu'est la compatibilité ABI et comment la préserver:

• la liste des choses à faire et à ne pas faire avec C++ pour le KDE projet
• Comment écrire des bibliothèques partagées D'Ulrich Drepper.pdf (auteur principal de la glibc)

Voici mes explications profanes:

• api-pensez aux fichiers include. ils fournissent une interface de programmation
• module du noyau ABI-think. lorsque vous l'exécutez sur un noyau, ils doivent convenir de la façon de communiquer sans inclure les fichiers, c'est-à-dire en tant qu'interface binaire de bas niveau

Permettez-moi de donner un exemple spécifique de la différence entre ABI et API en Java.

Un changement incompatible ABI est si je change une méthode a#m () de prendre un String comme argument à String... argument. Ceci est Pas Compatible ABI parce que vous devez recompiler le code qui appelle cela, mais il est compatible API car vous pouvez le résoudre en recompilant sans aucun changement de code dans l'appelant.

Voici l'exemple énoncé. J'ai ma bibliothèque Java avec classe Un

// Version 1.0.0
public class A {
    public void m(String string) {
        System.out.println(string);
    }
}

Et j'ai une classe qui utilise cette bibliothèque

public class Main {
    public static void main(String[] args) {
        (new A()).m("string");
    }
}

Maintenant, l'auteur de la bibliothèque a compilé leur classe A, j'ai compilé ma classe principale et tout fonctionne bien. Imaginer une nouvelle version vient

// Version 2.0.0
public class A {
    public void m(String... string) {
        System.out.println(string[0]);
    }
}

Si je prends simplement la nouvelle classe compilée A et la dépose avec la classe main précédemment compilée, j'obtiens une exception lors de la tentative d'invoquer la méthode

Exception in thread "main" java.lang.NoSuchMethodError: A.m(Ljava/lang/String;)V
        at Main.main(Main.java:5)

Si Je recompile Main, ceci est corrigé et tout fonctionne à nouveau.

(Unapplication Binary Interface) Un cahier des charges pour une plate-forme matérielle, combiné avec le système d'exploitation. C'est une étape au-delà de l'API (UNapplication Program Interface), qui définit les appels de l'application pour le système d'exploitation. L'ABI définit L'API plus le langage machine pour une famille de processeurs particulière. Une API n'assure pas la compatibilité d'exécution, mais un ABI le fait, car il définit le langage machine, ou de l'exécution, format.

De Courtoisie

Votre programme (code source) peut être compilé avec des modules qui fournissent API.

Votre programme (binaire) peut fonctionner sur des plates-formes qui fournissent ABI approprié.

L'API restreint les définitions de type, les définitions de fonction, les macros, parfois les variables globales qu'une bibliothèque doit exposer.

ABI restreint ce qu'une "plate-forme" devrait fournir pour que votre programme fonctionne. J'aime le considérer en 3 niveaux:

• Niveau du processeur - le jeu d'instructions, le Convention d'appel

• Niveau du noyau - la convention d'appel système, la convention spéciale de chemin de fichier (par exemple les fichiers /proc et /sys sous Linux), etc.

• Niveau du système D'exploitation - le format de l'objet, les bibliothèques d'exécution, etc.

Considérons un compilateur croisé nommé arm-linux-gnueabi-gcc. "arm" indique l'architecture du processeur, "linux" indique le noyau, " gnu " indique ses programmes cibles utilisent la libc de GNU comme bibliothèque d'exécution, différente de {[3] } qui utilisent la libc D'Android application.