From kde-devel  Wed Feb 13 10:46:00 2002
From: Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date: Wed, 13 Feb 2002 10:46:00 +0000
To: kde-devel
Subject: Re: Weird "const"-ness problem
X-MARC-Message: https://marc.info/?l=kde-devel&m=101359708630709

On Wed 13. February 2002 11:22, Michael Goffioul wrote:
> >  Hmm. Another reason why to avoid putting things in the private d-pointer
> > structure whenever possible.
> >
> >  The 'd' pointer is of type 'KPrinterPrivate*'. In the context of the
> > const method, it will be 'KPrinterPrivate *const', which is a const
> > pointer to KPrinterPrivate, but not a pointer to const KPrinterPrivate
> > (i.e. the pointer is const, but the data it points to isn't). Which means
> > that d->m_options isn't a const object.
>
> Got it. Thanks.
>
> >  The solution can be moving the data from KPrinterPrivate directly to the
> > class, if it's possible, or changing the code to:
> >
> > const QString& KPrinter::option(const QString& key) const
> > {
> > const KPrinterPrivate* const d_const = d;
> > return d_const->m_options[key];
> > }
>
> ...or use something like:
>
> inline const QString& KPrinterPrivate::option(const QString& key) const
> { return m_options[key]; }
>
> and
>
> const QString& KPrinter::option(const QString& key) const
> { return d->option(key); }
>
> Though I'm not sure about the effect of "inline".

 There shouldn't be a problem with the 'inline' I think. Note however that if 
the KPrinterPrivate method will have both a const and non-const, the 
non-const will be still called.
 (And I personally find just the d_const variant simpler).

-- 
 Lubos Lunak
 llunak@suse.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<