NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/cplus/13231

Text File | 1992-09-02 | 3.6 KB | 73 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!news.mentorg.com!sdl!adk
From: [e-mail] (Ajay Kamdar)
Subject: Re: istrstream
Message-ID: <[e-mail]>
Organization: Mentor Graphics Corp. - IC Group
References: <[e-mail]> <[e-mail]>
Date: Wed, 2 Sep 1992 16:30:01 GMT
Lines: 62

In article <[e-mail]> [e-mail] (Joe Buck) writes:
>In article <[e-mail]> [e-mail] (Ajay Kamdar) writes:
>>Why do istrstream constructors take a char* instead of a const char* ?
>>This either stops me from reading a formatted input string (which I get
>>as a const char*) as an istrstream, or compels me to cast away the const
>>on the string when constructing the istrstream.
>
>This annoys me too.  The reason appears to be that istrstream and
>ostrstream are both derived from strstream, and it is the strstream
>constructor that requires the "char *" argument.  Still, it would be nice
>if this could be avoided.  I despise casting away const, and currently
>this is the only place where I feel compelled to do it.  It still may
>not be safe, because of putback.
>

I guess you meant that istrstream derives from strstreambase and not
strstream, and that the strstreambase has a CTOR which takes a char*
argument.

It is unfortunate that the fact that strstreambase has a char* CTOR should
dictate that istrstream should have a char* CTOR too. I would have much
preferred that the istrstream have a const char* CTOR, and that the
istrstream class cast away the const to create the strstreambase part of
it self. Along with casting away the const internally, istrstream would
also set up some other conditions in strstreambase which would ensure that
even though the strstreambase was created with a char* argument, it does not
actually modify the buffer. This would making the cast away of the const
purely an implementation detail of the istrstream class while still
maintaining the constness of its CTOR argument.

Such internal casting away of const purely to facilitate implementation
is perectly safe. I use such a technique to implement manipulators
and iterators for containers. I implement my iterators by deriving privately
from the manipulator, casting away the const of the argument in the iterator
CTOR to construct the manipulator, and ensuring in the iterator member
functions (which would be all const functions) that only the const member
functions of the manipultor are ever called from the iterator interface.

>Depending on the implementation, I suppose that it is possible that
>istream::putback(char) might modify the argument to the istrstream
>constructor, which could cause trouble if you passed a string argument
>and the code modified the string (possibly causing a bus error if the
>string is in ROM).

Note that istream::putback(char) only attempts to put back a character
into the input stream. It is not required to succeed, and in fact if the
character being put back is not the last character extracted, the effect
of putback() is undefined. Hence in case of istrstream, it would be ok
if putback(char c) simply moved the get pointer one character back without
any attempt to write its argument into the stream.

Is the standards committee leaning towards an istrstream() which takes
a char* argument? Or is it trying to work things such that it takes a
const char* argument? I would strongly urge it do the latter.

- Ajay

--
I speak for none but myself.

Ajay Kamdar                               Email : [e-mail]
Mentor Graphics, IC Group (Warren, NJ)    Phone : [phone]