This is the mail archive of the libstdc++@gcc.gnu.org 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?


Chris Jefferson <caj@cs.york.ac.uk> writes:

| Gabriel Dos Reis wrote:
| 
| >"Vladimir Merzliakov" <wanderer@rsu.ru> writes:
| >
| >| > | Without this methods being const (which they should be IMHO from a
| >| > | logical perspective, as they do not change the internal state of the
| >| > | stream but simply return state information), methods that use these
| >| > | methods can not be const.
| >| > | This "can not be const" will easily cascade into upper layers, which
| >| > | reduces quality and safeness of the code.
| > | > | | > | What are your doubts? Is there anything I might miss?
| > | > | > What do you do with a const stream?
| > | | class Parser {
| >|    std:ifstream m_in;
| >|    public: bool isOK() const { return m_in.is_open(); }
| >| };
| > | | ?
| >
| >You're telling me that you need a const member function because you
| >need a constant member function.  A parser, is kind of stream.  My
| >question was what do you with a const stream.  If your const parser is
| >not OK what do you to it?
| >
| >
| Surely a better idea would be to make every function const which can
| be made const, because there is no reason not to?

That is essentially what the const-correctness principle says, and I
agree with it, *in general*.  My question in the context of streams, is
is there any real reason i.e. semantics reasons, apart from adhering
to the dogma, to make those functions const?

Notice that my question is not directed to oppose the patch but to
elaborate on my profound doubts regarding the DR -- which Paolo
Carlini asked. 

-- Gaby


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