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

Andreas Kohn andreas@syndrom23.de
Fri Aug 13 11:10:00 GMT 2004


On Fri, 2004-08-13 at 12:44, Gabriel Dos Reis wrote:
> Paolo Carlini <pcarlini@suse.de> writes:
> 
> | Andreas Kohn wrote:
> | 
> | >So, if I read this correctly, "Note that implementers can make this
> | >change in a binary compatible way by providing both overloads; this
> | >would be a conforming extension." overloads could be added to libstdc++
> | >without violating the standard?
> | >
> | >Is anything like that planned?
> | >
> | Ok, I'm going to apply the below to mainline (would be 3.5.0 or 4.0), not to
> | the release branch, however, since we want complete backward and forward
> | compatibility.
> 
> Still, I find the need to this addition very dubious.
> 
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?

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20040813/c9b6ac5b/attachment.sig>


More information about the Libstdc++ mailing list