Si je peux changer ma représentation interne d'une classe, ne pas recompiler ceux qui utilisent cette classe et tout de même linker avec c'est qu'il n'y a pas de problème d'abi ?
Oui, tant que ça pete pas en vol non plus. Java est abi compatible aussi, un .class de 1993 tournera sans problème dans une appli écrite en 2022 en java 17 sans rien toucher.
Java (et actes associés donc kotlin aussi), swift/objc, c, .net aot ou jit, et un petit peu en c++ si tu plisses les yeux sont abi stable. Pas rust et go. Go essaye d’esquiver le problème en linkant tout en statique, mais je sais pas ce que ça donne en pratique pour la distribution de librairies?
Les languages de script ne sont pas distribués sous forme binaire, ce qui aide pas pour le b d’abi, donc le problème ne se pose pas pour eux.
[^] # Re: C'est moi ou c'est idiot ?
Posté par groumly . En réponse au journal Google forke C++. Évalué à 5.
Oui, tant que ça pete pas en vol non plus. Java est abi compatible aussi, un .class de 1993 tournera sans problème dans une appli écrite en 2022 en java 17 sans rien toucher.
Java (et actes associés donc kotlin aussi), swift/objc, c, .net aot ou jit, et un petit peu en c++ si tu plisses les yeux sont abi stable. Pas rust et go. Go essaye d’esquiver le problème en linkant tout en statique, mais je sais pas ce que ça donne en pratique pour la distribution de librairies?
Les languages de script ne sont pas distribués sous forme binaire, ce qui aide pas pour le b d’abi, donc le problème ne se pose pas pour eux.