playground-libs/libkvkontakte has moved to kdereview

Thomas Zander 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 ;)


Cheers!
-- 
Thomas Zander




More information about the kde-core-devel mailing list