import std.stdio;
import std.string;

void main() {
char[] x = toString(0);

// la de da...
x[0] = 'a';

// guess what i print
writefln("x=%s", toString(0));
}

It is because toString(uint) sometimes returns an array slice.

Aaron Lenfestey

On Mon, 26 Jun 2006 19:18:15 -0400, lenfestey at geemail.com <lenfestey_member@pathlink.com> wrote:

> import std.stdio;
> import std.string;
>
> void main() {
> char[] x = toString(0);
>
> // la de da...
> x[0] = 'a';
>
> // guess what i print
> writefln("x=%s", toString(0));
> }
>
> It is because toString(uint) sometimes returns an array slice.
>
> Aaron Lenfestey

In D you have to practice COW (copy-on-write) unless you are certain you are the only one using the memory.

On Mon, 26 Jun 2006 23:18:15 +0000 (UTC), lenfestey at geemail.com <lenfestey_member@pathlink.com> wrote:
> import std.stdio;
> import std.string;
>
> void main() {
> char[] x = toString(0);
>
> // la de da...
> x[0] = 'a';
>
> // guess what i print
> writefln("x=%s", toString(0));
> }
>
> It is because toString(uint) sometimes returns an array slice.

Theoretically "Copy on Write" should be used before writing to the string. Ideally the write should be detected and prevented by the compiler. Eventually I hope Walter can come up with a "const that works" for D :)

Regan

In article <op.tbr0mdsfpo9bzi@moe>, Chris Miller says...
>
>On Mon, 26 Jun 2006 19:18:15 -0400, lenfestey at geemail.com  =
>
><lenfestey_member@pathlink.com> wrote:
>
>> import std.stdio;
>> import std.string;
>>
>> void main() {
>> char[] x =3D toString(0);
>>
>> // la de da...
>> x[0] =3D 'a';
>>
>> // guess what i print
>> writefln("x=3D%s", toString(0));
>> }
>>
>> It is because toString(uint) sometimes returns an array slice.
>>
>> Aaron Lenfestey
>
>In D you have to practice COW (copy-on-write) unless you are certain you are the only one using the memory.

IM(h)O toString should *always* return a copy.

"BCS" <BCS_member@pathlink.com> wrote in message news:e7qd2l$j7g$1@digitaldaemon.com...
>
> IM(h)O toString should *always* return a copy.

I strongly agree.

On Tue, 27 Jun 2006 00:44:05 -0400, BCS <BCS_member@pathlink.com> wrote:

> In article <op.tbr0mdsfpo9bzi@moe>, Chris Miller says...
>>
>> On Mon, 26 Jun 2006 19:18:15 -0400, lenfestey at geemail.com  =
>>
>> <lenfestey_member@pathlink.com> wrote:
>>
>>> import std.stdio;
>>> import std.string;
>>>
>>> void main() {
>>> char[] x =3D toString(0);
>>>
>>> // la de da...
>>> x[0] =3D 'a';
>>>
>>> // guess what i print
>>> writefln("x=3D%s", toString(0));
>>> }
>>>
>>> It is because toString(uint) sometimes returns an array slice.
>>>
>>> Aaron Lenfestey
>>
>> In D you have to practice COW (copy-on-write) unless you are certain you
>> are the only one using the memory.
>
> IM(h)O toString should *always* return a copy.
>

Nah, I disagree. Take MemoryStream for example, what if it has 2MB, you want that copied every toString. This COW is just a different method than what's common in other languages, and yields such a great performance boost. If you want a copy, copy it. But if all you want to do is read the value, what is the point in copying.

Plus, where does this copying stop? Should every function returning an array, or even a reference, make sure the caller gets a copy he can modify?

However, I think I would be in favor of some type of immutability, provided it isn't so wordy and troublesome as C/C++'s.

Wouldn't this be solved by putting the string constants (assuming toString(0) returns an static constant) in read-only memory?

L.

Chris Miller wrote:
> On Tue, 27 Jun 2006 00:44:05 -0400, BCS <BCS_member@pathlink.com> wrote:
> 
>> In article <op.tbr0mdsfpo9bzi@moe>, Chris Miller says...
>>
>>>
>>> On Mon, 26 Jun 2006 19:18:15 -0400, lenfestey at geemail.com  =
>>>
>>> <lenfestey_member@pathlink.com> wrote:
>>>
>>>> import std.stdio;
>>>> import std.string;
>>>>
>>>> void main() {
>>>> char[] x =3D toString(0);
>>>>
>>>> // la de da...
>>>> x[0] =3D 'a';
>>>>
>>>> // guess what i print
>>>> writefln("x=3D%s", toString(0));
>>>> }
>>>>
>>>> It is because toString(uint) sometimes returns an array slice.
>>>>
>>>> Aaron Lenfestey
>>>
>>>
>>> In D you have to practice COW (copy-on-write) unless you are certain you
>>> are the only one using the memory.
>>
>>
>> IM(h)O toString should *always* return a copy.
>>
> 
> Nah, I disagree. Take MemoryStream for example, what if it has 2MB, you  want that copied every toString. This COW is just a different method than  what's common in other languages, and yields such a great performance  boost. If you want a copy, copy it. But if all you want to do is read the  value, what is the point in copying.
> 
> Plus, where does this copying stop? Should every function returning an  array, or even a reference, make sure the caller gets a copy he can modify?
> 
> However, I think I would be in favor of some type of immutability,  provided it isn't so wordy and troublesome as C/C++'s.

Hear Hear! ;)

Even if the immutable aspect could be supported for return-values only, we could then wrap our valuable immutables within an aggregate for those cases where immutability can be a considerable help (e.g. multi-threaded information sharing).

That approach (return-values only) may be naiive on my part ~ would it notably simplify things in terms of implementation detail?

BCS wrote:
> In article <op.tbr0mdsfpo9bzi@moe>, Chris Miller says...
> 
>>On Mon, 26 Jun 2006 19:18:15 -0400, lenfestey at geemail.com  =
>>
>><lenfestey_member@pathlink.com> wrote:
>>
>>
>>>import std.stdio;
>>>import std.string;
>>>
>>>void main() {
>>>char[] x =3D toString(0);
>>>
>>>// la de da...
>>>x[0] =3D 'a';
>>>
>>>// guess what i print
>>>writefln("x=3D%s", toString(0));
>>>}
>>>
>>>It is because toString(uint) sometimes returns an array slice.
>>>
>>>Aaron Lenfestey
>>
>>In D you have to practice COW (copy-on-write) unless you are certain you
>>are the only one using the memory.
> 
> 
> IM(h)O toString should *always* return a copy.


But this particular issue is not so hard to resolve ... for instance, if a target-array was provided as part of the itoa() operation, there would be no need for heap activity or for aliasing. On the flip side, it would mean the method signatures are somwhat less succinct? Perhaps there are other detrimental aspects?

In article <op.tbshnsu0po9bzi@moe>, Chris Miller says...
>
>On Tue, 27 Jun 2006 00:44:05 -0400, BCS <BCS_member@pathlink.com> wrote:=
>>
>> IM(h)O toString should *always* return a copy.
>>
>
>Nah, I disagree. Take MemoryStream for example, what if it has 2MB, you want that copied every toString. This COW is just a different method than what's common in other languages, and yields such a great performance boost. If you want a copy, copy it. But if all you want to do is read the value, what is the point in copying.
>

Overrides of object.toString might not be a good candidate for always copy, but
toSting(intType) will copy in most cases (~ always copies) but an implementation
might return a ptr to a static array for some cases (0-9 in the following
example);

char[] toString(uint i);
{
char[] ret;
const static char[] map = "0123456789";
ret = map[i%10..i%10+1];
i/=10;
while(i)
{
ret = map[i%10..i%10+1] ~ ret;
i/=10;
}
return ret;
}

This would be a bad choice for COW, forget it once and problems start cropping up all over the place. A Simpler implementation might still get unrolled to this.

>Plus, where does this copying stop? Should every function returning an array, or even a reference, make sure the caller gets a copy he can modify?
>

No, only when it is ALWAYS a bug if the referenced data is changed.