Impressed

Dmitry Olshansky dmitry.olsh at gmail.com
Sat Jul 28 02:07:00 PDT 2012


On 28-Jul-12 13:00, Stuart wrote:
> On Saturday, 28 July 2012 at 08:53:43 UTC, Dmitry Olshansky wrote:
>> On 28-Jul-12 11:49, Stuart wrote:
>>>
>>> But as I understand it, for ranges I'd need to write a whole new class.
>>
>> struct. Yeah, you need it.
>>
>>> Here, I'm writing a SINGLE FUNCTION in standard imperative style.
>>
>> That implicitly constructs Iterator.
>> It's just a sugar. In fact you can do template mixin to generate most
>> of range boilerplate.
>
> I think the basic thrust of my point is: Sugar is good. The compiler
> converting an imperative function into a state-machine class is helpful.
> Having to write it yourself every damn time is a pain in the arse.
>
It would be good to redo opApply so that it does something like this. In 
fact look at opApply it's approach is the other way around - instead of 
generating object it packs function as delegate and passes it to some 
internal iteration mechanism:

for(v; a){
	v++;
}

--->

a.opApply(x => x++);

where a's opApply can do whatever it wants to with this delegate and 
elements.

> I've been reading about ranges at
> [http://ddili.org/ders/d.en/ranges.html], and don't understand
> something. Where it says:
>
>     struct StudentRange {
>      Student[] students;
>
>      this(School school) {
>          this.students = school.students;
>      }
>
>      [...code...]
>
> Surely "students" is copied here? Isn't the whole point NOT to copy the
> array? Perhaps it should say:
>
>     this.students = school.students[];
>
> ?
Okay. You also need to learn how D arrays or rather slices work :)
It copies 2 words: pointer and length. Thus students points to the same 
array in both cases.

To make a full copy use .dup. You really need to checkout Steven's D 
slices article can't recall link offhand.

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list