Re: [C++] ostrstream vs. sprintf

From: Henrik Stuart (hstuart@geocities.com)
Date: 02/06/02


Greetings,

On Wednesday, February 06, 2002 8:39:01 AM you wrote:
> On Tue, 5 Feb 2002, Karl B Buchner wrote:

>> I was looking through some C++ documentation, and I noticed the
>> ostrstream class (heretofor unbeknownst to me).

> strstring is deprecated.  Its replacement within the IOStreams framework
> is stringstream.  A standard example would be:

>> From a look at the description ostrstream has the following
>> advantages over sprintf: -dynamic size

   The advantage with strstream is only partial unless you always
   allocate with a buffer of fixed size. :o)  There are some rather
   tricky memory issues with dynamically allocated memory in
   strstreams, but as Daniel writes, it's deprecated so we luckily do
   not need to worry about that. :o)

   The places where sprintf popularly is used in CircleMud is when
   we're dealing with: send_to_char, act, SEND_TO_Q and mudlog. Of
   these, neither act or mudlog translate easily to a sane operator<<
   definition (it is doable with a bit of thought and patience to get
   it sane, though).

   Since we will be using stringstream only for output it is usually
   nicer merely to use std::ostringstream as you don't have to worry
   about it performing checks and maintain buffers for input - it is
   doable to use operator>> to read data from the descriptor, but in
   general we don't really need to know about this when we're
   outputting stuff. :o)  (Hence and std::istringstream would probably
   do well somewhere in descriptor_data with a few sensible changes to
   deal with timeout on socket reads and/or polling and/or threading).

> The equivalent in Standard C++ isn't necessarily cleaner:

>   oss << std::left << std::setw(5) << foobar;

   Another few remarks. :o)
   std::left and std::setw used in Daniel's example are what is
   declared as stream manipulators, and they can control different
   aspects of your stream. Most of these are not normally included,
   but need be included from the <iomanip> header file. There are, of
   usual interest, also manipulators to control fill characters,
   skipping of whitespace, precision of floating point numbers, and
   many more.

   Usually, most manipulators are only in effect until "the next
   formatted field is written," or however the standard goes these
   days.

>> one disadvantage that I noticed was cases where you want to set the
>> size of the parameter (i.e. %20s).

   As far as I recall I have seen the %20s a few places in the code,
   might just be misrememberance. :o)

> For C++, you might consider migrating to std::string, in which case you
> can handle this explicitly with the substr() member, like:

   std::string is a lovely thing - no more str_dup's you have to worry
   about deallocating either, and lovely destructors. *sighs happily and
   returns to his c++*

--
Yours truly,
  Henrik Stuart (http://www.unprompted.com/hstuart/)

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   | Newbie List:  http://groups.yahoo.com/group/circle-newbies/   |
   +---------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 06/25/03 PDT