On Wed, 16 May 2012 13:23:07 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
On 5/16/2012 10:18 AM, Steven Schveighoffer wrote:
On Wed, 16 May 2012 11:59:37 -0400, Walter Bright
<newshou...@digitalmars.com>
wrote:
On 5/16/2012 7:38 AM, Steven Schveighoffer wrote:
On Wed, 16 May 2012 09:50:12 -0400, Walter Bright
<newshou...@digitalmars.com>
wrote:
On 5/15/2012 3:34 PM, Nathan M. Swan wrote:
I do agree for e.g. with binary data some data can't be read with
ranges (when
you need to read small chunks of varying size),
I don't see why that should be true.
How do you tell front and popFront how many bytes to read?
std.byLine() does it.
Have you looked at how std.byLine works? It certainly does not use a
range
interface as a source.
It presents a range interface, though. Not a streaming one.
But that is *the point*! The code deciding how much data to read (i.e.
the entity I referenced above that 'tells front and popFront how many
bytes to read') is *not* using a range interface. In other words, ranges
aren't enough.
Ranges can be built on top of streaming interfaces. But there is *still*
a need for a comprehensive streaming toolkit. And C's streaming toolkit
is not as good as a native D toolkit can be.
In general, you can read n bytes by calling empty, front, and popFront
n times.
I hope you are not serious! This will make D *the worst performing* i/o
language.
You can read arbitrary numbers of bytes by tacking a range on after
byChunk().
No, this doesn't work in most cases. See my other post. You can't get
everything you want out of just byChunk and byLine.
what about byMySpecificPacketProtocol?
-Steve
