digitalmars.D.announce - Re: dmd 1.057 and 2.041 release
- biozic <biozic free.fr> Mar 09 2010
- "Steven Schveighoffer" <schveiguy yahoo.com> Mar 09 2010
- Lutger <lutger.blijdestijn gmail.com> Mar 09 2010
- bearophile <bearophileHUGS lycos.com> Mar 09 2010
- David Gileadi <foo bar.com> Mar 09 2010
- Don <nospam nospam.com> Mar 09 2010
- Michal Minich <michal.minich gmail.com> Mar 09 2010
- "Steven Schveighoffer" <schveiguy yahoo.com> Mar 09 2010
- Michal Minich <michal.minich gmail.com> Mar 09 2010
- "Steven Schveighoffer" <schveiguy yahoo.com> Mar 09 2010
- "Steven Schveighoffer" <schveiguy yahoo.com> Mar 09 2010
- "Steven Schveighoffer" <schveiguy yahoo.com> Mar 09 2010
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
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
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
Lutger:Or assumeNoMemoryAliasing. It should be clear that it is a potentially very unsafe function.
This is getting there :-) Bye, bearophile
Mar 09 2010
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
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
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
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
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
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
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
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