Thomas Holaday wrote:
>
> In article <358A9334.2781@wizard.net>, kuyper@wizard.net says...
> > Thomas Holaday wrote:
> > ...
> > >         ostrstream ost;
> > >         ost << "here is a semi-portable way to get the ostrstream to " ;
> > You're putting 'semi-portable' and 'MessageBox' within two lines of each
> > other? How many non-Windows implmentations have you programmed for?
> >
>
> How long does it take to implement
>
>         MessageBox(void *, const char *, const char *, long)
>
> for an embedded system?  As compared to, say, implementing ostrstream on
> top of ostringstream? :-)

You miss my point - if you're posting supposedly portable code, it
shouldn't call system specific functions. It doesn't matter whether the
equivalent functions could have been implemented under other systems, it
makes your code less clear to people who are unfamiliar with that
system. In your code, you had:

> > >         MessageBox(0,ost.str(),"Hacking 4-Ever",MB_OK);

A programmer with no familiarity with Windows might not even be able to
guess what the first and fourth arguments to that function did. I
remember what the fourth one does, but I'd have to check my
documentation on the first one. Given the function signature you've
quoted, it would have been clearer to write it as NULL than as 0.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <358A9334.2781@wizard.net>, kuyper@wizard.net says...
> Thomas Holaday wrote:
> ...
> >         ostrstream ost;
> >         ost << "here is a semi-portable way to get the ostrstream to " ;
> You're putting 'semi-portable' and 'MessageBox' within two lines of each
> other? How many non-Windows implmentations have you programmed for?
>

How long does it take to implement

 MessageBox(void *, const char *, const char *, long)

for an embedded system?  As compared to, say, implementing ostrstream on
top of ostringstream? :-)


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Thomas Holaday wrote:
...
>         ostrstream ost;
>         ost << "here is a semi-portable way to get the ostrstream to " ;
>         ost << "delete its own darn buffer" ;
>         MessageBox(0,ost.str(),"Hacking 4-Ever",MB_OK);
>         ost.rdbuf()->freeze(0);

You're putting 'semi-portable' and 'MessageBox' within two lines of each
other? How many non-Windows implmentations have you programmed for?


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Eric Tse wrote in message <35885BBD.9E9FE7DA@scdt.intel.com>...
>I wonder if anyone know from the standard what is the correct way to
>delete the memory return from ostrstream::str()? If so, could
>you quote from the standard, please?
>
>  ostrstream oss;
>  oss << "yo!" << ends;
>  char* c = oss.str();

>  // OPTION 1: aCC v1.12 (HP)
>  delete c;

This seems patently wrong, since you are deleting a pointer to a buffer, not
a single character.

>  // OPTION 2: CC/aCC v1.06 (HP) and VC5.0 (NT)
>  delete [] c;

This seems like it should work

And here is option 3:

oss.freeze(0);  //tells ~ostringstream to free the memory

And here are the requested quotes from the standard:

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

>Eric Tse wrote:
>>
>> I wonder if anyone know from the standard what is the correct way to
>> delete the memory return from ostrstream::str()? If so, could
>> you quote from the standard, please?

>ostrstream is not part of the standard. ostringstream is, but
>ostringstram::str() returns a string, not a char*.

That's not quite right. It is part of the standard in Appendix
D, but is deprecated. "Deprecated" means that a future version
of the standard might drop the feature, and programers are
advised to consider changing to alternative features.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35885BBD.9E9FE7DA@scdt.intel.com>, etse@scdt.intel.com
says...

> I wonder if anyone know from the standard what is the correct way to
> delete the memory return from ostrstream::str()? If so, could
> you quote from the standard, please?

As Mr. DeRocco says, ostrstream isn't in the standard, but if you write
(get ready for a mouthful):

 ostrstream ost;
 ost << "here is a semi-portable way to get the ostrstream to " ;
 ost << "delete its own darn buffer" ;
 MessageBox(0,ost.str(),"Hacking 4-Ever",MB_OK);
 ost.rdbuf()->freeze(0);

I am greatful to Steve Teale for pointing this out in his incomparable
C++ IOStreams Handbook.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi guys,

I wonder if anyone know from the standard what is the correct way to
delete the memory return from ostrstream::str()? If so, could
you quote from the standard, please?


  ostrstream oss;
  oss << "yo!" << ends;
  char* c = oss.str();

  // OPTION 1: aCC v1.12 (HP)
  delete c;

  // OPTION 2: CC/aCC v1.06 (HP) and VC5.0 (NT)
  delete [] c;

HP aCC v1.12 seems to like "delete c", while HP aCC v1.06 and VC5.0
likes "delete [] c"

Thanks,
Eric
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Eric Tse wrote:
>
> I wonder if anyone know from the standard what is the correct way to
> delete the memory return from ostrstream::str()? If so, could
> you quote from the standard, please?

ostrstream is not part of the standard. ostringstream is, but
ostringstram::str() returns a string, not a char*.

--

Ciao,
Paul


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35885BBD.9E9FE7DA@scdt.intel.com>,
  Eric Tse <etse@scdt.intel.com> wrote:
>
> I wonder if anyone know from the standard what is the correct way to
> delete the memory return from ostrstream::str()? If so, could
> you quote from the standard, please?
>
>   ostrstream oss;
>   oss << "yo!" << ends;
>   char* c = oss.str();
>
>   // OPTION 1: aCC v1.12 (HP)
>   delete c;
>
>   // OPTION 2: CC/aCC v1.06 (HP) and VC5.0 (NT)
>   delete [] c;
>
> HP aCC v1.12 seems to like "delete c", while HP aCC v1.06 and VC5.0
> likes "delete [] c"

According to the standard, the correct way of handling this is to use
ostringstream, so you don't have to worry about deleting memory.  The
use of ostrstream is deprecated.

With regards to ostrstream, the usual way of handling the memory is to
return ownership to the stream, e.g.: oss.freeze( 0 ).  The standard
makes no direct statements concerning the return value of str, but in
several places, it does talk about other functions using delete[] to
free memory.  In any case, unless the string holds only a single char,
plain delete is definitly wrong -- the possible alternative is free.
Definitly wrong, in this case, means undefined behavior, which in turn
means that it might work.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]