On Thursday 25 August 2011 19.23.10 Alexander Potashev wrote: > 2011/8/25 Albert Astals Cid <aa...@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