Re: const memberfunctions

Fons Rademakers (Fons.Rademakers@cern.ch)
Tue, 11 Aug 1998 16:05:38 +0200

We agree that as many member functions as possible should be constant.
Especially the getters, testers (IsXxxxxx()) and service (Print(), Dump())
members. All new code is more or less ok. Older code is still sloppy
in this respect and will be corrected over time. However, this might
break some code since making a member const causes often a ripple effect
through many routines plus overriding will break due to signature changes.
Any such changes will be clearly documented in new releases.

On the other hand more methods are const then shows up in the list of
methods in the HTML doc. Check the *.h file to see the thruth. We'll
fix the THtml class to show correctly const.

Cheers, Fons.

Rutger van der Eijk wrote:
>
> Hi,
>
> I couldn't find any reference on roottalk to this subject yet, so here I
> go.
>
> I noticed that in the root classes (including TObject) almost never
> memberfunctions which don't (and shouldn't!) change datamembers of a class
> are declared constant.
> For example most 'getters' should be declared constant (Except in
> the exceptional case where you want a user of a class to be able to change
> a datamember (which usually indicates an 'ill formed' (i.e. non OO)
> program.)) Another example is for example the TObject::Print() member
> which (at least in my opinion) should not change the object.
> Of course C++ does not force anyone to declare memberfunctions
> constant if they in fact don't change the object. I do think it
> is a sort of convention in structered/OO programming in C++ though. I see
> that this might not be an issue of the highets priority but I think it
> should be changed in the (near) future.
>
> Anybody have (other) opinions about this?
>
> Rutger

-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland          Phone: +41 22 7679248
E-Mail: Fons.Rademakers@cern.ch              Fax:   +41 22 7677910