On Tue, 24 Nov 2009 15:25:27 -0500, Andrei Alexandrescu
<[email protected]> wrote:
Steven Schveighoffer wrote:
Why do we need this scheme then? If it only makes sense to use
slicing when you are done appending, then why not use that model with
today's rules? Why make code that uses slices before you are finished
appending perform poorly? Why make code that uses temporary slices
(like I showed in my example) perform poorly?
-Steve
Oh, I think I understand. I wasn't talking about the current proposal,
but instead of your hypothetical Array class (note that I capitalized
Array). So probably I caused confusion.
I might be the one causing confusion :) I assumed you were taking the
side of "Array should be a separate type from slice" and proposing a
method of avoiding hard-to-determine reallocation properties.
But my counter-point is that your method forces users (at least users who
care about performance) to avoid slicing in the first place until all
appending operations are finished. A common usage of slicing is to
temporarily use a read-only view of a portion of an array, as in my
example. In that case, you inadvertently triggered a reallocation when
none was necessary. While that is a conservative approach, it hinders
performance unnecessarily. Basically, in many cases where slicing and
appending are interleaved, you will incur an unreasonable performance
penalty.
*and* without this scheme, you can achieve the same results by writing
your code the way you would have written it if this scheme were in place.
In other words, isn't it just enough to recommend "don't slice before
you're done appending" instead of inventing weird allocation rules to herd
programmers in that direction?
-Steve
