Re: [orbitcpp-list] build issues, work-around

[<bb...@ya...>]

I would prefer to see an autoconf test. 
All STL implementation from now on must support ostringstream to have
a hope of calling themselves standard compliant. For this reason I'd
prefer to leave the ostringstream in there. It is legal code and it
follows "the C++ way" of doing things. Only legacy implementations of
the STL would have a problem.

From memory there is a standard compliant STL drop-in for gcc-2.95
(libstdc++-2.95.10 from memory) which supports ostringstream.

Note that gcc 2.95 requires the -fhonor-standard flag in some cases
to make the standard compliance code kick in.


--
Rich

 --- Brian Craft <bc...@th...> wrote: 
> Would you accept a patch to fix the ostringstream thing? This could
> be either a
> patch to conditionally use ostrstream (which I believe would
> require an
> autoconf test to see which is available), or a patch to ditch it
> entirely and
> use sprintf to a static buffer. The latter has the disadvantage
> that it could
> overflow, but I think it's a safe call that no one will have more
> than a google
> or two of skeleton wrappers. So, say, 100 bytes is way more than
> needed.


http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.