Summary: Safer stdin.byLine()
--- Comment #0 from bearophile_h...@eml.cc 2010-07-16 16:21:32 PDT ---
This is relative to page 16-17 of The D Programming Language. It explains
stdin.byLine() and possible 'rather hard to find' bugs caused by not
duplicating the input data.
If I use D to write 20-lines long scripts I really don't want to remember to
dup all things (in D1 code I sometimes end up dupping too much, to be on the
safe side). So I suggest a different API for the line reading:
- stdin.byLineMutable() (or another similar name, longer than "byLine" that
makes it clear it doesn't copy): for the current behaviour that avoids a memory
allocation for each line read. This is faster but it's less safe.
- stdin.byLine(): that allocates a new string for each line, this is safer, as
in Python (Python also uses heuristics to speed up this method as much as
possible, because this is often a very common and performance-critical
operation in scripts).
All D default design policy says that unsafe but faster things need to be asked
for, and the default things must be less bug-prone. If I write a small D script
I can use byLine(), hoping to avoid some bugs. If later I see profiling shows
me it's too much slow, I can replace the byLine() with the other method and
optimize the code, carefully, removing some heap allocations.
(An alternative design strategy is to keep just the byLine() method, but give
it an optional default argument, like stdin.byLine(bool copy=True) or
stdin.byLine(bool COPY=True)(), that on default copies the line with a new
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------