• Michael <mcoupland gmail.com> Jan 22 2008
• "Unknown W. Brackets" <unknown simplemachines.org> Jan 22 2008
• Brad Roberts <braddr puremagic.com> Jan 22 2008

Michael <mcoupland gmail.com> writes:

Wow, yeah I think that's pretty unfortunate. I haven't done much D coding, and
was only tangentially aware of the copy-on-write nature of D arrays (which I
think is the underlying cause of this bug/feature...?)

This seems to seriously violate the principle of least surprise: I strongly
suspect that most non-D programmers would make the same assumption I did. It's
one thing when you're passing around a bunch of char*'s; but this is a full
featured string class!

Chalk it up to the pains of learning D if you want, but I'm not confident I
won't make this mistake numerous times (resulting in potentially strange and
hard-to-solve bugs) before getting it straight in my head, which is very
frustrating... :(

bearophile Wrote:

 Unknown W. Brackets:
 As it happens, the problem is the way you are abusing File's buffer. 
 You're taking the line, and using it... where the stream is overwriting 
 that space with new data.


 Yes, D is rather unsafe in that regard. To avoid this kind of bugs I add a
"bool copy=true" as a template parameter (constant at compile time) to all my
classes that return iterable objects then manage lot of data. So by default
they perform the copy, and you avoid that whole class of bugs. When you know
what you are doing and you want to go faster (sometimes 10 times faster)
accepting a bit less safe code, you set that copy flag to false, and it keeps
using the same buffer. I think the Phobos can grow such extra parameter in its
iterable objects to avoid such kind of bugs.
 
 Bye,
 bearophile

"Unknown W. Brackets" <unknown simplemachines.org> writes:

At the end of the day, you still need to have some tracking of memory 
management.  It's just not as complicated as with C/C++.

That is, someone still "owns" the data.  In this case, it's the stream. 
  The stream may change this data (since it owns it) which will screw 
you up unless you copy it.

This is actually not copy on write.  But, copy on write would make the 
stream functions very slow since they would constantly be allocating 
memory while reading...

-[Unknown]


Michael wrote:
 Wow, yeah I think that's pretty unfortunate. I haven't done much D coding, and
was only tangentially aware of the copy-on-write nature of D arrays (which I
think is the underlying cause of this bug/feature...?)
 
 This seems to seriously violate the principle of least surprise: I strongly
suspect that most non-D programmers would make the same assumption I did. It's
one thing when you're passing around a bunch of char*'s; but this is a full
featured string class!
 
 Chalk it up to the pains of learning D if you want, but I'm not confident I
won't make this mistake numerous times (resulting in potentially strange and
hard-to-solve bugs) before getting it straight in my head, which is very
frustrating... :(
 
 bearophile Wrote:
 
 Unknown W. Brackets:
 As it happens, the problem is the way you are abusing File's buffer. 
 You're taking the line, and using it... where the stream is overwriting 
 that space with new data.



 Bye,
 bearophile

Brad Roberts <braddr puremagic.com> writes:

In 2.x you can probably make it safe by declaring the key as invariant. 
  I haven't actually tried it to see how well it works out, but in 
concept that's how keys ought to behave.

Later,
Brad


Unknown W. Brackets wrote:
 At the end of the day, you still need to have some tracking of memory 
 management.  It's just not as complicated as with C/C++.
 
 That is, someone still "owns" the data.  In this case, it's the stream. 
  The stream may change this data (since it owns it) which will screw you 
 up unless you copy it.
 
 This is actually not copy on write.  But, copy on write would make the 
 stream functions very slow since they would constantly be allocating 
 memory while reading...
 
 -[Unknown]
 
 
 Michael wrote:
 Wow, yeah I think that's pretty unfortunate. I haven't done much D 
 coding, and was only tangentially aware of the copy-on-write nature of 
 D arrays (which I think is the underlying cause of this bug/feature...?)

 This seems to seriously violate the principle of least surprise: I 
 strongly suspect that most non-D programmers would make the same 
 assumption I did. It's one thing when you're passing around a bunch of 
 char*'s; but this is a full featured string class!

 Chalk it up to the pains of learning D if you want, but I'm not 
 confident I won't make this mistake numerous times (resulting in 
 potentially strange and hard-to-solve bugs) before getting it straight 
 in my head, which is very frustrating... :(

 bearophile Wrote:

 Unknown W. Brackets:
 As it happens, the problem is the way you are abusing File's buffer. 
 You're taking the line, and using it... where the stream is 
 overwriting that space with new data.


 add a "bool copy=true" as a template parameter (constant at compile 
 time) to all my classes that return iterable objects then manage lot 
 of data. So by default they perform the copy, and you avoid that 
 whole class of bugs. When you know what you are doing and you want to 
 go faster (sometimes 10 times faster) accepting a bit less safe code, 
 you set that copy flag to false, and it keeps using the same buffer. 
 I think the Phobos can grow such extra parameter in its iterable 
 objects to avoid such kind of bugs.

 Bye,
 bearophile