playground-libs/libkvkontakte has moved to kdereview
zander at kde.org
Fri Aug 26 12:06:46 BST 2011
On Thursday 25 August 2011 19.23.10 Alexander Potashev wrote:
> 2011/8/25 Albert Astals Cid <aacid at kde.org>:
> > The point is that usually you do not know what the library will end up
> > doing and by using d-pointers everywhere you make it easier for
> > yourself to maintain binary compatibility in the future.
> But in the case that most classes won't grow in the future by using
mystrategy (keeping d-ptr NULL when possible) we cut down the number ofmemory
allocations, and also simplify the existing code that doesn'twork with the
private class' data. So, I'm going to keep following thecurrent strategy.
There are several cornercases known where the d-pointer and a general policy
of keeping the installed header file clean is a solution.
One example is when you can get problems when dynamic_cast fails to work
accross libraries (i.e. in code that uses your library) if there is not enough
code in the cpp file.
There are several other problems, like David also wrote, where you will end up
accidentially changing ABI.
So if you choose to not use this approach to solving ABI consistency, may I
suggest you write some tests that export the ABI at release and compare it for
every subsequent release so you can avoid accidental breakages.
I've been doing C++ for years, and I still accidentally make breakages when I
change something I didn't expect to cause issues, its much easier to break
than you might expect ;)
More information about the kde-core-devel