ABI compatibility plans
Posted: Thu Mar 03 2016 3:02 am
Qt has traditionally had very strict ABI compatibility guarantees, which comes with some pros and cons. I'm curious what approach CopperSpice will take in this regard, since it impacts the types of changes that can be made over time. More specifically, the standard library does not have any inherent ABI compatibility and different implementations have different policies about it. More importantly, using standard library types at shared object boundaries is usually a bad idea from an ABI compatibility perspective.
I believe the spectrum would place Boost on one side (with almost no guarantees across releases) and Qt on the other (with very strict guarantees across releases) and LLVM (and subprojects) somewhere in the middle (some things have guarantees and other things don't). Given this diversity, I'm curious where CopperSpice wants to end up?
I believe the spectrum would place Boost on one side (with almost no guarantees across releases) and Qt on the other (with very strict guarantees across releases) and LLVM (and subprojects) somewhere in the middle (some things have guarantees and other things don't). Given this diversity, I'm curious where CopperSpice wants to end up?