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

List:       kde-devel
Subject:    Re: Weird "const"-ness problem
From:       "Thomas Schilling" <snuffeler () gmx ! net>
Date:       2002-02-13 11:12:36
[Download RAW message or body]

d->option[key] looks like a hash access. Some hashes (e.g.: the
STL map) automatically generate an empty key when a new (i.e. not
in hash) key is requested. I think the QDict doesn't.

BTW: You need not use const QString& to save space in parameter
declarations: sizeof(QString) = 4

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


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]