I've read a bit about the requirement for write on copy semantics being necessary.

Understandably since a slice will point to the same array data.

I gatther that its got to be done by the programmer.  I this such a good thing?

Could the compiler/runtime not determin when this is necessary and automatically make a copy?

Am I missing something?

Scott Egan schrieb:
> I've read a bit about the requirement for write on copy semantics being
> necessary.
> 
> Understandably since a slice will point to the same array data.

It should be a standard strategy for libraries. In your code, you may do as you please. So are libraries for code which is only used internally and not called by the user.

> I gatther that its got to be done by the programmer.  I this such a good
> thing?

Yes, so it is. Walter decided it would be right as it is, because, say, when doing a functional style processing, you would need to avoid copying redundantly at every call. On the other hand, one could say, let "in" for arrays mean constant semantics or copy semantics as you suggest below, and assume "inout" if one wants the result to promote upwards - because without inout array resizes and such don't work anyway.

> Could the compiler/runtime not determin when this is necessary and
> automatically make a copy?

Perhaps - if it detects that an array is being written to. But then again, in such cases there are different decision strategies. One could be, if function contains code where array is lvalue, always copy at the beginning of the function. Another could be, copy at the first actual assignment - which could never happen and thus be a win - and maintain a boolean which has to be checked at every assignment - which is then a loss. As you see, they perform differently well depending on the task - but only the programmer could decide that and implement the optimal strategy, it cannot be done automatically.

> Am I missing something?

I don't think you are any longer. :>

-eye

PS. I think this is one of the fundamental questions - would it be worth adding that to a Wiki?

"Scott Egan" <scotte@tpg.com.aux> wrote in message news:c5ong8$ajv$1@digitaldaemon.com...
> I've read a bit about the requirement for write on copy semantics being necessary.
>
> Understandably since a slice will point to the same array data.
>
> I gatther that its got to be done by the programmer.  I this such a good thing?
>
> Could the compiler/runtime not determin when this is necessary and automatically make a copy?
>
> Am I missing something?

In order to make copy-on-write work automatically, one has to detect when a write is done to an array. Without hardware support for this (hardware support does exist for such, but only at the 4k page level), the compiler will have to either insert 'write barrier' checks on every write to an array, or would have to take the conservative approach and copy the array for every write to it. The latter is how javascript and (I heard) how delphi works. But it makes multiple sequential writes to an array incredibly slow and memory hoggish, rendering it completely unacceptable for a performance oriented language like D.

I just draged this from the MSDN Library - jsut for info.  Obviously MS throught about this too.

Strings are immutable
One of the hard things to get used to in the .NET Framework is that String
objects are immutable, meaning once they're created their values cannot be
changed. (However, you can reassign the string reference to refer to another
string, freeing up the first string for garbage collection if no other
references to it exist.)

The methods of String that appear to manipulate the string do not change the current string; instead, they create a new string and return it. Even changing, inserting, or deleting a single character causes a new string to be created and the old one to be thrown away.

Note that the process of repeatedly creating and throwing away strings can be slow. But making strings immutable has a number of advantages, in that ownership, aliasing, and threading issues are all much simpler with immutable objects. For instance, strings are always safe for multithreaded programming, since there's nothing a thread can do that would mess up another thread by modifying a string, since strings cannot be modified.




"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:c5p8kg$15eu$1@digitaldaemon.com...
> Scott Egan schrieb:
> > I've read a bit about the requirement for write on copy semantics being necessary.
> >
> > Understandably since a slice will point to the same array data.
>
> It should be a standard strategy for libraries. In your code, you may do as you please. So are libraries for code which is only used internally and not called by the user.
>
> > I gatther that its got to be done by the programmer.  I this such a good thing?
>
> Yes, so it is. Walter decided it would be right as it is, because, say, when doing a functional style processing, you would need to avoid copying redundantly at every call. On the other hand, one could say, let "in" for arrays mean constant semantics or copy semantics as you suggest below, and assume "inout" if one wants the result to promote upwards - because without inout array resizes and such don't work anyway.
>
> > Could the compiler/runtime not determin when this is necessary and automatically make a copy?
>
> Perhaps - if it detects that an array is being written to. But then again, in such cases there are different decision strategies. One could be, if function contains code where array is lvalue, always copy at the beginning of the function. Another could be, copy at the first actual assignment - which could never happen and thus be a win - and maintain a boolean which has to be checked at every assignment - which is then a loss. As you see, they perform differently well depending on the task - but only the programmer could decide that and implement the optimal strategy, it cannot be done automatically.
>
> > Am I missing something?
>
> I don't think you are any longer. :>
>
> -eye
>
> PS. I think this is one of the fundamental questions - would it be worth adding that to a Wiki?

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c5qq8b$fb3$1@digitaldaemon.com...
> Walter wrote:
>
> >
> >In order to make copy-on-write work automatically, one has to detect when
a
> >write is done to an array. Without hardware support for this (hardware support does exist for such, but only at the 4k page level), the compiler will have to either insert 'write barrier' checks on every write to an array, or would have to take the conservative approach and copy the array for every write to it. The latter is how javascript and (I heard) how
delphi
> >works. But it makes multiple sequential writes to an array incredibly
slow
> >and memory hoggish, rendering it completely unacceptable for a
performance
> >oriented language like D.
> >
> >
> Couldn't something like this be enabled only for debug mode, and parhaps specifically specified by the programmer?

It could, but I think it's better to just lay out the way it works and stick with it.

"Scott Egan" <scotte@tpg.com.aux> wrote in message news:c5r9ke$13o2$1@digitaldaemon.com...
> Note that the process of repeatedly creating and throwing away strings can be slow. But making strings immutable has a number of advantages, in that ownership, aliasing, and threading issues are all much simpler with immutable objects. For instance, strings are always safe for multithreaded programming, since there's nothing a thread can do that would mess up another thread by modifying a string, since strings cannot be modified.

It's a perfectly valid approach, except that it's slow and therefore not suitable for high performance programming applications.