How would it be more optimal? As I said, if you pass in
`file.byChunks(some_amount).joiner`, this will still read the
file in large chunks. It's less optimal now because `read` has
to allocate an array on every call (easily avoidable by passing
in a reusable buffer, but still).
Equivalent cod
On Tuesday, 5 May 2015 at 01:28:03 UTC, Freddy wrote:
Wait, Bad example,
void func(R)(R range){//expects range of ubyte
ubyte[] data=range.read(VERY_BIG_NUMBER);
ubyte[] other_data=range.read(OTHER_VERY_BIG_NUMBER);
}
which would be more optimal for a file but still works for
o
On Monday, 4 May 2015 at 00:07:27 UTC, Freddy wrote:
Would it be a bad idea to add a read primitive to ranges for
streaming?
struct ReadRange(T){
size_t read(T[] buffer);
//and | or
T[] read(size_t request);
/+ empty,front,popFront,etc +/
}
Also if so, What about add
On Tuesday, 5 May 2015 at 00:50:44 UTC, Freddy wrote:
void func(R)(R range){//expects range of strings
string[] elms=range.read(5);
string[] elms2=range.read(9);
/++..++/
}
void caller(){
auto file=...;//unbuffered file
file.map!(a=>a.to!string).func();
}
Wait, Ba
On Monday, 4 May 2015 at 23:20:57 UTC, Alex Parrill wrote:
On Monday, 4 May 2015 at 19:23:08 UTC, Freddy wrote:
On Monday, 4 May 2015 at 15:16:25 UTC, Alex Parrill wrote:
The ploblem is that all the functions in
std.range,std.algorithm and many other wrappers would ignore
byChucks and produce
On Monday, 4 May 2015 at 19:23:08 UTC, Freddy wrote:
On Monday, 4 May 2015 at 15:16:25 UTC, Alex Parrill wrote:
The ploblem is that all the functions in
std.range,std.algorithm and many other wrappers would ignore
byChucks and produce much slower code.
How so? `file.byChunks(4096).joiner` is
On Monday, 4 May 2015 at 15:16:25 UTC, Alex Parrill wrote:
IT seems redundant to me. It's semantically no different than
iterating through the range normally with front/popFront. For
objects where reading large amounts of data is more efficient
than reading one-at-a-time, you can implement a
On Monday, 4 May 2015 at 00:07:27 UTC, Freddy wrote:
Would it be a bad idea to add a read primitive to ranges for
streaming?
struct ReadRange(T){
size_t read(T[] buffer);
//and | or
T[] read(size_t request);
/+ empty,front,popFront,etc +/
}
IT seems redundant to me.
On Mon, 04 May 2015 00:07:25 +, Freddy wrote:
> Would it be a bad idea to add a read primitive to ranges for streaming?
>
> struct ReadRange(T){
> size_t read(T[] buffer); //and | or T[] read(size_t request);
>
> /+ empty,front,popFront,etc +/
> }
>
if you want to add suc
