Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #5867 > unrolled thread

Life is a stream?

Back to article view | Back to comp.lang.c++

Contents

  Life is a stream? "MikeP" <mp011011@some.org> - 2011-05-30 22:25 -0500
    Re: Life is a stream? BGB <cr88192@hotmail.com> - 2011-05-30 23:55 -0700
    Re: Life is a stream? Michael Doubez <michael.doubez@free.fr> - 2011-05-31 02:50 -0700
      Re: Life is a stream? "MikeP" <mp011011@some.org> - 2011-06-01 03:19 -0500
      Re: Life is a stream? "MikeP" <mp011011@some.org> - 2011-06-06 12:51 -0500
    Re: Life is a stream? Adam Skutt <askutt@gmail.com> - 2011-05-31 09:29 -0700
      Re: Life is a stream? "MikeP" <mp011011@some.org> - 2011-06-06 12:54 -0500
    Re: Life is a stream? Andy Champ <no.way@nospam.invalid> - 2011-05-31 20:43 +0100
      Re: Life is a stream? "MikeP" <mp011011@some.org> - 2011-06-01 03:22 -0500
        Re: Life is a stream? Andy Champ <no.way@nospam.invalid> - 2011-06-01 21:53 +0100
          Re: Life is a stream? "MikeP" <mp011011@some.org> - 2011-06-06 12:56 -0500

#5867 — Life is a stream?

Programmers are enamoured with streams of bytes. Is that abstraction 
(i.e., generality) too rigidly modeled? I say, all IO (I/O?) is not 
alike, so why model it as if it is. What say you (y'all)?

Keywords and key phrases (why is "keyword" a compound word and "key 
phrase" two words?): stream of bytes, record IO, formatted IO, ASCII 
unit/record/group separator, compromise, designed for all cases but good 
for none (nothing),... other. 

[toc] | [next] | [standalone]

#5888

On 5/30/2011 8:25 PM, MikeP wrote:
> Programmers are enamoured with streams of bytes. Is that abstraction
> (i.e., generality) too rigidly modeled? I say, all IO (I/O?) is not
> alike, so why model it as if it is. What say you (y'all)?
>
> Keywords and key phrases (why is "keyword" a compound word and "key
> phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
> unit/record/group separator, compromise, designed for all cases but good
> for none (nothing),... other.
>

collections of bytes (globs/streams/arrays/...) are generally the most 
generic bottom-level representation for data.

other data representations:
text, XML, arrays, structures, ... although often much more closely 
related to the data in question, are nowhere near as general-purpose, 
and so are ill suited as a "fundamental representation".

this then is why file-formats are often composed on a number of 
"layers", each with various levels of abstraction, various magic 
numbers, ...


also, it makes sense, as the world would be far more complex (and not 
nearly so functional) if all of the file-systems, network HW, memory 
storage, ... each had to deal with a wide range of possible data 
representations. since they only see bytes, their job is generally easier.

probably about the only other likely "fundamental" model would be 
abstract reference-based high-level data types... however... this model 
itself has a notably different problem: it doesn't really map well to 
traditional static-typed languages (such as C, C++, Java, ...). even 
then, it doesn't matter much, since this other model (more commonly used 
in languages like Lisp/Scheme/Erlang/...) still can be mapped fairly 
effectively to plain old bytes.

so, seemingly, there is nothing really that doesn't map acceptably well 
to bytes.

[toc] | [prev] | [next] | [standalone]

#5895

On 31 mai, 05:25, "MikeP" <mp011...@some.org> wrote:
> Programmers are enamoured with streams of bytes.

Yep. that's Ol' man river.

> Is that abstraction
> (i.e., generality) too rigidly modeled? I say, all IO (I/O?) is not
> alike, so why model it as if it is. What say you (y'all)?

Are you talking about a model or the support for a model ?

However you interpret your data, it has eventually a beginning and a
end (out-of-bound data are stream in themselves) on a support which is
a represented as an ordered sequence of ones and zeros. The byte being
the smallest addressable unit.

> Keywords and key phrases (why is "keyword" a compound word and "key
> phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
> unit/record/group separator, compromise, designed for all cases but good
> for none (nothing),... other.

Those are models with context; you are not at the same level.

Could you elaborate ?

--
Michael

[toc] | [prev] | [next] | [standalone]

#5957

Michael Doubez wrote:
> On 31 mai, 05:25, "MikeP" <mp011...@some.org> wrote:
>> Programmers are enamoured with streams of bytes.
>
> Yep. that's Ol' man river.
>
>> Is that abstraction
>> (i.e., generality) too rigidly modeled? I say, all IO (I/O?) is not
>> alike, so why model it as if it is. What say you (y'all)?
>
> Are you talking about a model or the support for a model ?
>

Probably, but it is a secret.

> However you interpret your data, it has eventually a beginning and a
> end (out-of-bound data are stream in themselves) on a support which is
> a represented as an ordered sequence of ones and zeros. The byte being
> the smallest addressable unit.

Wouldn't I love to find you in "a court of law".

>
>> Keywords and key phrases (why is "keyword" a compound word and "key
>> phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
>> unit/record/group separator, compromise, designed for all cases but
>> good for none (nothing),... other.
>
> Those are models with context; you are not at the same level.
>
> Could you elaborate ?

I could and have, but I won't. 

[toc] | [prev] | [next] | [standalone]

#6304

Michael Doubez wrote:
> On 31 mai, 05:25, "MikeP" <mp011...@some.org> wrote:
>> Programmers are enamoured with streams of bytes.
>
> Yep. that's Ol' man river.
>
>> Is that abstraction
>> (i.e., generality) too rigidly modeled? I say, all IO (I/O?) is not
>> alike, so why model it as if it is. What say you (y'all)?
>
> Are you talking about a model or the support for a model ?

Note that this is a C++ NG. I was alluding to C++ recognizing only 
streams of bytes.

>
> However you interpret your data, it has eventually a beginning and a
> end (out-of-bound data are stream in themselves) on a support which is
> a represented as an ordered sequence of ones and zeros. The byte being
> the smallest addressable unit.
>
>> Keywords and key phrases (why is "keyword" a compound word and "key
>> phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
>> unit/record/group separator, compromise, designed for all cases but
>> good for none (nothing),... other.
>
> Those are models with context; you are not at the same level.
>
> Could you elaborate ?

No, that part was just food for thought. 

[toc] | [prev] | [next] | [standalone]

#5914

On May 30, 11:25 pm, "MikeP" <mp011...@some.org> wrote:
> Programmers are enamoured with streams of bytes. Is that abstraction
> (i.e., generality) too rigidly modeled?

Given that the only thing you can do with all streams in POSIX is
close them, I would say no.  Programmers are enamoured with streams of
bytes as a reflection of the nature of the underlying hardware.  When
streams don't work especially well, we don't use them.

> I say, all IO (I/O?) is not
> alike, so why model it as if it is. What say you (y'all)?

We never have and never will.  I don't think you know what you're
talking about, all major operating systems that I can think of
support:
* Memory-mapped I/O (which is the dominant form of hardware I/O in
most modern computers), including shared memory support, like UNIX
mmap.
* Block-based I/O for block-oriented devices, though sometimes only at
the kernel level.
* Stream-based I/O for stream-oriented devices, like UNIX open/read/
write.
* Ancillary I/O for configuration and management of most hardware,
like UNIX ioctl.
* Special purpose I/O for directory and other special filesystem
structures.
* Some form of "reliable" message IPC, such as SysV message queues.

I could keep going, but I think I've made my point.

>
> Keywords and key phrases (why is "keyword" a compound word and "key
> phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
> unit/record/group separator, compromise, designed for all cases but good
> for none (nothing),... other.

It would help if you'd write actual complete sentences.  If you don't
have the I/O interface you want, you usually can provide the I/O
interface you want by simply layering on top of the one you have.
This is why we don't have to write block-oriented code to access files
in a filesystem, which is a good thing.

Adam

[toc] | [prev] | [next] | [standalone]

#6305

Adam Skutt wrote:
> On May 30, 11:25 pm, "MikeP" <mp011...@some.org> wrote:
>> Programmers are enamoured with streams of bytes. Is that abstraction
>> (i.e., generality) too rigidly modeled?
>
> Given that the only thing you can do with all streams in POSIX is
> close them, I would say no.  Programmers are enamoured with streams of
> bytes as a reflection of the nature of the underlying hardware.  When
> streams don't work especially well, we don't use them.
>
>> I say, all IO (I/O?) is not
>> alike, so why model it as if it is. What say you (y'all)?
>
> We never have and never will.  I don't think you know what you're
> talking about, all major operating systems that I can think of
> support:
> * Memory-mapped I/O (which is the dominant form of hardware I/O in
> most modern computers), including shared memory support, like UNIX
> mmap.
> * Block-based I/O for block-oriented devices, though sometimes only at
> the kernel level.
> * Stream-based I/O for stream-oriented devices, like UNIX open/read/
> write.
> * Ancillary I/O for configuration and management of most hardware,
> like UNIX ioctl.
> * Special purpose I/O for directory and other special filesystem
> structures.
> * Some form of "reliable" message IPC, such as SysV message queues.
>
> I could keep going, but I think I've made my point.

Actually, you've made mine! (I knew someone would). :)

>
>>
>> Keywords and key phrases (why is "keyword" a compound word and "key
>> phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
>> unit/record/group separator, compromise, designed for all cases but
>> good for none (nothing),... other.
>
> It would help if you'd write actual complete sentences.

The colon in the above is very key. It is not meant to be sentencial.

> If you don't
> have the I/O interface you want, you usually can provide the I/O
> interface you want by simply layering on top of the one you have.
> This is why we don't have to write block-oriented code to access files
> in a filesystem, which is a good thing.

[toc] | [prev] | [next] | [standalone]

#5919

On 31/05/2011 04:25, MikeP wrote:
> Programmers are enamoured with streams of bytes. Is that abstraction
> (i.e., generality) too rigidly modeled? I say, all IO (I/O?) is not
> alike, so why model it as if it is. What say you (y'all)?
>
> Keywords and key phrases (why is "keyword" a compound word and "key
> phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
> unit/record/group separator, compromise, designed for all cases but good
> for none (nothing),... other.
>
>

Having read a few comments and rummaged in the old memory...

Some mainframe systems have record based file systems, where the OS is 
responsible for mapping the records onto the disc sectors.  There's no 
stream of bytes involved - a read will give you a record (which 
admittedly is usually made of bytes!) direct from a sector, and there is 
no byte-wide stream involved at all.  This of course has advantages if 
your data is wider than bytes, and the system bus is too - there's never 
a need to perform the byte alignment.

Andy

[toc] | [prev] | [next] | [standalone]

#5958

Andy Champ wrote:
> On 31/05/2011 04:25, MikeP wrote:
>> Programmers are enamoured with streams of bytes. Is that abstraction
>> (i.e., generality) too rigidly modeled? I say, all IO (I/O?) is not
>> alike, so why model it as if it is. What say you (y'all)?
>>
>> Keywords and key phrases (why is "keyword" a compound word and "key
>> phrase" two words?): stream of bytes, record IO, formatted IO, ASCII
>> unit/record/group separator, compromise, designed for all cases but
>> good for none (nothing),... other.
>>
>>
>
> Having read a few comments and rummaged in the old memory...
>
> Some mainframe systems have record based file systems, where the OS is
> responsible for mapping the records onto the disc sectors.  There's no
> stream of bytes involved - a read will give you a record (which
> admittedly is usually made of bytes!) direct from a sector, and there
> is no byte-wide stream involved at all.  This of course has
> advantages if your data is wider than bytes, and the system bus is
> too - there's never a need to perform the byte alignment.
>

It is just data though, Hmm? 

[toc] | [prev] | [next] | [standalone]

#6012

On 01/06/2011 09:22, MikeP wrote:
> Andy Champ wrote:
>>
>> Having read a few comments and rummaged in the old memory...
>>
>> Some mainframe systems have record based file systems, where the OS is
>> responsible for mapping the records onto the disc sectors.  There's no
>> stream of bytes involved - a read will give you a record (which
>> admittedly is usually made of bytes!) direct from a sector, and there
>> is no byte-wide stream involved at all.  This of course has
>> advantages if your data is wider than bytes, and the system bus is
>> too - there's never a need to perform the byte alignment.
>>
>
> It is just data though, Hmm?
>
>

Well, depends what you mean.  These are things like ISAM files...

Andy

[toc] | [prev] | [next] | [standalone]

#6306

Andy Champ wrote:
> On 01/06/2011 09:22, MikeP wrote:
>> Andy Champ wrote:
>>>
>>> Having read a few comments and rummaged in the old memory...
>>>
>>> Some mainframe systems have record based file systems, where the OS
>>> is responsible for mapping the records onto the disc sectors. There's 
>>> no stream of bytes involved - a read will give you a record
>>> (which admittedly is usually made of bytes!) direct from a sector,
>>> and there is no byte-wide stream involved at all.  This of course
>>> has advantages if your data is wider than bytes, and the system bus
>>> is too - there's never a need to perform the byte alignment.
>>>
>>
>> It is just data though, Hmm?
>>
>>
>
> Well, depends what you mean.

I'm not sure where I was going with that either. 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web