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?

Nathan Myers <> writes:

| On Fri, Aug 13, 2004 at 06:48:22PM +0200, Gabriel Dos Reis wrote:
| > | >"Vladimir Merzliakov" <> writes:
| > | >
| > | >| class Parser {
| > | >|    std:ifstream m_in;
| > | >|    public: bool isOK() const { return m_in.is_open(); }
| > | >| };
| >  ...
| > Yes, it does not compile, I know and I see it. Similarly, I can post
| > many function declarations along the same lines.  The point of the
| > question, was in which actual context do you need that thing to be
| > const, i.e. is it actually called.
| This Parser might be derived from an abstract base that knows
| nothing about streams, yet be obliged to implement its interface.
| Certainly it is not unreasonable for the base class to have made 
| isOK() const.

This is precisely where we seem to disagree.  I contend that any
actual use of Parser is in contexts where it ought to be modifiable
and any added "const" is through artefacts.  I also contend that the
"not unreasonable to make it const" is more compliance with the
dogma than with the principle.

| (Whether it is reasonable to use an ifstream, and 
| not a filebuf, in a parser is beside the point.)  


| When implementing such a derivation interface, now, you have no 
| choice but to say "const_cast<Parser*>(this)->m_in" for access from 
| those const members.
| This issue came up in committee lots of times, and evoked Gaby's 
| reaction (from me, too), several times before examples like this made 
| the difference.

We seem to have diverged on the reality of the examples :-)

-- Gaby

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