DRAFT document on coding conventions in kde libraries

Kuba Ober kuba at mareimbrium.org
Mon Mar 6 13:49:31 GMT 2006

> I wanted to write the same, but in case of the libraries, it makes sense
> to have a common look, at least for the interfaces, and that includes
> if:
> - the d pointer classes are private or not (I support non-private ones)

If the d pointer classes are not private, there's no point in having d 
pointers, right? A private dptr class lets you modify the implementation 
without breaking BC. A protected/public dptr class doesn't allow you to do so 
-- any changes in the dptr class will break BC, since application code can 
now depend on the dptr class.

An exception would be a case where the dptr class is protected, but the parent 
class is not designed to be derived from in the application code (and it's 
documented to be so).

Cheers, Kuba

More information about the kde-core-devel mailing list