The great slice debate -- should slices be separated from arrays?

Steven Schveighoffer schveiguy at yahoo.com
Tue Nov 24 12:53:11 PST 2009


On Tue, 24 Nov 2009 15:25:27 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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



More information about the Digitalmars-d mailing list