Re: sstream

Re: sstream

[Benjamin Kosnik]

> I got so tired of not being able to use stringstreams that I wrote this. It 
> is probably not all according to the standard but it is a lot better than 
> the nothing that we have got currently. I suppose that I had been better of 
> working on libstdc++-v3 but this was faster.

v3 already has working stringstreams. Even standards-compliant
stringstreams. Perhaps you should use them?

-Benjamin

Re: sstream

[Joe Buck]

> v3 already has working stringstreams. Even standards-compliant
> stringstreams. Perhaps you should use them?

Benjamin,

If you want to promote the use of v3, then the first thing you might want
to do is to update http://sourceware.cygnus.com/libstdc++/status.html
and the files linked to it.  Right now, the status refers to the 2.90.6
release and indicates that the code is nowhere near ready to use.  I
know that the current version is better than that, but if you don't
update the status pages people will rightly assume that the code is
not ready to use.

Furthermore there are a lot of people who need binary compatibility
with libstdc++ v2 shared libraries already out there.

Re: sstream

[Jeffrey A Law]

  In message < 200002161831.KAA11821@possibly.synopsys.com >you write:
  > 
  > > v3 already has working stringstreams. Even standards-compliant
  > > stringstreams. Perhaps you should use them?
  > 
  > Benjamin,
  > 
  > If you want to promote the use of v3, then the first thing you might want
  > to do is to update http://sourceware.cygnus.com/libstdc++/status.html
  > and the files linked to it.  Right now, the status refers to the 2.90.6
  > release and indicates that the code is nowhere near ready to use.  I
  > know that the current version is better than that, but if you don't
  > update the status pages people will rightly assume that the code is
  > not ready to use.
  > 
  > Furthermore there are a lot of people who need binary compatibility
  > with libstdc++ v2 shared libraries already out there.
I talked to Benjamin last week about some of this stuff, and we may be at
a point where switching to libstdc++ v3 makes sense.

My understanding is v3 now has a superset of the functionality found in v2
and should work for all the common platforms (some configury hacking will
be necessary for oddball platforms).  Canadian crosses haven't been tested,
but Benjamin thinks they will work modulo the usual nits.

The biggest question in my mind is compatibility and interactions with 
libio on systems which embed libio into libc (ie linux).

jeffk

Re: sstream

[Martin v. Loewis]

> I talked to Benjamin last week about some of this stuff, and we may be at
> a point where switching to libstdc++ v3 makes sense.

I'd still like a comment on the original submission of that <sstream>
header. I think it should be integrated with the v2 libstdc++ -
whether or not this eventually appears in a release.

Regards,
Martin

Re: sstream

[Joe Buck]

Martin writes:
> I'd still like a comment on the original submission of that <sstream>
> header. I think it should be integrated with the v2 libstdc++ -
> whether or not this eventually appears in a release.

I'd vote for putting it in, to benefit those who have an immediate need
for it.  v3 is not yet ready.

Re: sstream

[Joe Buck]

> I talked to Benjamin last week about some of this stuff, and we may be at
> a point where switching to libstdc++ v3 makes sense.

I repeat my request that http://sourceware.cygnus.com/libstdc++/status.html
be updated, since according to it, v3 is nowhere near ready (but it
shows the state of the world as of the 2.90.6 snapshot).

(There are release notes for 2.90.7, but the bugs page and status page
refer to 2.90.6).

> The biggest question in my mind is compatibility and interactions with 
> libio on systems which embed libio into libc (ie linux).

We can't consider switching to v3 until this has been shown to work; it
is a requirement (one that shouldn't be difficult to satisfy, given
the long experience of the folks involved).

I think that, for Linux it would be sufficient to have it working with
glibc 2.1.x or newer (though folks who need to work with an older glibc
would be free to submit patches).

Also, what mechanisms will v3 provide to allow syncing between stdio
and iostreams on platforms such as *BSD that don't use libio in their C
library?

Re: sstream

[Benjamin Scherrey]

I concur - v3 is nowhere near ready for prime time although the guys
are moving ahead diligently. Its a big friggin library with lots of
nuances. It would be real nice if a piecemeal integration of v3
components into v2 could be made but I dunno how deep and intrusive
the dependencies are - I fear this option is not practical. FWIW -
providing a stringstream as a stop gap measure for v2 would probably
be a fantastic benefit because use of strstream (and forgetting to
unfreeze stuff correctly) is one of the biggest source of memory leaks
that I find in people's C++ code and in every case a stringstream
would have prevented and was what the original code would have
preferred in the first place.

	thanx & later,

		Ben Scherrey

Joe Buck wrote:
> 
> Martin writes:
> > I'd still like a comment on the original submission of that <sstream>
> > header. I think it should be integrated with the v2 libstdc++ -
> > whether or not this eventually appears in a release.
> 
> I'd vote for putting it in, to benefit those who have an immediate need
> for it.  v3 is not yet ready.

Re: sstream

[Gerald Pfeifer]

On Mon, 21 Feb 2000, Joe Buck wrote:
> I repeat my request that http://sourceware.cygnus.com/libstdc++/status.html
> be updated, since according to it, v3 is nowhere near ready (but it
> shows the state of the world as of the 2.90.6 snapshot).

That has been done know, as far as I saw, as part of libstdc++-2.90.8.

> Also, what mechanisms will v3 provide to allow syncing between stdio
> and iostreams on platforms such as *BSD that don't use libio in their C
> library?

I didn't find anything about that on the libstdc++ web page and noticed
that none of the BSDs is on the build matrix. Hopefully this doesn't mean
we'll run into troubles on these platforms?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: sstream

[Joe Buck]

> On Mon, 21 Feb 2000, Joe Buck wrote:
> > I repeat my request that http://sourceware.cygnus.com/libstdc++/status.html
> > be updated, since according to it, v3 is nowhere near ready (but it
> > shows the state of the world as of the 2.90.6 snapshot).
> 
> That has been done know, as far as I saw, as part of libstdc++-2.90.8.

libstdc++-almost-3 has improved a lot lately.  Unfortunately, I've been
too busy to do libstdc++ tests lately; I encourage people to bang on the
new libstdc++, I hope to have some time after next week.  A lot of the
issues blocking it have gone away (including a legal issue: I see it's now
assigned to the FSF, glad to see that was taken care of).

> > Also, what mechanisms will v3 provide to allow syncing between stdio
> > and iostreams on platforms such as *BSD that don't use libio in their C
> > library?
> 
> I didn't find anything about that on the libstdc++ web page and noticed
> that none of the BSDs is on the build matrix. Hopefully this doesn't mean
> we'll run into troubles on these platforms?

The troubles, if any, will be minor and workaroundable if this isn't done
right (programs that mix stdio and iostreams might need fflush/flush calls
that aren't strictly necessary for the standard).

Re: sstream

[Joe Buck]

> >I suggest using FreeBSD, because it's the most widely used one. If you
> >don't want to install it on one of your boxes, I'm confident that we
> >(i.e., David, Loren or myself) can arrange an account for you. :-)

Marc Espie writes:
> I would suggest something ELSE for two technical reasons:
> - FreeBSD is i386/alpha only,
> - FreeBSD is ELF.

Before we ship a release with libstdc++ 3 we will want to have tests
with all the BSD's.  If you can help with OpenBSD testing, that will be great.

Re: sstream

[Marc Espie]

In article < Pine.BSF.4.21.0003251323110.88158-100000@deneb.dbai.tuwien.ac.at > you write:
>On Fri, 24 Mar 2000, Benjamin Kosnik wrote:
>> Solaris doesn't use libio in its C library, and libstdc++-v3 supports
>> Solaris quite well. [...] Does that answer your question?

>Yes, thanks!

>> I'm interested in testing on BSD. Which one, in particular? I don't
>> have access to a BSD box, so that has kind of limited my testing.

>I suggest using FreeBSD, because it's the most widely used one. If you
>don't want to install it on one of your boxes, I'm confident that we
>(i.e., David, Loren or myself) can arrange an account for you. :-)

I would suggest something ELSE for two technical reasons:
- FreeBSD is i386/alpha only,
- FreeBSD is ELF.

You're very likely not to uncover significant problems running tests on
FreeBSD...

Right now, on OpenBSD for instance, you still have to cope with a.out or
coff on a large majority of architectures, AND you can run tests on somewhat
`forgotten' arches, such as m68k...

I haven't had much time to deal with gcc issues lately... but I could do
some tests. I think there is even a nice m68060 box that could be used for
some tests.

Re: sstream

[Gerald Pfeifer]

On Fri, 24 Mar 2000, Benjamin Kosnik wrote:
> Solaris doesn't use libio in its C library, and libstdc++-v3 supports
> Solaris quite well. [...] Does that answer your question?

Yes, thanks!

> I'm interested in testing on BSD. Which one, in particular? I don't
> have access to a BSD box, so that has kind of limited my testing.

I suggest using FreeBSD, because it's the most widely used one. If you
don't want to install it on one of your boxes, I'm confident that we
(i.e., David, Loren or myself) can arrange an account for you. :-)

If you're interested, please drop us a note!

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: sstream

[Benjamin Kosnik]

> > Also, what mechanisms will v3 provide to allow syncing between stdio
> > and iostreams on platforms such as *BSD that don't use libio in their C
> > library?

Solaris doesn't use libio in its C library, and libstdc++-v3 supports
Solaris quite well. On these platforms we build a skeletal libio, and
use it, much like the current libstdc++-v2.

Does that answer your question?

> I didn't find anything about that on the libstdc++ web page and noticed
> that none of the BSDs is on the build matrix. Hopefully this doesn't mean
> we'll run into troubles on these platforms?

I'm interested in testing on BSD. Which one, in particular? I don't
have access to a BSD box, so that has kind of limited my testing.

-benjamin

Re: sstream

[Martin v. Loewis]

> I got so tired of not being able to use stringstreams that I wrote this. It 
> is probably not all according to the standard but it is a lot better than 
> the nothing that we have got currently. I suppose that I had been better of 
> working on libstdc++-v3 but this was faster.
> I will write a copyright assignment and send as well if you wish to use the 
> code.

Thanks for your patch. It seems to me that no harm is done with
including the code, and it may be useful for people that are missing
stringstreams - so I'd be in favour of including it, also into the
2.95 release branch.

Of course, I don't decide such things; I still wanted to express my
opinion :-)

Regards,
Martin

sstream

[Magnus Fromreide]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

I got so tired of not being able to use stringstreams that I wrote this. It 
is probably not all according to the standard but it is a lot better than 
the nothing that we have got currently. I suppose that I had been better of 
working on libstdc++-v3 but this was faster.
I will write a copyright assignment and send as well if you wish to use the 
code.
It is in any case covered by GPL since it is derived from one of the other 
iostream headers but I suspect it is needed anyhow.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

[-- Attachment #2: sstream --]
[-- Type: text/x-c++, Size: 4794 bytes --]

/* This is part of libio/iostream, providing -*- C++ -*- input/output.
Copyright (C) 2000 Free Software Foundation

This file is part of the GNU IO Library.  This library is free
software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the
Free Software Foundation; either version 2, or (at your option)
any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this library; see the file COPYING.  If not, write to the Free
Software Foundation, 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.

As a special exception, if you link this library with files
compiled with a GNU compiler to produce an executable, this does not cause
the resulting executable to be covered by the GNU General Public License.
This exception does not however invalidate any other reasons why
the executable file might be covered by the GNU General Public License. */

/* Written by Magnus Fromreide (magfr@lysator.liu.se). */

#ifndef __SSTREAM
#define __SSTREAM

#include <string>
#include <iostream.h>
#include <streambuf.h>

namespace std
{
  class stringstreambuf : public streambuf
  {
    std::string		buf;
    ios::open_mode	mode;
  protected:
    inline virtual int sync();
    inline virtual int overflow(int = EOF);
    inline virtual int underflow();
  public:
    stringstreambuf(int m=ios::in|ios::out) :
      buf(), mode(static_cast<ios::open_mode>(m))
    { }
	
    stringstreambuf(const std::string &s, int m=ios::in|ios::out) :
      buf(s), mode(static_cast<ios::open_mode>(m))
    { }
	
    _IO_ssize_t pcount() { return buf.size(); }
    std::string str() { sync(); return buf; };
    void str(const std::string& s)
    {
      pbump(pbase() - pptr());
      gbump(egptr() - gptr());
      buf = s;
    }
  };

  class stringstreambase : virtual public ios {
  protected:
    stringstreambuf __my_sb;
  public:
    std::string str() const
    { return dynamic_cast<stringstreambuf*>(_strbuf)->str(); }
    void str(const std::string& s)
    { return dynamic_cast<stringstreambuf*>(_strbuf)->str(s); }
	
    stringstreambuf* rdbuf() { return &__my_sb; }
  protected:
    stringstreambase(int m) :
      __my_sb(m)
    { init (&__my_sb); }
	
    stringstreambase(const std::string& s, int m) :
      __my_sb(s, m)
    { init (&__my_sb); }
  };
    
  class istringstream : public stringstreambase, public istream {
  public:
    istringstream(std::string& s) :
      stringstreambase(s, ios::in)
    { }
    void str(const std::string& s)
    { return dynamic_cast<stringstreambuf*>(_strbuf)->str(s); }	
  };
    
  class ostringstream : public stringstreambase, public ostream {
  public:
    ostringstream(int m=ios::out) :
      stringstreambase(m)
    { }
	
    ostringstream(const std::string& s, int m=ios::out) :
      stringstreambase(s, m)
    { }

    std::string str() const
    { return dynamic_cast<stringstreambuf*>(_strbuf)->str(); }
  };
    
  class stringstream : public stringstreambase, public iostream {
  public:
    stringstream(int m=ios::in|ios::out) :
      stringstreambase(m)
    { }
    stringstream(const std::string &s, int m=ios::in|ios::out) :
      stringstreambase(s, m)
    { }
	
    std::string str() const
    { return dynamic_cast<stringstreambuf*>(_strbuf)->str(); }
    void str(const std::string& s)
    { return dynamic_cast<stringstreambuf*>(_strbuf)->str(s); }
	
    _IO_ssize_t pcount()
    { return dynamic_cast<stringstreambuf*>(_strbuf)->pcount(); }
  };
}

inline int std::stringstreambuf::sync()
{
  if((mode & ios::out) == 0)
    return EOF;
  std::string::size_type oldSize = buf.size();
  std::string::size_type  n = pptr() - pbase();
  if(n)
    {
      buf.append(pbase(), pptr());
      if(buf.size() - oldSize != n)
	return EOF;
    }
  return 0;
}

inline int std::stringstreambuf::overflow(int ch)
{
  if((mode & ios::out) == 0)
    return EOF;
  streamsize n = pptr() - pbase();

  if(n && sync())
    return EOF;
  if(ch != EOF)
    {
      char cbuf[1];
      std::string::size_type oldSize = buf.size();
	
      cbuf[0] = ch;
      buf.append(cbuf, 1);
      if(buf.size() - oldSize != 1)
	return EOF;
    }
  pbump(-n);
  return 0;
}

inline int std::stringstreambuf::underflow()
{
  if((mode & ios::in) == 0)
    return EOF;
  std::string::size_type n = egptr() - eback();
  std::string::size_type s;
    
  if(buf.size() < n)
    s = buf.copy(egptr() - buf.size(), buf.size());
  else
    s = buf.copy(eback(), n);
  gbump(egptr() - gptr() - s);
  return 0;
}

#endif /*!__STRSTREAM_H*/