www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - bug: concatenation doesn't create a copy

reply Nick <Nick_member pathlink.com> writes:
Maybe this is a known bug already, in that case consider this a friendly
reminder :)

The documentation says the following:







However, this isn't the case, as the following example illustrates:












Regards,
Nick
Jul 31 2004
parent reply From <From_member pathlink.com> writes:
Oh, forgot to add: Even if it did work, having to write something like

a = b ~ "";

to copy a string seems a bit arcane to me. And the obvious "proper" way to copy
arrays (and indeed the only way to do it at the moment) is

a.length = b.length;
a[] = b[];

Why isn't there a .copy property? Something like

a = b.copy;  // a is a copy of b


Nick

In article <ceh4l7$1ddi$1 digitaldaemon.com>, Nick says...
Maybe this is a known bug already, in that case consider this a friendly
reminder :)

The documentation says the following:







However, this isn't the case, as the following example illustrates:












Regards,
Nick
Jul 31 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
From wrote:

 Oh, forgot to add: Even if it did work, having to write something like
 
 a = b ~ "";
 
 to copy a string seems a bit arcane to me. And the obvious "proper" way to
 copy arrays (and indeed the only way to do it at the moment) is
 
 a.length = b.length;
 a[] = b[];
 
 Why isn't there a .copy property? Something like
 
 a = b.copy;  // a is a copy of b
try .dup
Jul 31 2004
parent reply Nick <Nick_member pathlink.com> writes:
In article <ceh71j$1eci$1 digitaldaemon.com>, Ben Hinkle says...
 Oh, forgot to add: Even if it did work, having to write something like
 
 a = b ~ "";
 
 to copy a string seems a bit arcane to me. And the obvious "proper" way to
 copy arrays (and indeed the only way to do it at the moment) is
 
 a.length = b.length;
 a[] = b[];
 
 Why isn't there a .copy property? Something like
 
 a = b.copy;  // a is a copy of b
try .dup
And it's even documented :) Silly me. Thanks. Nick
Jul 31 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Nick wrote:

 In article <ceh71j$1eci$1 digitaldaemon.com>, Ben Hinkle says...
<snip>
 try .dup
And it's even documented :) Silly me. Thanks.
Indeed. But wasn't your original post about the fact that you can't rely on concatenation to create a copy, if at runtime one of the operands may or may not be zero-length? Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Aug 02 2004
parent reply Nick <Nick_member pathlink.com> writes:
In article <cel5j3$2vk3$1 digitaldaemon.com>, Stewart Gordon says...
Indeed.  But wasn't your original post about the fact that you can't 
rely on concatenation to create a copy, if at runtime one of the 
operands may or may not be zero-length?
Yes, that's correct. I'm not quite sure how I feel about that one, though. The "copy-on-write" principle that D seems to follow says that string1 ~ string2 should be a reference, not a copy, if one of the strings are empty. This might be more efficient in some cases. On the other hand, if you want to be sure to get a copy, you would then have to write (string1 ~ string2).dup, which might cause double copying if both strings are nonempty (unless the compiler can optimize one of them away automatically.) In any case, dmd does not follow with the docs at the moment. Nick
Aug 03 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Nick wrote:

<snip>
 On the other hand, if you want to be sure to get a copy, you would 
 then have to write (string1 ~ string2).dup, which might cause double 
 copying if both strings are nonempty (unless the compiler can 
 optimize one of them away automatically.)
After checking that it doesn't already optimise away the .dup under the false belief that concatenation works correctly. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Aug 04 2004