Short article on std.parallism

Robert Jacques sandford at jhu.edu
Wed Jun 8 22:19:31 PDT 2011


On Tue, 31 May 2011 02:21:13 -0400, Andrej Mitrovic  
<andrej.mitrovich at gmail.com> wrote:
> Why doesn't Appender overload opCatAssign? It would be almost trivial
> to replace usage of existing arrays with Appender, instead of having
> to replace all calls with var.put().

I've submitted a patch for an improved appender implementation. I didn't  
include '~=' as at the time, I thought it unnecessarily complicated  
dependent patch to std.range.put. ( See:  
http://d.puremagic.com/issues/show_bug.cgi?id=5813 and  
http://d.puremagic.com/issues/show_bug.cgi?id=5233 ) On review, I think it  
should be a trivial fix. And, as there were two enhancement requests in  
bugzilla for appender + "~=" (See Issue 4287), I will update my patches.

> And why doesn't it overload toString? You can't print its contents to
> stdout like you can with slices.

In the current appender? No reason. In my patched appender? Less trivial  
but doable. I've put it on my todo list.

> And why can't you slice an Appender?

What do you mean by a slice? An appender slice is non-nonsensical, since  
it can't append. If you mean slicing an appender to get a T[]; there is no  
technical reason why it can't be done now. But it's bad design. Supporting  
slicing, indexing and even length all expose too much of the underlying  
implementation. And array building utilities should be allowed to change  
their internal implementations. For example, in .Net 4.0, StringBuilder  
changed from a dynamic array to a linked list. And a linked list can't  
efficiently index nor slice. Regarding my patched appender, O(1) indexing  
and slicing is doable, but would require some additional memory overhead  
and would not be as fast as built-in arrays.

> I see a lot of drawbacks with the only benefit being performance.

It also lets you build immutable and const arrays like they were mutable.  
Oh, and for my patch that performance gain, in terms of free memory and  
performance is massive for large arrays.

> Now,
> if Appender had some syntax sugar to make it appear as if it were a
> simple dynamic array (well, slice..), that would be sweet and would
> encourage its use, at least with me. Otherwise it just looks ugly
> compared to the sexy D arrays. It looks like everything is becoming a
> template in a library these days..

A good array builder _isn't_ a simple array (dynamic or otherwise) and it  
shouldn't be used as such. Appender has one job and needs to do it well.  
Supporting other functions that have very poor performance is a sure way  
to whittle away all the performance gains using Appender gets you in the  
first place.


More information about the Digitalmars-d-announce mailing list