In article <m3wwvskezh.fsf@gabi-soft.fr>, kanze@gabi-soft.fr (J. Kanze) wrote:

>> Properties of random-access streams:
>>
>> Properties of sequential streams:

Maybe that should be called "storage streams" and "communications
streams" instead.

>This sounds more or less like the status quo, except for timeouts and
>the special states (connected, etc.), which are irrelevant for what is
>by far the most frequent type of sequential stream in my environment (a
>Unix pipe).

But timeouts and connected state IS relevant for asynchronous serial
ports and network sockets. I find it very convenient to use a socket
stream hen writing TCP/IP applications, but then I do need to handle
timeout and connected state.

In some cases it would be useful to write a function that takes a
stream as parameter, and that stream can be either a socket or a serial
port (but not a disk file). To do that now I have to declare the
parameter as iostream and I can't use the timeout and connection
handling methods in my sostream and astream classes. With my proposal I
could declare the parameter as seqstream and be able to use timeout and
connection handling.

>Having separate classes for the two types is not a valid solution for
>Unix (and probably many other environments), for example.  Whether a
>filebuf supports random access depends on the file it is opened on.
>While C++ obviously shouldn't be strictly Unix, I doubt you'll find much
>support for defining the language such that it cannot be implemented
>under Unix.

I don't think that my proposal would be impossible to implement
sensible on UNIX. You can still use normal filebuf on file handles for
communications devices, you just won't get the timeout and connection
handling (no difference from today).
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

d96-mst@nada.kth.se (Mikael Steldal) writes:

> Will the standard include a useful, well-defined and portable interface
> for constructing your own stream types (a class that derives from
> streambuf (or whatever it will be named) and some more stuff)? In my
> old Borland C++ compiler the interface was rather clumsy and
> non-documented. I did manage to write working I/O-stream interfaces for
> network sockets and asynchronous serial ports, but it was more
> difficult than nessesary IMHO.

All of the drafts I've seen have this.

> It seemed to me that the interface was designed for random-access
> streams (such as the predefined fstream, stringstream and strstream),
> and not very suitable for sequential streams (such as network sockets
> and serial ports).

I've not noticed this with the USL iostream (and compatible versions
like Sun), nor with g++.  From experience, I'd say that at least 90% of
my private streams do *NOT* support random-access.  In fact, you have to
do extra work to support it (override the default seekpos).

> Maybe it would be a good idea if the standard defined two classes that
> derives from streambuf (or whatever it will be named), one for
> random-access streams and one for sequential streams. The predefined
> would then derive from sequential_streambuf, and user defined would
> derive from one of them.
>
> Properties of random-access streams:
> * All data that can be read is accessible from start, except if you
>   write data to the same stream and read your just-written data.
> * seekg/tellg/seekp/tellp must be supported.
> * There is a distinct EOF when reading sequentially.
> * There are no such things as timeouts or connected state.
> * It's common to only read or only write, but read/write should be
>   supported.
>
> Properties of sequential streams:
> * All data that can be read is NOT accessible from start.
> * seekg/tellg/seekp/tellp can not be supported.
> * There is not a distinct EOF when reading, but there can be timeouts
>   which must be handled in some decent way.
> * There stream can have a connected and a disconnected state, there must
>   be ways to check current state, and to disconnect.
> * You want read/write, only read or only write need not to be supported.

This sounds more or less like the status quo, except for timeouts and
the special states (connected, etc.), which are irrelevant for what is
by far the most frequent type of sequential stream in my environment (a
Unix pipe).

Having separate classes for the two types is not a valid solution for
Unix (and probably many other environments), for example.  Whether a
filebuf supports random access depends on the file it is opened on.
While C++ obviously shouldn't be strictly Unix, I doubt you'll find much
support for defining the language such that it cannot be implemented
under Unix.

--
James Kanze          +33 3 88 14 49 00           email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Will the standard include a useful, well-defined and portable interface
for constructing your own stream types (a class that derives from
streambuf (or whatever it will be named) and some more stuff)? In my
old Borland C++ compiler the interface was rather clumsy and
non-documented. I did manage to write working I/O-stream interfaces for
network sockets and asynchronous serial ports, but it was more
difficult than nessesary IMHO.

It seemed to me that the interface was designed for random-access
streams (such as the predefined fstream, stringstream and strstream),
and not very suitable for sequential streams (such as network sockets
and serial ports).

Maybe it would be a good idea if the standard defined two classes that
derives from streambuf (or whatever it will be named), one for
random-access streams and one for sequential streams. The predefined
would then derive from sequential_streambuf, and user defined would
derive from one of them.

Properties of random-access streams:
* All data that can be read is accessible from start, except if you
  write data to the same stream and read your just-written data.
* seekg/tellg/seekp/tellp must be supported.
* There is a distinct EOF when reading sequentially.
* There are no such things as timeouts or connected state.
* It's common to only read or only write, but read/write should be
  supported.

Properties of sequential streams:
* All data that can be read is NOT accessible from start.
* seekg/tellg/seekp/tellp can not be supported.
* There is not a distinct EOF when reading, but there can be timeouts
  which must be handled in some decent way.
* There stream can have a connected and a disconnected state, there must
  be ways to check current state, and to disconnect.
* You want read/write, only read or only write need not to be supported.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]