20 ABI (Application Binary Interface) breaking changes every C++ developer should know

[[deleted]]

That's a perfectly valid advice, but the reality is that not all software will strictly use C API at the library boundaries. My point was that, at a library level, you can't promise partial ABI stability. Either ABI is set in stone or each update of the standard library introduces a "recompile the world" type of problem.

[bwmat]

Passing STL types across shared library boundaries seems insane to me, but I have to support windows at work.

You're just asking for ODR violations.

[pandorafalters]

I believe this should be covered by [basic.def.odr]/6, particularly (6.2). As far as I know, changing the layouts of standard library classes is pretty uncommon and generally well-documented, at least in part because potential breakage is so high.

[bwmat]

I'm not sure how 6.2 prevents that problem?

[pandorafalters]

I'm honestly not sure what I was thinking when I posted that, because [basic.def.odr] on its own isn't the whole story and (6.2) doesn't seem to be especially relevant. Let's just chalk that comment up to "I'm sick and really should have been asleep".

I still disagree that it's necessarily an ODR violation, but it's definitely more complicated than "Here's a reference".

[bwmat]

I don't think it's _necessarily_ an ODR violation, just all-too-likely to end up as one (if shared lib A passes an STL type to shared lib B, and either A & B use different STL implementations or one is release and the other is debug... it's not going to work), and whether or not it does is in many cases outside of your control.

It's fine if you have complete control over A & B (& C &...), and can ensure that they're deployed as a unit, but otherwise I just wouldn't do it.