May 31, 2011
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().

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

And why can't you slice an Appender?

I see a lot of drawbacks with the only benefit being performance. 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..
May 31, 2011
On 2011-05-30 23:21, Andrej Mitrovic 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().
> 
> And why doesn't it overload toString? You can't print its contents to stdout like you can with slices.
> 
> And why can't you slice an Appender?
> 
> I see a lot of drawbacks with the only benefit being performance. 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..

If you could slice an Appender, it would lose all of its guarantees. It can do what it does in part because it knows that it hasn't been sliced. If you were slicing it, then you'd have to worry about possible reallocations which loses all of the benefit of Appender in the first place. Appender only works because it's creating an array. If you tried to use it as a dynamic array in general, it wouldn't work. It's purely an optimization for creating arrays. ~= can't be made to do what Appender does, and if you tried to make Appender do what ~= does, then Appender couldn't do what it currently does. Appender has a very specific purpose and no one should be trying to replace dynamic arrays with it. It's just that if you want to get your code to be as fast as possible, there are cases where using Appender is a good idea. Beyond that, you shouldn't be using Appender.

- Jonathan M Davis
May 31, 2011
On Tue, 31 May 2011 02:21:13 -0400, Andrej Mitrovic <andrej.mitrovich@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().

It should, there might already be an enhancement filed for it.

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

writeln(app.data);
auto slice = app.data[2...6];

-Steve
June 09, 2011
On Tue, 31 May 2011 02:21:13 -0400, Andrej Mitrovic <andrej.mitrovich@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.
1 2
Next ›   Last »