On Friday, 3 October 2014 at 15:22:06 UTC, Nordlöw wrote:
As a follow up to
http://forum.dlang.org/thread/dndicafxfubzmndeh...@forum.dlang.org
I've begun implementing a new range, I currently call,
SlidingSplitter at
https://github.com/nordlow/justd/blob/master/range_ex.d#L12
I would now
On Friday, 3 October 2014 at 15:22:06 UTC, Nordlöw wrote:
Destroy, please!
As a quick comment, your definition of moveFront is not what
phobos understands with moveFront:
https://github.com/D-Programming-Language/phobos/blob/7914fa31cb3b53f4e50421399f2b99d2012e8031/std/range.d#L8267
On Friday, 3 October 2014 at 16:32:24 UTC, monarch_dodra wrote:
If anything, I'd have expected you to provide something returns
the popped element. What you do pops an element, and then
returns the *next* one. What good is that?
My mistake. It's fixed now.
Also, what you want to check is
On Friday, 3 October 2014 at 17:06:41 UTC, Nordlöw wrote:
On Friday, 3 October 2014 at 16:32:24 UTC, monarch_dodra wrote:
If anything, I'd have expected you to provide something
returns the popped element. What you do pops an element, and
then returns the *next* one. What good is that?
My
On Friday, 3 October 2014 at 17:46:18 UTC, monarch_dodra wrote:
My mistake. It's fixed now.
Well, yes and no. You are still providing a moveFront that does
not conform to what the range interface expects. EG:
auto app = appender();
auto myRange = slidingSplitter([1, 2, 3]);
for ( ;
On Friday, 3 October 2014 at 19:12:54 UTC, Nordlöw wrote:
On Friday, 3 October 2014 at 17:46:18 UTC, monarch_dodra wrote:
If your implementation use two ranges that you slice on the
fly, then you can trivially support strings, thanks to
popFront.
Very clever. That's what I wanted.
I threw
On Friday, 3 October 2014 at 19:31:30 UTC, monarch_dodra wrote:
The idea is to try to keep as much code in common as possible.
You can keep your version, provided you write this for popFront:
void popFront()
{
if (_index _data.length)
{
static if
On Friday, 3 October 2014 at 19:46:10 UTC, Nordlöw wrote:
Is prefix ++ preferred in D because of some specific reason? I
recall it, for some containers/iterators, gives smaller/faster
codegen in C++?
Be it C, C++ or D, pre increment is maybe faster, and is never
slower.
So as a rule of
On Friday, 3 October 2014 at 19:57:31 UTC, monarch_dodra wrote:
Be it C, C++ or D, pre increment is maybe faster, and is never
slower.
So as a rule of thumb, unless you should *specifically* require
post increment, pre-increment is to be prefered, though in 95%
of the cases, it results in
On Friday, 3 October 2014 at 17:46:18 UTC, monarch_dodra wrote:
I threw this together. I left out checks for infinity in favor
of brevity:
Could you please take a look again at
https://github.com/nordlow/justd/blob/master/range_ex.d#L15
I added all the stuff we talked about.
Note that I had
On Friday, 3 October 2014 at 17:46:18 UTC, monarch_dodra wrote:
writefln(%(%s\n%), slidingSplitter(Nordlöw));
That's a really cool syntax, btw. I got to remember that.
On Friday, 3 October 2014 at 20:15:33 UTC, Nordlöw wrote:
Could you please take a look again at
I made another update at
https://github.com/nordlow/justd/blob/master/range_ex.d#L15
I had forgotten to move front and popFront out of static if
hasSlicing!R
Now
auto name =
Is prefix ++ preferred in D because of some specific reason? I
recall it, for some containers/iterators, gives smaller/faster
codegen in C++?
I assume the reason is the same as in C++. As users can provide
their own implementations of pre and postfix incrementing, the
compiler can't
On Friday, 3 October 2014 at 20:28:24 UTC, Nordlöw wrote:
On Friday, 3 October 2014 at 20:15:33 UTC, Nordlöw wrote:
Could you please take a look again at
I made another update at
https://github.com/nordlow/justd/blob/master/range_ex.d#L15
I had forgotten to move front and popFront out of
On Friday, 3 October 2014 at 20:15:33 UTC, Nordlöw wrote:
Note that I had to tweak empty() a bit. I don't know if I got
right. Could you check?
Sounds about right, but I didn't really look.
Further I can't get string support to work:
writefln(%(%s\n%), slidingSplitter(Nordlöw));
errors
On Friday, 3 October 2014 at 21:17:54 UTC, monarch_dodra wrote:
Sounds about right, but I didn't really look.
std.utf.stride solved all but one thing...namely that
https://github.com/nordlow/justd/blob/master/range_ex.d#L131
prints all but last
Tuple!(string, string)(, Nordlöw)
On Friday, 3 October 2014 at 21:34:33 UTC, Nordlöw wrote:
Why?
I cracked it :)
See: https://github.com/nordlow/justd/blob/master/range_ex.d#L36
Thanks for all your help!
Now I know a lot more about ranges.
Do you think anybody is interested in including this in Phobos?
17 matches
Mail list logo