On Thursday, 29 May 2014 at 10:28:45 UTC, Chris wrote:
> I dug into Chapter 3 about ranges. It clarifies a lot of things about ranges.

Yeah, a lot of the stuff there comes from my own process when writing my first range consuming function (which is still in a pretty ugly form in my sha.d on github, I have never really fixed it).

I had to ask on the newsgroup: what does it really mean to accept a generic input range? Does it mean to attempt data transformations to receive anything? Or is it semi-strict? (the answer is to take any input range but be strict on the element type - don't try to transform it yourself as that introduces bugs and hidden performance issues for the algorithm's user)

I didn't quite understand the answer until some time later and now I think it is fairly simple, but since I was so wrong about it for such a long while I figured other people probably had the same problems and tried to cover them in the book.

One of the sections there talks about emulating random access on a structure that doesn't really support it (a linked list) and focuses on the hidden performance. That's the range-writer side of the same range-consumer rule: don't try to get fancy and support something the underlying data doesn't natively do because then you'll introduce bugs and slowdowns that might be hard to find.

On Thursday, 29 May 2014 at 10:28:45 UTC, Chris wrote:
> On Wednesday, 28 May 2014 at 18:14:28 UTC, Walter Bright wrote:
>> http://www.packtpub.com/discover-advantages-of-programming-in-d-cookbook/book
>>
>> http://www.amazon.com/D-Cookbook-Adam-D-Ruppe/dp/1783287217
>>
>> http://www.reddit.com/r/programming/comments/26pn00/d_cookbook_officially_published_consists_of_d/
>>
>> After watching Adam's most excellent presentation at Dconf, I'm sure the book will be great! My copy gets here on Friday.
>
> I dug into Chapter 3 about ranges. It clarifies a lot of things about ranges. These little questions I kept asking my self, like "is this good practice or a hack?" etc. Thanks to one of his examples (+explanation) I've already been able to improve my production code. Thanks a million Adam!

+1, just purchased my copy :)

On Wednesday, 28 May 2014 at 18:14:28 UTC, Walter Bright wrote:
> http://www.packtpub.com/discover-advantages-of-programming-in-d-cookbook/book
>
> http://www.amazon.com/D-Cookbook-Adam-D-Ruppe/dp/1783287217
>
> http://www.reddit.com/r/programming/comments/26pn00/d_cookbook_officially_published_consists_of_d/
>
> After watching Adam's most excellent presentation at Dconf, I'm sure the book will be great! My copy gets here on Friday.

A question(s) regarding Chapter 5: Making a reference-counted object:

(btw do we need separate thread for content-related questions?)

- point 5 (of How to do it...) says: "... and free the object if necessary", but then in code:

~this() {
  if(data is null) return;
  data.refcount--;
  writeln("Released. Refcount = ", data.refcount);
  if(data.refcount == 0)
  writeln("Destroyed.");
}

is actual freeing missing? Or am I missing something?

Later in same chapter: "... or being collected by the garbage collector—its destructor is called, if present."

Is that really true? My understanding (and unfortunate test) is that it is never guaranteed that d-tor of GD allocated object is ever called. If that is the case then: is that true that dynamic array of RefCountedObject does not guarantee any of d-tors called? That would also mean that if any of objects in object graph is GC-allocated then NONE of its child nodes have any guarantees about destruction?

On Thursday, 29 May 2014 at 12:45:20 UTC, Adam D. Ruppe wrote:
> On Thursday, 29 May 2014 at 10:28:45 UTC, Chris wrote:
>> I dug into Chapter 3 about ranges. It clarifies a lot of things about ranges.
>
> Yeah, a lot of the stuff there comes from my own process when writing my first range consuming function (which is still in a pretty ugly form in my sha.d on github, I have never really fixed it).

I have different types of range implementations throughout my code now, which basically depicts the learning process while I was trying to grasp the concept. I think the D website could do with something like your Chapter 3. It's not really rocket science, but when you have no guidelines, best practices whatsoever, you have to experiment yourself which always leaves a weird after taste, i.e. questions like "is this really the right way? am I doing something wrong?".

> I had to ask on the newsgroup: what does it really mean to accept a generic input range? Does it mean to attempt data transformations to receive anything? Or is it semi-strict? (the answer is to take any input range but be strict on the element type - don't try to transform it yourself as that introduces bugs and hidden performance issues for the algorithm's user)

Yes, I always adhered to this rule.

> I didn't quite understand the answer until some time later and now I think it is fairly simple, but since I was so wrong about it for such a long while I figured other people probably had the same problems and tried to cover them in the book.

True, true. Your book was direly needed, and if it's just to clarify things. Sometimes I would feel like a fool to ask questions about ranges, thinking everybody understands them except for me. Once you get the hang of it, it's pretty straight forward.

> One of the sections there talks about emulating random access on a structure that doesn't really support it (a linked list) and focuses on the hidden performance. That's the range-writer side of the same range-consumer rule: don't try to get fancy and support something the underlying data doesn't natively do because then you'll introduce bugs and slowdowns that might be hard to find.

On Thu, 29 May 2014 06:20:51 -0400, Atila Neves <atila.neves@gmail.com> wrote:

> For some reason I didn't even know it was available as an ebook
> until I read this. At which point I promptly bought it. Dead
> trees and their lack of Ctrl-F... :)

To be fair, the physical book comes with access to the ebook.

But the reason for me to buy the ebook was simpler -- it's half the price :)

Still lack time to read it, but I like the AK47 tip (don't have one, but I'm sure it works for most rifles)!

-Steve

On Thursday, 29 May 2014 at 13:12:33 UTC, Chris wrote:
> a weird after taste, i.e. questions like "is this really the right way? am I doing something wrong?".

I ask myself that a lot too, even the book isn't really meant to be authoritative, more like "this works pretty well for me hopefully it works for you too".

On Thursday, 29 May 2014 at 13:01:50 UTC, Szymon Gatner wrote:
> Later in same chapter: "... or being collected by the garbage collector—its destructor is called, if present."
>
> Is that really true?

hmm, you seem to be right, but this might be a bug. I'm pretty sure the struct dtors were called on arrays not long ago but it isn't really reliable with the GC (My weasel word there is "provably", sometimes the GC can't prove there are no references; false pointers etc) but still blargh this current reality seems weird.

On Thursday, 29 May 2014 at 13:57:41 UTC, Adam D. Ruppe wrote:
> On Thursday, 29 May 2014 at 13:01:50 UTC, Szymon Gatner wrote:
>> Later in same chapter: "... or being collected by the garbage collector—its destructor is called, if present."
>>
>> Is that really true?
>
> hmm, you seem to be right, but this might be a bug. I'm pretty sure the struct dtors were called on arrays not long ago but it isn't really reliable with the GC (My weasel word there is "provably", sometimes the GC can't prove there are no references; false pointers etc) but still blargh this current reality seems weird.

:(

And the 1st question?

On Thu, 29 May 2014 09:57:40 -0400, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Thursday, 29 May 2014 at 13:01:50 UTC, Szymon Gatner wrote:
>> Later in same chapter: "... or being collected by the garbage collector—its destructor is called, if present."
>>
>> Is that really true?
>
> hmm, you seem to be right, but this might be a bug. I'm pretty sure the struct dtors were called on arrays not long ago but it isn't really reliable with the GC (My weasel word there is "provably", sometimes the GC can't prove there are no references; false pointers etc) but still blargh this current reality seems weird.

The GC never has called struct destructors for arrays of structs or individual structs allocated on the heap.

It will call destructors on structs that are members of classes ONLY because the class destructor will call the struct destructor.

One other situation a heap allocated struct will have it's destructor called (I think) is due to a closure allocation, but I'm not 100% sure how that works. A way to verify is to make a closure occur, then test the closure's block to see if FINALIZE flag is set on it.

-Steve

On Thursday, 29 May 2014 at 13:01:50 UTC, Szymon Gatner wrote:
> - point 5 (of How to do it...) says: "... and free the object if necessary", but then in code:

Sorry, I typed this answer but forgot to actually post it. But to keep the example focused on postblit and destructor stuff instead of malloc/free so I used the writeln instead of the actual calls.

So all you'd have to do is do free() where it says "Destroyed" instead and alloc in the ctor.