Pimpl copying

[David Faure]

On Monday 17 July 2006 09:19, Peter Kümmel wrote:
> David Faure wrote:
> > 
> > Honestly, for all those "how to write library classes" issues, I would say, let's
> > just do what Qt does. Consistent, and avoids re-inventing (and re-discussing!)
> > the wheel.
> > 
> > Qt uses QFooPrivate instead of QFoo::Private, maybe the reason is the visibility
> > issue, but in any case I'd suggest we just do that.
> > 
> > Similary, I would suggest just using Q_DISABLE_COPY, etc.
> > 
> 
> 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.

> 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.

> 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.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).