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

List:       kde-devel
Subject:    Re: const-correctness in part.h
From:       "Christian Loose" <Christian.Loose () hamburg ! de>
Date:       2001-08-22 22:18:13
[Download RAW message or body]

On Wed 22. Aug 01 21:09, aleXXX wrote:
> On Wed 22 Aug 01 19:55, Christian Loose wrote:
> > Hi!
> >
> > I was just looking at the source code of the kpart-library, when I came
> > across the
> > member functions widget() and manager(). I think, they should be
declared
> > const,
> > because they don't change the internal state of the Part-class. Please
> > apply the attached
> > patch when you go conform with my opinion, because I don' t have access
to
> > cvs.
> >
> > I hope, I helped....
> >
> > Bye
> > Christian
> >
>
> Hmm, not sure, but the function returns "QWidget*" instead of  "const
> QWidget*", so the function is not really const since it returns a member
> non-const. The same for the other functions.
>
> Bye
> Alex
>

I don't think that specifying const or not depends on the return type,
because
const means *this* member function doesn't change the state of the object.
It
does not mean IMHO an outside function isn't allowed to "mess around" with
the returned variable.

But your statement made me play around alittle, and I found out that
specifying
const doesn't gain us alot, because it means that the member function isn't
allowed
to change the member pointer. It does *not* mean, the member function
doesn't
change the memory the member pointer points to. So imagine you have a class
with a 'char* str_;' member variable. Than you can write the following
member function
with no problems at all:

void changeMember() const { str_[0] = 'a'; }

So just ignore my patch...Happy coding!!!

Christian


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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