www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - string literal error?

reply badmadevil <badmadevil gmail.com> writes:
Hi, sorry if already discussed.

codes:
   string x = "bug?" ;
   string y = "bug?" ;
   string z = "bug?".reverse ;
   writefln("%s : %s : %s", x, y, z) ;
   x.reverse ;
   writefln("%s : %s : %s", x, y, z) ;

output - D 1.027 & 2.013:
?gub : ?gub : ?gub
bug? : bug? : bug?

Should x, y, z be independent to each others?
May 08 2008
parent reply badmadevil <badmadevil gmail.com> writes:
badmadevil wrote:
 Hi, sorry if already discussed.
 
 codes:
   string x = "bug?" ;
   string y = "bug?" ;
   string z = "bug?".reverse ;
   writefln("%s : %s : %s", x, y, z) ;
   x.reverse ;

same effect if x is replace with literal "bug?", ie. "bug?".reverse ;
   writefln("%s : %s : %s", x, y, z) ;
 
 output - D 1.027 & 2.013:
  >?gub : ?gub : ?gub
  >bug? : bug? : bug?
 
 Should x, y, z be independent to each others?

May 08 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 08 May 2008 20:37:17 +0200, badmadevil <badmadevil gmail.com>  =

wrote:

 badmadevil wrote:
 Hi, sorry if already discussed.
  codes:
   string x =3D "bug?" ;
   string y =3D "bug?" ;
   string z =3D "bug?".reverse ;
   writefln("%s : %s : %s", x, y, z) ;
   x.reverse ;

same effect if x is replace with literal "bug?", ie. "bug?".reverse ;
   writefln("%s : %s : %s", x, y, z) ;
  output - D 1.027 & 2.013:
  >?gub : ?gub : ?gub
  >bug? : bug? : bug?
  Should x, y, z be independent to each others?


This happens because .reverse does in-place reversal. The correct way to do it would be: string x =3D "bug?".idup; string y =3D "bug?".idup; string z =3D "bug?".idup.reverse; writefln(x,y,z); x.reverse; writefln(x,y,z); writefln(typeof("bug?").stringof); Now, seeing as the array contents are invariant in this example, .reverse is not following the D rules of conduct. (i.e. it's buggy) -- Simen
May 08 2008
parent reply badmadevil <badmadevil gmail.com> writes:
Simen Kjaeraas wrote:
 On Thu, 08 May 2008 20:37:17 +0200, badmadevil <badmadevil gmail.com> 
 wrote:
 
 badmadevil wrote:
 Hi, sorry if already discussed.
  codes:
   string x = "bug?" ;
   string y = "bug?" ;
   string z = "bug?".reverse ;
   writefln("%s : %s : %s", x, y, z) ;
   x.reverse ;

same effect if x is replace with literal "bug?", ie. "bug?".reverse ;
   writefln("%s : %s : %s", x, y, z) ;
  output - D 1.027 & 2.013:
  >?gub : ?gub : ?gub
  >bug? : bug? : bug?
  Should x, y, z be independent to each others?


This happens because .reverse does in-place reversal. The correct way to do it would be: string x = "bug?".idup; string y = "bug?".idup; string z = "bug?".idup.reverse; writefln(x,y,z); x.reverse; writefln(x,y,z); writefln(typeof("bug?").stringof); Now, seeing as the array contents are invariant in this example, .reverse is not following the D rules of conduct. (i.e. it's buggy)

I see, .reverse is buggy in D2 situation. How about D1? string in D1 is just alias of char[]. It should be valid in the case of x.reverse. (x is of type char[]) It seems that the reason x,y,z reference to same string literal is to reduce bloated string data in the .exe (repeated literal array of other type, eg. integer, may not be reduced). dup/idup each literal array may avoid such bug, but would it be handy that idup/dup be implictly called during runtime? (btw, the title should read "string literal bug?")
 -- Simen

May 08 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
badmadevil <badmadevil gmail.com> wrote:

 I see, .reverse is buggy in D2 situation.

 How about D1?
 string in D1 is just alias of char[]. It should be valid in the case
 of x.reverse. (x is of type char[])

 It seems that the reason x,y,z reference to same string literal is to
 reduce bloated string data in the .exe (repeated literal array of othe=

 type, eg. integer, may not be reduced).
 dup/idup each literal array may avoid such bug, but would it be handy
 that idup/dup be implictly called during runtime?

Consider the case where you have a 2MB string literal (for some weird reason), with 1K references to it. Would you like for the program to cal= l .dup on each of those? A bit hypothetical, I know, but it should highlig= ht the problem. I believe for D1, COW (copy on write) is how things should work. In other words, the correct D1 program would look like this: string x =3D "bug?"; string y =3D "bug?"; string z =3D "bug?".dup.reverse; // copy because we're changing it writefln(x,y,z); x.dup.reverse; // copy because we're changing it writefln(x,y,z); writefln(typeof("bug?").stringof); In the context of D1, I can see how non-duped string literals may be a source of bugs, indeed. This (except that it does not work :p) is one of= the reasons I like D2's invariant strings. -- Simen
May 08 2008
parent badmadevil <badmadevil gmail.com> writes:
Simen Kjaeraas wrote:
 badmadevil <badmadevil gmail.com> wrote:
 
 I see, .reverse is buggy in D2 situation.

 How about D1?
 string in D1 is just alias of char[]. It should be valid in the case
 of x.reverse. (x is of type char[])

 It seems that the reason x,y,z reference to same string literal is to
 reduce bloated string data in the .exe (repeated literal array of other
 type, eg. integer, may not be reduced).
 dup/idup each literal array may avoid such bug, but would it be handy
 that idup/dup be implictly called during runtime?

Consider the case where you have a 2MB string literal (for some weird reason), with 1K references to it. Would you like for the program to call .dup on each of those? A bit hypothetical, I know, but it should highlight

Got the idea. Thank you!
 the problem. I believe for D1, COW (copy on write) is how things should
 work. In other words, the correct D1 program would look like this:
 
   string x = "bug?";
   string y = "bug?";
   string z = "bug?".dup.reverse; // copy because we're changing it
   writefln(x,y,z);
   x.dup.reverse; // copy because we're changing it
   writefln(x,y,z);
   writefln(typeof("bug?").stringof);
 
 In the context of D1, I can see how non-duped string literals may be a
 source of bugs, indeed. This (except that it does not work :p) is one of
 the reasons I like D2's invariant strings.
 
 -- Simen

May 10 2008