tony@online.tmx.com.au (Tony Cook) writes:

>Timothy Murphy (tmurphy@panix.com) wrote:
>
>:    no, no, no.  What I mean is that there should be separate types
>: for streams that support seeking and streams that don't.  In general,
>: cin and cout do not support seeking; I think that their classes should
>: not have a seek method.  Files, on the other hand, do support seeking,
>: so a file object should have a seek method.
>
>The problem is that under some circumstances cin and cout can
>support seeking, for example redirected I/O with files under MS-DOS.

That's easily dealt with, using RTTI.

 extern istream &cin;

 seekable_istream* seekable_cin = dynamic_cast<seekable_istream*>(&cin);
 if (seekable_cin) {
  seekable_cin->seek(...);
 } else {
  cerr << "Sorry, can't seek on std input" << endl;
 }

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
: tony@online.tmx.com.au (Tony Cook) writes:

: >Timothy Murphy (tmurphy@panix.com) wrote:
: >
: >:    no, no, no.  What I mean is that there should be separate types
: >: for streams that support seeking and streams that don't.  In general,
: >: cin and cout do not support seeking; I think that their classes should
: >: not have a seek method.  Files, on the other hand, do support seeking,
: >: so a file object should have a seek method.
: >
: >The problem is that under some circumstances cin and cout can
: >support seeking, for example redirected I/O with files under MS-DOS.

: That's easily dealt with, using RTTI.

:  extern istream &cin;

:  seekable_istream* seekable_cin = dynamic_cast<seekable_istream*>(&cin);
:  if (seekable_cin) {
:   seekable_cin->seek(...);
:  } else {
:   cerr << "Sorry, can't seek on std input" << endl;
:  }

Isn't this type of code normally considered bad practice (checking
the type of an object to decide what to do)?

But I suppose it's better than the current alternative (of calling
an operation that makes no real sense in the circumstances).

--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com

Timothy Murphy (tmurphy@panix.com) wrote:

:    no, no, no.  What I mean is that there should be separate types
: for streams that support seeking and streams that don't.  In general,
: cin and cout do not support seeking; I think that their classes should
: not have a seek method.  Files, on the other hand, do support seeking,
: so a file object should have a seek method.

The problem is that under some circumstances cin and cout can
support seeking, for example redirected I/O with files under MS-DOS.

--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com

In article <3jfiha$m1j@panix3.panix.com>, tmurphy@panix.com (Timothy Murphy) writes:
> Seekable vs. non-Seekable iostreams.
>
>    It seems that there should be a compile-time distinction between
> iostreams that support seeking (such as files) and those that do
> not (such as terminals).
>
> -- Timothy S. Murphy: A serious user and admirer of C++.
>    tmurphy@panix.com

Does that mean that the language or its run-time system must ensure that
the actual representation of the file in the run-time environment (perhaps
across a network) matches the particular form of the declaration just to
ensure that an operation that may never be used (Halting Problem, remember?)
is never available?
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
 (Training and consulting in C, C++, UNIX, etc.)

In article <3jkrob$k9h@panix3.panix.com>,
Timothy Murphy <tmurphy@panix.com> wrote:
>
>   no, no, no.  What I mean is that there should be separate types
>for streams that support seeking and streams that don't.  In general,
>cin and cout do not support seeking; I think that their classes should
>not have a seek method.  Files, on the other hand, do support seeking,
>so a file object should have a seek method.

 Sigh. You are asking for a proper static design long
after the "unified" Unix file system -- which uses
dynamic controls -- has been put in place.

 It is way too late to provide a proper set of
abstract services for the range of devices available
on modern machines.

 Where is the standardised "gotoxy()" without which
no reasonable commercial program can possibly be written?
Let alone graphics and mice.

 The best thing you can do with iostreams is use
them for batch processing and debugging and ignore them
completely otherwise.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

mat@mole-end.matawan.nj.us wrote:
: In article <3jfiha$m1j@panix3.panix.com>, tmurphy@panix.com (Timothy Murphy) writes:
: > Seekable vs. non-Seekable iostreams.
: >
: >    It seems that there should be a compile-time distinction between
: > iostreams that support seeking (such as files) and those that do
: > not (such as terminals).
: >
: > -- Timothy S. Murphy: A serious user and admirer of C++.
: >    tmurphy@panix.com

: Does that mean that the language or its run-time system must ensure that
: the actual representation of the file in the run-time environment (perhaps
: across a network) matches the particular form of the declaration just to
: ensure that an operation that may never be used (Halting Problem, remember?)
: is never available?
: --
:  (This man's opinions are his own.)
:  From mole-end    Mark Terribile
:  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
:  (Training and consulting in C, C++, UNIX, etc.)


   no, no, no.  What I mean is that there should be separate types
for streams that support seeking and streams that don't.  In general,
cin and cout do not support seeking; I think that their classes should
not have a seek method.  Files, on the other hand, do support seeking,
so a file object should have a seek method.

---tim

Seekable vs. non-Seekable iostreams.

   It seems that there should be a compile-time distinction between
iostreams that support seeking (such as files) and those that do
not (such as terminals).

-- Timothy S. Murphy: A serious user and admirer of C++.
   tmurphy@panix.com