DRAFT document on coding conventions in kde libraries
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
> - 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).
More information about the kde-core-devel