Bernd Eggink (admin@rzaix13.uni-hamburg.de) wrote:
> Kevin Cline (kcline@ventures) wrote:
> >  What should the following function return, a pointer to a null byte,
> >  or the null pointer?

> >  #include <strstream.h>
> >  char *f() {
> >   ostrstream ost;
> >   return ost.str();
> >  }

> >  Sun C++ 4.0.1 returns a null pointer.  Is that a bug?
> >  What does the proposed standard say?

> The Draft eliminates i/ostrstream and replaces them by i/ostringstream,
> which deal with objects of the standard class string.

> The current practice is that ostrstream::str() may return a null pointer
> if the buffer is empty. It's implementation dependant; some libraries
> return a pointer to a null byte.

Does this mean that in the new standard, strstreams don't even exist and
any code using string formatting is broken?! It also seems like
efficiency if traded for power when you could easily have both.

John Williams
johnw@jove.acs.unt.edu
"Life is case sensitive."

johnw@jove.acs.unt.edu (John Robert Williams) writes:

>Bernd Eggink (admin@rzaix13.uni-hamburg.de) wrote:

>> The Draft eliminates i/ostrstream and replaces them by i/ostringstream,
>> which deal with objects of the standard class string.

>> The current practice is that ostrstream::str() may return a null pointer
>> if the buffer is empty. It's implementation dependant; some libraries
>> return a pointer to a null byte.

>Does this mean that in the new standard, strstreams don't even exist and
>any code using string formatting is broken?! It also seems like
>efficiency if traded for power when you could easily have both.

The C++ standard will probably contain strstreams in an appendix of
"deprecated features".  A "deprecated" feature is one which may be
removed from the language in the next standard, and which it would
be better not to use in any case. (Usually because it is dangerous
or because there are better alternatives available.)

In the case of strstreams, stringstreams are easier to use and much
safer.  There is no reason to assume they will be less efficient than
strstreams. I wouldn't be surprised if in some implementations they
were more efficient than strstreams.

But even if strstreams don't appear in the standard, implementations
will continue to supply them for a while. A C++ vendor can't just
abandon customer code if it expects to stay in business. C++
implementations have historically supported obsolete features for
significant periods of time, often for years.
--
Steve Clamage, stephen.clamage@eng.sun.com

In article <3l1ruv$fhc@engnews1.eng.sun.com>,
   clamage@Eng.Sun.COM (Steve Clamage) wrote:

 [snip]

:The C++ standard will probably contain strstreams in an appendix
:of "deprecated features".  A "deprecated" feature is one which may
:be removed from the language in the next standard, and which it
:would be better not to use in any case. (Usually because it is
:dangerous or because there are better alternatives available.)
:
:In the case of strstreams, stringstreams are easier to use and
:much safer.  There is no reason to assume they will be less
:efficient than strstreams. I wouldn't be surprised if in some
:implementations they were more efficient than strstreams.

It depends.  I've used strstream's for some applications where I
doubt that stringstream's would have worked--the case I'm thinking
of used a ostrstream constructed on a fixed portion of a buffer to
format output records that were Cobol compatible.  The ostrstream
constructed in this fashion guaranteed no field overflow--a
difficult promise to make with the width manipulator--and made the
order of assigning fields into the record independent of the actual
record layout.  The member function in the base class looked like
this:

OutputIFV::formatField(size_t offset, size_t length, string val)
{
    memset(buffer + offset, ' ', length);
    ostrstream str(buffer + offset, length);
    str << val;
}

Construction of the ostrstream in this case took virtually no
overhead.

I agree that stringstream would be better for most applications.

 --Paul J. Ste. Marie, pstemari@well.sf.ca.us, pstemari@erinet.com

The Financial Crimes Enforcement Network claims that they capture every
public posting that has their name ("FinCEN") in it.  I wish them good hunting.

Kevin Cline (kcline@ventures) wrote:
>  What should the following function return, a pointer to a null byte,
>  or the null pointer?

>  #include <strstream.h>
>  char *f() {
>   ostrstream ost;
>   return ost.str();
>  }

>  Sun C++ 4.0.1 returns a null pointer.  Is that a bug?
>  What does the proposed standard say?

The Draft eliminates i/ostrstream and replaces them by i/ostringstream,
which deal with objects of the standard class string.

The current practice is that ostrstream::str() may return a null pointer
if the buffer is empty. It's implementation dependant; some libraries
return a pointer to a null byte.


--
+----------------------------------+
|          Bernd Eggink            |
|    Rechenzentrum Uni Hamburg     |
| admin@rzaix13.rrz.uni-hamburg.de |
+----------------------------------+

What should the following function return, a pointer to a null byte,
or the null pointer?

#include <strstream.h>
char *f() {
 ostrstream ost;
 return ost.str();
}

Sun C++ 4.0.1 returns a null pointer.  Is that a bug?
What does the proposed standard say?
--
Kevin Cline

--
Kevin Cline