Pimpl copying

[Peter Kümmel]

David Faure wrote:
>> I agree when there is a good solution provided by Qt, but sometimes
>> Qt also have some drawbacks, especially in cases where a solution requires
>> template techniques. kde doesn't need to support compilers for embedded systems.
> 
> I'm not sure the Konq/E people would agree. KDE code -has- been ported to embedded
> systems in the past, surely it will happen again in the future.
> 

Yes, I forgot, wasn't it a Nokia.


>> In the pimpl case i think it is better to unify the pimpl declaration with
>> disabling copying, because then you can't forget it. You also can't forget
>> destruction, creation. 
> 
> Maybe, but when I read your macro's name I got -very- confused about what it
> was supposed to do. The documentation then explained it, but it's really not
> self-explaining, that forbidding the copying is about Foo, not about FooPrivate.

I've dropped the idea to use a new macro: templates or Qt macros is the way top go.

But I don't see that it is possible to introduce a template version, too many will
complain about it, because kdelibs is not a template heavy library, and I don't
wanna be the guy who tries to changes this. The pimpl idiom is not worth the trouble


>> And is the Qt version const correct, I don't think so? 
> 
> Doesn't d_func come with a const version of it, for const methods? I didn't check,
> but that would make sense.

#define Q_DECLARE_PRIVATE(Class) \
    inline Class##Private* d_func() { return reinterpret_cast<Class##Private *>(d_ptr); } \
    inline const Class##Private* d_func() const { return reinterpret_cast<const Class##Private *>(d_ptr); } \
    friend class Class##Private;

#define Q_D(Class) Class##Private * const d = d_func()


So you get a 'const ClassPrivate*' when you call d_func() in a const function,
seems I was wrong.

BTW the cast is the price they pay for their Private "Hinterwelt", means there
is a second class hierarchy behind the scene.

Peter