This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should basic_*stream::is_open() be const?

On Sat, Aug 14, 2004 at 01:29:01PM +0200, Gabriel Dos Reis wrote:
> Carlo Wood <> writes:
> Const-correctness is a good, sound design principle when it is
> not hold as a dogma.  Making a function const, in an interface or
> abstract class, put a *high* constaint on the ways it could be
> implemented. Actually, it reduces the set of implementation
> possibilities. It exposes implementation details in the interface.
> That is why I maintain it should be questioned each time it is applied.
> For example, with your const external_extrophy, you exclude "lazy
> evaluation", unless one adds extra indirection.  The same goes for the
> is_open(). 

Making a function const is a way of documenting its role: does calling
it change the public state of the object?  Regardless of how much work
an is*() function has to do, making it const is a promise, and the 
compiler helps you keep it by preventing accidents.

Now, in the derived Parser example, one could certainly define the
fstream member as "mutable", and all problems would go away.  But
why should people have to say "mutable" just because the member 
they are using failed to document its intentions?  If is_open()
has to do something complicated, then fooling around with mutable
and const_cast is _its_ job.  Making the whole stream mutable 
means that the compiler can't help maintain the promise.

Iostreams is how it is for purely historical reasons: it is the 
oldest component in the library, and it shows.  It certainly
wouldn't have been done that way today, or even in the '90s.  
You can call const-correctness a dogma -- and for people with no 
experience, it can be little more -- but around here, it's just a
way to pick a fight.  

It doesn't cost anything to be const-correct, but it makes others' 
lives easier, so what it really amounts to is a courtesy to users.

Nathan Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]