This is the mail archive of the
mailing list for the libstdc++ project.
Re: Should basic_*stream::is_open() be const?
On Sat, Aug 14, 2004 at 01:29:01PM +0200, Gabriel Dos Reis wrote:
> Carlo Wood <email@example.com> 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
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.