dmd 1.057 and 2.041 release

[Steven Schveighoffer]

On Mon, 08 Mar 2010 03:45:21 -0500, Lars T. Kyllingstad  
<public at kyllingen.nospamnet> wrote:

> Simen kjaeraas wrote:
>> Walter Bright <newshound1 at digitalmars.com> wrote:
>>
>>> Lots of meat and potatoes here, and a cookie! (spelling checker for  
>>> error messages)
>>>
>>> http://www.digitalmars.com/d/1.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.1.057.zip
>>>
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.2.041.zip
>>>
>>> Thanks to the many people who contributed to this update!
>>  I don't know what to find more awesome with this update - possibly
>> the operator overloading. Thanks a bunch, guys!
>
> I just noticed that Steven Schveighoffer's array append patch made it  
> into this release.  That ranks pretty high on the awesome scale too.  :)

Thanks :)

One note that was not mentioned on the changelog, there are three new  
runtime functions for arrays.  They are in object.di (and the docs are  
there too):

  * setCapacity(T[] arr, int newcapacity): preallocate at least newcapacity  
elements.  This is intended to replace the "set length to zero" trick.
  * @property capacity(T[] arr): get the capacity (yes, it's a property,  
ddoc does not propogate the @property attribute)
  * shrinkToFit(T[] arr): This one is a bit tricky and technically unsafe.   
It reduces the size of the "allocated" length to fit the length of the  
array.  The allocated length is the length that the runtime assumes is  
being used of the memory block.  This is what aids in preventing stomping,  
so use with care.  You can achieve stomping if you use shrinkToFit on a  
slice, but still have references to the trimmed data.  Example:

string s = "12345".idup;
string slice = s[0..2];
slice.shrinkToFit(); // tells the runtime that you will no longer use any  
data beyond the slice
slice ~= "00"; // appends in place, overwriting immutable data referenced  
in s!

Using s after such usage results in undefined behavior (probably should be  
noted in the docs).

The use case is when you want to reuse a buffer when you know you will not  
use the trimmed area again.  You can consider the trimmed off data  
unallocated.

The shrinkToFit name is not my favorite, anyone care to submit a better  
name?  minimize is out because it has connotations of math already.

setCapacity will be changed in the next release to reserve() (could not  
squeeze that change in), since it was pointed out that you are requesting  
a capacity, not setting it.

-Steve