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

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.COM> writes:

| On Fri, Aug 13, 2004 at 06:44:00PM +0200, Gabriel Dos Reis wrote:
| > Joe Buck <Joe.Buck@synopsys.COM> writes:
| > | Any decent design process by a designer unaware of the defect in the
| > | standard (and that's what it is) would probably specify that the
| > | Parser::isOK method is const, because it does not alter either the actual
| > | or the logical state of any of the members.  Good C++ design requires that
| > | const be used as much as possible, because it greatly simplifies the
| > | maintainance of the code (when undesired write operations occur, there are
| > | fewer places to look.
| > 
| > Const-correctness is a good design principle.  However, it is not a dogma,
| > which is why I'm aksing the question.
| 
| Designing standard APIs in such a way as to impede the use of
| const-correctness, and then arguing to all who point out the fact one's
| believe that a Parser object should have no const methods seems dogmatic.

Quite the contrary -- principles should be questioned in specific
contexts for relevance -- and I beg to differ.

I'm not the author of this part of the library, but the mere fact that
it has been like that for ages and source of continual discussions is
a sign that your statement above is way either light-year away from the
issue or just, er, dogmatic.  Sorry; half :-)

| In this case, const-correctness is impossible without casting away const,
| using a mutable member, or other similar hacks, and arguing that this
| doesn't matter because people shouldn't design that way is troubling.

Er. Const-correctness, is like copy-construction or assignment.  In
either cases its application needs questions.  

No, in this case one can achieve const-correctness without resorting
to casting away const or mutable.  Just like in case one thinks one
can define copy-construction or assignment for a stream.

-- Gaby