In article <1157636428.873405.22210@m79g2000cwm.googlegroups.com>,
werasm <w_erasm@telkomsa.net> wrote:

> Alberto Ganesh Barbati wrote:
>
> > the buffer is local to the function, yet I don't see any trouble as the
> > lifetime of the buffer clearly outlives the stream object.
>
 ... memory based stream buffers....

   A lot of the excess copying can be avoid by being less terse,by
using a default constructed stringstream and copying with
an ostreambuf_iterator<char> to the stream and then seeking the
beginning read [seekg(0)] and then reading the stream.

prepending an ostream can be read into a properly sized char array
or vector<char> via std::copy(std::istreambuf_iterator<char>
(stream),...);

   std::ostringstream os;
   // write to os
   foo(os.str().c_str()); // ouch two copies of data

   std::stringstream os;
   // write to os;
   {
      std::vector<char> tmp(std::istreambuf_iterator<char>(os),
         std::std::istream_iterator<char>());  // one copy of data
      tmp.push_back('\0');
      foo(&*tmp.begin());
   }

   initializing a string stream form a '\0' terming terminated char
array does not need to be converted to a string first, since something
like
      std::istringstream   in("20 10");
      // read the stream

   can be done with
      std::stringstream in;
      {
         char *p = "20 10";
         std::ostreambuf_iterator<char> out(in);
         while (*p)
            *out++ = *p++;
         in.seekg();
      }
      // read the stream.
note this does no unnecessary conversions to std::string.

seems like the only thing is simple usages that can be handled simple
stream buffers that don't seek, if you don't seek the stream
[seekp,seekp] then the streambuf's defaults [always fail] will work.
so only thing needed is a constructor to set the buffer and end()
function for output only memory buf

   struct isimplemembuf:std::streambuf
   {
      isimplemembuf(char *start,std::ptrdiff_t size)
      {setg(start,start,start+size}
      char *begin() {return eback();}
      char *end() {return egptr();}
   };

    struct osimplemembuf:std::streambuf
   {
      osimplemembuf(char *start,std::ptrdiff_t size)
      { setp(start,start+size);}
      char *begin() {return pbase();}
      char *end() {return pptr();}
   };

look simple enough:)
    The seekpos and seekoff functions can be written if needed.
Tedious but not complicated...

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it> napisal w
wiadomosci news:a0EKg.92459$zy5.1528159@twister1.libero.it...
> Kristof Zelechovski ha scritto:
>> By the way, there is a problem with the spanbuf because gbump &al. take
>> an
>> int so I have to use a loop or replace them with setg &al. to be able to
>> handle a ptrdiff_t in a portable way.
>
> This fact is known to the LWG, see issue #255
> <http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255>.
>
> The memstream proposal addresses this problem by effectively limiting
> the size of the buffer to std::numeric_limits<int>::max().
>
>> I think it is a defect in the
>> standard making setg &al. completely deprecated.
>
> I don't follow you. setg/setp are not deprecated! (BTW do we agree on
> the meaning of the word "deprecated"? It means "Normative for the
> current edition of the Standard, but not guaranteed to be part of the
> Standard in future revisions").
>

They are crippled in a way that makes using them inefficient and cumbersome
and therefore should be avoided and replaced by calls to setg &al everywhere
unless this defect is going to be fixed.  I am glad the issue has been
reopened.

Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:

> the buffer is local to the function, yet I don't see any trouble as the
> lifetime of the buffer clearly outlives the stream object.

How about having a new stream type that forces this issue. You have to
provide the size of the buffer. This is most often known at compile
time, therefore:

void output()
{
  omemstream<BUFLEN> stream;
  stream << "Integer Set: " << 5 <<  ", " << 10 << ", etc. "
    << std::endl;
  c_legacy_function_that_reads_buffer( stream.c_str(), stream.length()
);
  //length() returns bytes streamed, size() return BUFLEN?
}

I think it would be good to discern also, between a stream that adds a
NULL terminator by default, and one that does not. This could be an
instantiation option with the default choice being the safer route. For
safety purposes implementations could also specify the actual size to
be one greater than BUFLEN, and force the last to remain NULL
terminated and untouched.

template <unsigned size>
class X
{
  enum{ StreamSz = size+1 }
  char buffer_[StreamSz];
};

I have not looked at your proposal, but could this be considered?

Regards,

Werner

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Sorry for top posting, my OE fails to quote correctly.
I need to read from a region.  And I already have implemented your
suggestion - it is called basic_spanbuf in my toolset.  But I can hardly
imagine a C++ programmer that does not need such a streambuf some time.  If
you want to implement a buffered stream from/to an external device, the
spanbuf is the common denominator (base class).
By the way, there is a problem with the spanbuf because gbump &al. take an
int so I have to use a loop or replace them with setg &al. to be able to
handle a ptrdiff_t in a portable way.  I think it is a defect in the
standard making setg &al. completely deprecated.
Chris

Uzytkownik "Carl Barron" <cbarron413@adelphia.net> napisal w wiadomosci
news:260820062058375666%cbarron413@adelphia.net...
In article <ecp9f8$1uhd$1@news2.ipartners.pl>, K   i   tof    elechovski
<giecrilj@stegny.2a.pl> wrote:

> U   ytkownik ""P.J. Plauger"" <pjp@dinkumware.com> napisa    w wiadomo   ci
> news:1OGdnWSxAeG7EHDZnZ2dnUVZ_sidnZ2d@giganews.com...
> > strstream has some obvious design flaws that make it easy to
> > use improperly. But it still does certain jobs with less fuss
> > and overhead than its putative replacement, template class
> > basic_stringstream. I favor the latter for cleanliness, the
> > former for speed.
> >
>
> And I need wstrstream - and it is not there.
> Chris
>

How are you using string streams??  write a region and read it or write
a region and reprocess it??

Its easier to write a stream buffer to or from a fixed region. Its also
likely to be faster than a more general dynamic solution.   A fixed
region buffer only needs to convert the seeking syntax to pointer
arithmetic, and reset the internal buffer ptrs if the seek is in the
memory range, else return error. Default
underflow() and overflow() will prevent buffer overrun being actually
performed.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Kristof Zelechovski wrote:
> Sorry for top posting, my OE fails to quote correctly.
> [..]

Get OE-QuoteFix.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Kristof Zelechovski ha scritto:
> Sorry for top posting, my OE fails to quote correctly.
> I need to read from a region.  And I already have implemented your
> suggestion - it is called basic_spanbuf in my toolset.  But I can hardly
> imagine a C++ programmer that does not need such a streambuf some time.  If
> you want to implement a buffered stream from/to an external device, the
> spanbuf is the common denominator (base class).

I have just submitted the memstream proposal I mentioned in another
post. However, it's not meant to be a basic class for any buffered
access to an external device. For that (and more) I suggest to consider
the boost.iostream library.

> By the way, there is a problem with the spanbuf because gbump &al. take an
> int so I have to use a loop or replace them with setg &al. to be able to
> handle a ptrdiff_t in a portable way.

This fact is known to the LWG, see issue #255
<http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255>.

The memstream proposal addresses this problem by effectively limiting
the size of the buffer to std::numeric_limits<int>::max().

> I think it is a defect in the
> standard making setg &al. completely deprecated.

I don't follow you. setg/setp are not deprecated! (BTW do we agree on
the meaning of the word "deprecated"? It means "Normative for the
current edition of the Standard, but not guaranteed to be part of the
Standard in future revisions").

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow ha scritto:

> It seems to me that you are making assumptions about how both
> std::string and std::stringstream should be implemented. If the need is
> sufficiently high there is nothing, AFAIKS, that prevents implementors
> form providing sophisticated implementations that seriously reduce the
> need for copying buffers of char around.

No matter how you implement them, there are copies that stringstreams
cannot optimize away. For example, consider the input case:

  char mybuffer[BUFLEN];
  c_legacy_function_that_fills_buffer(mybuffer, BUFLEN);
  std::istringstream stream(std::string(mybuffer, mybuffer + BUFLEN));

A smart implementation might be able to avoid the copy of the buffer
once it's inside the temporary std::string object, but I can't see how
you could implement std::string without copying the content of mybuffer
at least once. You can't just make std::string hold a pointer to the
buffer, because the buffer might disappear anytime leaving the
std::string with a dangling pointer thus violating its invariant.

Same for the output case, because at some time you will need to call
std::string::copy, strcpy or memcpy to extract the characters from the
string and put them into the memory buffer. Of course, there are use
cases where you might be able to use std::string::data() right away, but
if what you want is to fill some memory buffer, you must copy the data
*there*, sooner or later.

So no future (hopefully smarter) implementation can do better than that.
When it comes to looking at existing (non-refcounting) implementations,
we see that the buffer is usually going to be copied at least twice in
both cases. I don't see the trend changing sooner, but it's just me, of
course and I know it's a weak argument.

> OTOH, if the need is limited then rather than add further maintenance
> overheads to the Standard Library those needing it can write their own.

I can't say how limited or not is the need. What I believe is that this
proposal addresses most (if not all) issues that may force a programmer
to prefer strstreams to stringstreams.

> There is also a practical option of providing a suitable type via Boost.

That is definitely an option, of course. However, Boost already has the
boost.iostream library that does that and much more.

> BTW, one serious problem with strstream types based on an externally
> provided buffer concerns when they can be returned by reference (or
> pointer)

Sorry, I don't understand. Could you please elaborate?

> I am not trying to pour cold water on your proposal, just trying to
> point out that there are probably better ways to achieve your objective.

It is a fact that this issue periodically arises in this NG every few
months and every time the thread is concluded by a "it would be a nice
addition, but there is no formal proposal". I just happened to have
written one and I posted it. I just hope it might raise discussion further.

About "better ways", the only reasonable one I see is the use of the
boost.iostream library. With that, memstreams can easily be implemented
using basic_array_sink/basic_array_source devices. If you see other
ways, please elaborate.

BTW, does anyone know if boost.iostream is being considered for
standardization? Of course, if boost.iostream is being considered, then
there there would be no need to consider this proposal also... ;-)

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <BTGIg.85887$_J1.772169@twister2.libero.it>, Alberto Ganesh
Barbati <AlbertoBarbati@libero.it> writes
>> BTW, one serious problem with strstream types based on an externally
>> provided buffer concerns when they can be returned by reference (or
>> pointer)
>
>Sorry, I don't understand. Could you please elaborate?

It is a matter of lifetimes. An externally provided buffer better be
either of static storage duration or of dynamic storage duration. If it
is neither of those (i.e. it is local to a function) you are in trouble.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow ha scritto:
> In article <BTGIg.85887$_J1.772169@twister2.libero.it>, Alberto Ganesh
> Barbati <AlbertoBarbati@libero.it> writes
>>> BTW, one serious problem with strstream types based on an externally
>>> provided buffer concerns when they can be returned by reference (or
>>> pointer)
>>
>> Sorry, I don't understand. Could you please elaborate?
>
> It is a matter of lifetimes. An externally provided buffer better be
> either of static storage duration or of dynamic storage duration. If it
> is neither of those (i.e. it is local to a function) you are in trouble.
>

As long as the stream object is a local object, I see no problem with
local buffers. For example, in the typical use case I already mentioned:

void input()
{
  char mybuffer[BUFLEN];
  c_legacy_function_that_fills_buffer(mybuffer, BUFLEN);
  imemstream stream(mybuffer, BUFLEN);
  // extract something from stream
}

the buffer is local to the function, yet I don't see any trouble as the
lifetime of the buffer clearly outlives the stream object.

Same for the typical output scenario:

void output()
{
  char mybuffer[BUFLEN];
  omemstream stream(mybuffer, BUFLEN);
  // write something into stream
  c_legacy_function_that_reads_buffer(mybuffer, BUFLEN);
}

Of course, if you construct a static or dynamically allocated stream
object then you'd better provide a similarly static or dynamically
allocated buffer, but it seems a rather rare and exotic use case to me.
Even when using stringstreams the stream objects tend to be short-lived
locals.

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:
> In article <BTGIg.85887$_J1.772169@twister2.libero.it>, Alberto Ganesh
> Barbati <AlbertoBarbati@libero.it> writes
> >> BTW, one serious problem with strstream types based on an
> >> externally provided buffer concerns when they can be
> >> returned by reference (or pointer)

> >Sorry, I don't understand. Could you please elaborate?

> It is a matter of lifetimes. An externally provided buffer
> better be either of static storage duration or of dynamic
> storage duration. If it is neither of those (i.e. it is local
> to a function) you are in trouble.

If we're going to ban all the ways you can possibly get a
dangling pointer, it won't be C++ any more.  In practice, in
almost all of the uses of strstream with a user defined buffer,
the strstream object is on the stack; the buffer is either on
the stack as well (in which case, it automatically has a longer
lifetime than the strstream object), or is acquired from an
std::vector<char> (in which case, you do have to be careful
about increasing the capacity of the vector).

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

U=BFytkownik ""P.J. Plauger"" <pjp@dinkumware.com> napisa=B3 w wiadomo=B6=
ci=20
news:1OGdnWSxAeG7EHDZnZ2dnUVZ_sidnZ2d@giganews.com...
> strstream has some obvious design flaws that make it easy to
> use improperly. But it still does certain jobs with less fuss
> and overhead than its putative replacement, template class
> basic_stringstream. I favor the latter for cleanliness, the
> former for speed.
>

And I need wstrstream - and it is not there.
Chris=20


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci
news:1156410282.874936.229020@75g2000cwc.googlegroups.com...
> Gennaro Prota wrote:
>
>> Thanks to you and Howard for info "from the trench" :-) I know it
>> hasn't been removed, but I thought "reinstatement" was the contrary of
>> "deprecation" in ISO-standardese. What's the right term instead?
>> "Undeprecation"?
>
> The de- in deprecation has a meaning somewhat similar to un-, so
> presumably, the correct term would be precation, or maybe
> reprecation:-).
>
Imprecation.
Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <ecp9f8$1uhd$1@news2.ipartners.pl>, K=F8i=B9tof =AEelechovski
<giecrilj@stegny.2a.pl> wrote:

> U=BFytkownik ""P.J. Plauger"" <pjp@dinkumware.com> napisa=B3 w wiadomo=B6=
ci=20
> news:1OGdnWSxAeG7EHDZnZ2dnUVZ_sidnZ2d@giganews.com...
> > strstream has some obvious design flaws that make it easy to
> > use improperly. But it still does certain jobs with less fuss
> > and overhead than its putative replacement, template class
> > basic_stringstream. I favor the latter for cleanliness, the
> > former for speed.
> >
>=20
> And I need wstrstream - and it is not there.
> Chris=20
>=20
=20
How are you using string streams??  write a region and read it or write
a region and reprocess it??=20

Its easier to write a stream buffer to or from a fixed region. Its also
likely to be faster than a more general dynamic solution.   A fixed
region buffer only needs to convert the seeking syntax to pointer
arithmetic, and reset the internal buffer ptrs if the seek is in the
memory range, else return error. Default
underflow() and overflow() will prevent buffer overrun being actually
performed.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Howard Hinnant ha scritto:
> In article <rrdbe2h5a9tm1g6lhb1hhufga6v6klfovq@4ax.com>,
>  gennaro_prota@yahoo.com (Gennaro Prota) wrote:
>
>> Hi guys,
>>
>> a very simple question: is there any plan/intention for reinstatement
>> of strstream? Has this been recently discussed in WG21?
>
> There has been no discussion in the LWG along these lines recently (in
> the past couple of years).  More distantly, there has been informal
> discussion of replacing the functionality of strstream with more modern
> practice (specifically, the ability to perform I/O with a
> client-supplied buffer).  However an actual proposal has never emerged.
> Such a proposal would be most welcome.
>

In fact, I happen to have a proposal for it. You can download it from
here: <http://iaanus.com/memstream.pdf>.

That's the first such thing I write and I'm not a standardese-writer, so
I apologize in advance for the possibly inaccurate wording. I just hope
it can be useful in some way.

Ganesh

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <EdqIg.84045$zy5.1449354@twister1.libero.it>, Alberto Ganesh
Barbati <AlbertoBarbati@libero.it> writes
>In fact, I happen to have a proposal for it. You can download it from
>here: <http://iaanus.com/memstream.pdf>.
>
>That's the first such thing I write and I'm not a standardese-writer, so
>I apologize in advance for the possibly inaccurate wording. I just hope
>it can be useful in some way.

Let me quote the opening paragraphs of your proposal:

<quote>
A proposal to add stream objects based on fixed memory buffers
(revision 1)
Motivation
The C++03 standard deprecates the strstream class templates, while the
stringstream counterparts are usually considered a replacement. The
string-based streams indeed have a better interface, however they have
the following drawbacks:

1. If the user has initial data stored in a character buffer, making an
input stream to access that data requires copying the entire buffer into
a string object. Moreover, the stringbuf object may need to internally
perform an additional copy of such string.

2. If the user require output data to be stored in a previously
allocated character buffer (for example because he must interface with a
legacy C function), up to two copies of the entire buffer are performed:
one might occur during the execution of the member function str() itself
and the other when copying the returned string object into the
preallocated buffer.
</quote>

It seems to me that you are making assumptions about how both
std::string and std::stringstream should be implemented. If the need is
sufficiently high there is nothing, AFAIKS, that prevents implementors
form providing sophisticated implementations that seriously reduce the
need for copying buffers of char around.

OTOH, if the need is limited then rather than add further maintenance
overheads to the Standard Library those needing it can write their own.

There is also a practical option of providing a suitable type via Boost.

BTW, one serious problem with strstream types based on an externally
provided buffer concerns when they can be returned by reference (or
pointer)

I am not trying to pour cold water on your proposal, just trying to
point out that there are probably better ways to achieve your objective.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Earl Purple wrote:
> Gennaro Prota wrote:

> > ... is there any plan/intention for reinstatement
> > of strstream? ...
> >
> what exactly would be the advantage of bringing it back - what could
> you achieve with it that you can't already do with stringstream?


Avoiding the inefficiency of std::string?

(That's why I'm using it.)

-- Alan McKenney

[line-eater fodder]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <rrdbe2h5a9tm1g6lhb1hhufga6v6klfovq@4ax.com>,
 gennaro_prota@yahoo.com (Gennaro Prota) wrote:

> Hi guys,
>
> a very simple question: is there any plan/intention for reinstatement
> of strstream? Has this been recently discussed in WG21?

There has been no discussion in the LWG along these lines recently (in
the past couple of years).  More distantly, there has been informal
discussion of replacing the functionality of strstream with more modern
practice (specifically, the ability to perform I/O with a
client-supplied buffer).  However an actual proposal has never emerged.
Such a proposal would be most welcome.

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Earl Purple wrote:
> Gennaro Prota wrote:

> > a very simple question: is there any plan/intention for
> > reinstatement of strstream? Has this been recently discussed
> > in WG21?

> what exactly would be the advantage of bringing it back - what
> could you achieve with it that you can't already do with
> stringstream?

Format text into a char[] buffer.  It's useful if you have to
interface to a legacy interface, to write into a memory mapped
file, and a few other things.

Of course, writing your own memory_streambuf isn't that hard
either.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kanze wrote:


> Format text into a char[] buffer.  It's useful if you have to
> interface to a legacy interface, to write into a memory mapped
> file, and a few other things.
>
> Of course, writing your own memory_streambuf isn't that hard
> either.

so maybe the standard (or possibly boost at first if they haven't
already) should implement a memory_streambuf (probably as
memory_basic_streambuf) and then one can use that instead of strstream.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <1156322203.785878.132850@i42g2000cwa.googlegroups.com>,
Earl Purple <earlpurple@gmail.com> wrote:

> kanze wrote:
>
>
> > Format text into a char[] buffer.  It's useful if you have to
> > interface to a legacy interface, to write into a memory mapped
> > file, and a few other things.
> >
> > Of course, writing your own memory_streambuf isn't that hard
> > either.
>
> so maybe the standard (or possibly boost at first if they haven't
> already) should implement a memory_streambuf (probably as
> memory_basic_streambuf) and then one can use that instead of strstream.
>
   Boost does have a high level stream buffer library,

see http://boost.org/libs/iostreams/doc/index.html

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Wed, 23 Aug 2006 03:03:13 GMT, pjp@dinkumware.com ("P.J. Plauger")
wrote:

>"Gennaro Prota" <gennaro_prota@yahoo.com> wrote in message
>news:rrdbe2h5a9tm1g6lhb1hhufga6v6klfovq@4ax.com...
>
>> a very simple question: is there any plan/intention for reinstatement
>> of strstream? Has this been recently discussed in WG21?
>
>strstream has never been uninstated, just deprecated.

Thanks to you and Howard for info "from the trench" :-) I know it
hasn't been removed, but I thought "reinstatement" was the contrary of
"deprecation" in ISO-standardese. What's the right term instead?
"Undeprecation"?

--
Gennaro Prota

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Gennaro Prota" <gennaro_prota@yahoo.com> wrote in message
news:80voe25heksd9uh2vfftgjeme7ngko70i5@4ax.com...

> On Wed, 23 Aug 2006 03:03:13 GMT, pjp@dinkumware.com ("P.J. Plauger")
> wrote:
>
>>"Gennaro Prota" <gennaro_prota@yahoo.com> wrote in message
>>news:rrdbe2h5a9tm1g6lhb1hhufga6v6klfovq@4ax.com...
>>
>>> a very simple question: is there any plan/intention for reinstatement
>>> of strstream? Has this been recently discussed in WG21?
>>
>>strstream has never been uninstated, just deprecated.
>
> Thanks to you and Howard for info "from the trench" :-) I know it
> hasn't been removed, but I thought "reinstatement" was the contrary of
> "deprecation" in ISO-standardese. What's the right term instead?
> "Undeprecation"?

IME, deprecated features seldom get undeprecated, but they often
continue in deprecation limbo longer than their original enemies
planned. All deprecation does, from a practical standards sense,
is lower the barrier to removing a feature at some point in the
future. But most people celebrate the pejorative overtones --
don't use this awful/obsolete feature 'cause it's gonna go away
Real Soon Now (tm).

strstream has some obvious design flaws that make it easy to
use improperly. But it still does certain jobs with less fuss
and overhead than its putative replacement, template class
basic_stringstream. I favor the latter for cleanliness, the
former for speed.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota wrote:

> Thanks to you and Howard for info "from the trench" :-) I know it
> hasn't been removed, but I thought "reinstatement" was the contrary of
> "deprecation" in ISO-standardese. What's the right term instead?
> "Undeprecation"?

The de- in deprecation has a meaning somewhat similar to un-, so
presumably, the correct term would be precation, or maybe
reprecation:-).

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hi guys,

a very simple question: is there any plan/intention for reinstatement
of strstream? Has this been recently discussed in WG21?

--
Gennaro Prota

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota wrote:

> Hi guys,
>
> a very simple question: is there any plan/intention for reinstatement
> of strstream? Has this been recently discussed in WG21?
>
what exactly would be the advantage of bringing it back - what could
you achieve with it that you can't already do with stringstream?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Gennaro Prota" <gennaro_prota@yahoo.com> wrote in message
news:rrdbe2h5a9tm1g6lhb1hhufga6v6klfovq@4ax.com...

> a very simple question: is there any plan/intention for reinstatement
> of strstream? Has this been recently discussed in WG21?

strstream has never been uninstated, just deprecated. So far there
has been no discussion of actually removing strstream from the next
C++ Standard. Note that all the C headers are also deprecated, and
the odds of them disappearing from any useful C++ implementation
are zip-a-dee-doo-dah. Which means the C++ Committee would have to
be unusually perverse to remove those headers from the C++ Standard.
My bet is that strstream will stick around too.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]