[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Weird "const"-ness problem
From: Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date: 2002-02-13 10:46:00
[Download RAW message or body]
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 <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic