News for hackers. Stuff that matters.

A comment on Is Semantic Versioning an Anti-Pattern?. Parent comment

Re:Is Semantic Versioning an Anti-Pattern? by viraptor on Thursday January 12, 2017 @12:25AM (#13380005)
I don't do C++ normally, but the situation seems similar. There's http://wiki.c2.com/?PimplIdiom for opaque objects, so you don't have to make their members part of the public API. But for things you do want to make public it's the same solution - make it a your public API by documenting it. If you know it breaks compatibility, it requires major version bump.

And no, after compilation, I don't believe the symbol order matters.

[ Parent | on HN ]
Re:Is Semantic Versioning an Anti-Pattern? by flukus on Thursday January 12, 2017 @01:26AM (#13380204)
The pimpl method looks like it ads a level of indirection to every private member access. Is that an issue in practice?
[ Parent | on HN ]
Re:Is Semantic Versioning an Anti-Pattern? by slavik81 on Thursday January 12, 2017 @01:48AM (#13380287)
Qt uses it extensively. For big, complex objects like QTextEdit it's probably the least of your concerns, but they do avoid it for simple value types like QPoint.
[ Parent | on HN ]
Re:Is Semantic Versioning an Anti-Pattern? by flukus on Thursday January 12, 2017 @02:08AM (#13380387)
A good chunk of these questions I'm asking are because I half remember Qt's binary compatibility guidelines from when I did an internship at Trolltech many years ago :) A similar list is here: https://community.kde.org/Policies/Binary_Compatibility_Issu... . It looks like the virtual function restrictions are what I was talking about, that's where pure additions can break compatibility.
[ Parent | on HN ]
Re:Is Semantic Versioning an Anti-Pattern? by slavik81 on Thursday January 12, 2017 @03:56AM (#13380838)
If you worked at Trolltech, you almost certainly know more than me. I was just a user of Qt who peeked under the covers occasionally.
[ Parent | on HN ]
Re:Is Semantic Versioning an Anti-Pattern? by jstimpfle on Thursday January 12, 2017 @06:35AM (#13381465)
It's an issue if the methods on that object are short-lived enough that the overhead of indirection is significant.

It's also an issue if very performance-sensitive routines need to read data from the object. In which case they already know exactly what's in there, so "pimpl" hiding has no benefit in the first place.

Implementations should be hidden if they are likely to change. In other words, there are are non-obvious data or method members and/or it's likely that functionality will be added in the future. These are the high-level architectural situations, not the leaf level ones where you optimize out every cyle possible.

[ Parent | on HN ]