www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Re: dmd 1.057 and 2.041 release

reply biozic <biozic free.fr> writes:
Steven Schveighoffer Wrote:

   * 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  

Actually, slice.capacity *increases* from 0 to s.capacity when calling shrinkToFit, doesn't it? So "stomp" or "prepare_for_stomping" could be a better name.
Mar 09 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 09 Mar 2010 10:10:10 -0500, biozic <biozic free.fr> wrote:

 Steven Schveighoffer Wrote:

   * 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

Actually, slice.capacity *increases* from 0 to s.capacity when calling shrinkToFit, doesn't it? So "stomp" or "prepare_for_stomping" could be a better name.

Yes, it is technically like that. shrinkToFit really looks weird as a property of the slice you are shrinking to because it really is operating on the array data itself (which has no concrete type or reference). I don't like anything that talks about stomping, because we are not trying to say this is a stomping operation. I want to focus more on the fact that you are declaring the data after the slice as being no longer used. It's definitely a harder function to name... -Steve
Mar 09 2010
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Michal Minich wrote:

 On Tue, 09 Mar 2010 10:23:07 -0500, Steven Schveighoffer wrote:
 
 I want to focus more on the fact that you are declaring the data after
 the slice as being no longer used.

kind of assumeUnique ... assumeNoArrayReference ?

I like that. Or assumeNoMemoryAliasing. It should be clear that it is a potentially very unsafe function.
Mar 09 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Lutger:
 Or assumeNoMemoryAliasing. It should be clear that it is a 
 potentially very unsafe function. 

This is getting there :-) Bye, bearophile
Mar 09 2010
prev sibling parent reply David Gileadi <foo bar.com> writes:
On 3/9/2010 12:44 PM, Steven Schveighoffer wrote:
 On Tue, 09 Mar 2010 14:36:41 -0500, Michal Minich
 <michal.minich gmail.com> wrote:

 assumeNoArrayReference does not express that there can be references to
 the original array before slice start. probably better expressing, if
 rather long name could be

Actually, you can have valid references up until the slice end.
 assumeNoOriginArrayReferencesPastSliceEnd
 assumeNoOriginArrayReferencesAfter

These are too long. As much as this is an unsafe to-be-used-with-care function, we don't want to torture those who need it :) I prefer a name with 1-3 terms in it.
 or probably somthing like this:
 unsafeDeletePastSlice

also a little long, and I don't like the term delete, it's not actually deleting the memory. -Steve

As long as we're bikeshedding, maybe assumeUnreferencedAfter?
Mar 09 2010
parent Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:
 On Tue, 09 Mar 2010 14:54:11 -0500, David Gileadi <foo bar.com> wrote:
 
 On 3/9/2010 12:44 PM, Steven Schveighoffer wrote:
 On Tue, 09 Mar 2010 14:36:41 -0500, Michal Minich
 <michal.minich gmail.com> wrote:

 assumeNoArrayReference does not express that there can be references to
 the original array before slice start. probably better expressing, if
 rather long name could be

Actually, you can have valid references up until the slice end.
 assumeNoOriginArrayReferencesPastSliceEnd
 assumeNoOriginArrayReferencesAfter

These are too long. As much as this is an unsafe to-be-used-with-care function, we don't want to torture those who need it :) I prefer a name with 1-3 terms in it.
 or probably somthing like this:
 unsafeDeletePastSlice

also a little long, and I don't like the term delete, it's not actually deleting the memory.

As long as we're bikeshedding, maybe assumeUnreferencedAfter?

This is exactly the semantic meaning we are going for. I'd like it to be shorter... synonyms for unreferenced? assumeUnusedAfter Any others ideas? -Steve

Mar 09 2010
prev sibling next sibling parent Michal Minich <michal.minich gmail.com> writes:
On Tue, 09 Mar 2010 10:23:07 -0500, Steven Schveighoffer wrote:

 I want to focus more on the fact that you are declaring the data after 
 the slice as being no longer used.

kind of assumeUnique ... assumeNoArrayReference ?
Mar 09 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 09 Mar 2010 12:54:16 -0500, Lutger <lutger.blijdestijn gmail.com>  
wrote:

 Michal Minich wrote:

 On Tue, 09 Mar 2010 10:23:07 -0500, Steven Schveighoffer wrote:

 I want to focus more on the fact that you are declaring the data after
 the slice as being no longer used.

kind of assumeUnique ... assumeNoArrayReference ?

I like that. Or assumeNoMemoryAliasing. It should be clear that it is a potentially very unsafe function.

I like this train of thought, assume is a good term for what you are doing, and it is consistent with assumeUnique. The only thing I don't like about it is you aren't really assuming anything about the slice, you are assuming the data after the slice is no longer used. It looks weird that you are assuming something about the slice. assumeEndOfData ? assumeAllocation ? I don't 100% like those either. -Steve
Mar 09 2010
prev sibling next sibling parent Michal Minich <michal.minich gmail.com> writes:
On Tue, 09 Mar 2010 14:07:10 -0500, Steven Schveighoffer wrote:

 On Tue, 09 Mar 2010 12:54:16 -0500, Lutger
 <lutger.blijdestijn gmail.com> wrote:
 
 Michal Minich wrote:

 On Tue, 09 Mar 2010 10:23:07 -0500, Steven Schveighoffer wrote:

 I want to focus more on the fact that you are declaring the data
 after the slice as being no longer used.

kind of assumeUnique ... assumeNoArrayReference ?

I like that. Or assumeNoMemoryAliasing. It should be clear that it is a potentially very unsafe function.

I like this train of thought, assume is a good term for what you are doing, and it is consistent with assumeUnique. The only thing I don't like about it is you aren't really assuming anything about the slice, you are assuming the data after the slice is no longer used. It looks weird that you are assuming something about the slice. assumeEndOfData ? assumeAllocation ? I don't 100% like those either. -Steve

assumeNoArrayReference does not express that there can be references to the original array before slice start. probably better expressing, if rather long name could be assumeNoOriginArrayReferencesPastSliceEnd assumeNoOriginArrayReferencesAfter or probably somthing like this: unsafeDeletePastSlice
Mar 09 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 09 Mar 2010 14:36:41 -0500, Michal Minich  
<michal.minich gmail.com> wrote:

 assumeNoArrayReference does not express that there can be references to
 the original array before slice start. probably better expressing, if
 rather long name could be

Actually, you can have valid references up until the slice end.
 assumeNoOriginArrayReferencesPastSliceEnd
 assumeNoOriginArrayReferencesAfter

These are too long. As much as this is an unsafe to-be-used-with-care function, we don't want to torture those who need it :) I prefer a name with 1-3 terms in it.
 or probably somthing like this:
 unsafeDeletePastSlice

also a little long, and I don't like the term delete, it's not actually deleting the memory. -Steve
Mar 09 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 09 Mar 2010 14:54:11 -0500, David Gileadi <foo bar.com> wrote:

 On 3/9/2010 12:44 PM, Steven Schveighoffer wrote:
 On Tue, 09 Mar 2010 14:36:41 -0500, Michal Minich
 <michal.minich gmail.com> wrote:

 assumeNoArrayReference does not express that there can be references to
 the original array before slice start. probably better expressing, if
 rather long name could be

Actually, you can have valid references up until the slice end.
 assumeNoOriginArrayReferencesPastSliceEnd
 assumeNoOriginArrayReferencesAfter

These are too long. As much as this is an unsafe to-be-used-with-care function, we don't want to torture those who need it :) I prefer a name with 1-3 terms in it.
 or probably somthing like this:
 unsafeDeletePastSlice

also a little long, and I don't like the term delete, it's not actually deleting the memory.

As long as we're bikeshedding, maybe assumeUnreferencedAfter?

This is exactly the semantic meaning we are going for. I'd like it to be shorter... synonyms for unreferenced? assumeUnusedAfter Any others ideas? -Steve
Mar 09 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 09 Mar 2010 15:29:04 -0500, Don <nospam nospam.com> wrote:

 Steven Schveighoffer wrote:
 On Tue, 09 Mar 2010 14:54:11 -0500, David Gileadi <foo bar.com> wrote:

 As long as we're bikeshedding, maybe assumeUnreferencedAfter?

be shorter... synonyms for unreferenced? assumeUnusedAfter Any others ideas? -Steve


That is great! Do you think assumeSafeAppend is better, since we do call the operation append? -Steve
Mar 09 2010