What features of D are you using now which you thought you'd never goint to use?

monarch_dodra monarchdodra at gmail.com
Sat Jun 22 14:58:40 PDT 2013


On Saturday, 22 June 2013 at 21:28:47 UTC, Joseph Rushton 
Wakeling wrote:
> On 06/22/2013 09:08 PM, monarch_dodra wrote:
>> Personally, I've found ranges to be a very useful and powerful 
>> *high level*
>> abstraction. They lend themselves work very well for adapting 
>> and chaining
>> (which iterators don't). However, they do come with *some* 
>> downsides (IMO):
>> #1: Performance issues: No matter how I use them, it seems 
>> that I can never get
>> the same raw performance I could get with raw iterator 
>> iteration.*
>
> Do you think that's inevitable?  I'd have thought that this 
> ought to be possible
> to improve with better compiler optimizations.

Yeah, most probably. But as is, the:

for ( ; !r.empty ; r.popFront())
     something with front;

Always seems slower to me, even for arrays.

But this is probably indeed a compiler issue, so yeah, not a real 
issue.

>> *: #1 is subject to simple iteration: Once things scale in 
>> terms of adaptors,
>> ranges win because of the "single item empty" mechanic
>
> Could you explain that in a bit more depth, please?

I mean that once you have an iota=>map=>filter=>whatnot...

This scales well with ranges. With iterators though, you increase 
the complexity by 2 (front + back iterator) for every level. This 
ends up making the checks more expensive they they should be, 
when the iteration scheme doesn't actually need an "end" to know 
it has already reached it.

Not sure that's very clear...?

>> #2: Extremelly bad compatibility with simple no 
>> bidir/non-slicing ranges: There
>> is no way to iterate over a specific part of a range, and 
>> making a range out of
>> what was just iterated over. For example "Get the beggining of 
>> this range until
>> the first x": not possible without slicing.
>
> Not sure what you mean here -- doesn't the attached little code 
> example do
> roughly what you're looking for?  (N.B. it has crap template 
> constraints.
> Typing this quickly I couldn't work out how to make sure that 
> the second
> constructor argument matches the type of input.front.)

Not sure what example you are referring to, but a more complete 
thread about it was here:
The rfind challenge
http://forum.dlang.org/thread/kd2qok$16e6$1@digitalmars.com

long story short: we don't have rfind. C++ does.


More information about the Digitalmars-d mailing list