[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Pimpl copying
From:       Peter_Kümmel <syntheticpp () gmx ! net>
Date:       2006-07-14 17:35:56
Message-ID: 44B7D5FC.8050003 () gmx ! net
[Download RAW message or body]

Peter Kümmel wrote:
>> Many pimpls were just changed to (nested) Private.
>>
> 
> Have the guide lines changed again?
> 
> http://lists.kde.org/?l=kde-core-devel&m=114322798807520&w=2
> http://developer.kde.org/policies/librarypolicy.html
> 

Searching for "Private;" shows that the naming is totally inconsistent
in kdelibs. So the question is, must it be consistent? And if, which
name should be used?


>>> +#define KDE_PIMPL_ENABLE_COPY(X)  KDE_PIMPL_BASE_MACRO(public, X)
>>> +#define KDE_PIMPL_DISABLE_COPY(X) KDE_PIMPL_BASE_MACRO(private,X)
>> Does't KDE_PIMPL_DISABLE_COPY lead to unresolved smybols linking error 
>> with MSVC (see "unresolved symbols from value.cpp/.h" on k-c-d from 
>> 20.01.2006)?

Reading this thread I think the problem is more related to templates
(which does not mean we can use the pimpl macro).


If it is OK I will change the pimpl at least in kdecore to the
usage of the new pimpl macro.

As a next step I wanna change the macro to use a constness propagating
pointer wrapper, which eventuality is only used for debug builds.

As you know using the pimpl idiom breaks const correctness:

void Class::memberFunction() const {
    d->setPrivateData( 0 );
}

[prev in list] [next in list] [prev in thread] [next in thread]