Buffered Files & Associative Arrays

[Brad Roberts]

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.
>>> 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
>>