On 3/6/2014 4:43 PM, H. S. Teoh wrote:
On Thu, Mar 06, 2014 at 01:26:46PM -0800, Walter Bright wrote:
A major goal for D in the short term is to reduce reliance in Phobos
on the GC. I was looking at std.string last night, and I noticed a
couple things:
1. The inputs are constrained to being strings. This is overly
restrictive, the inputs should be InputRanges.
2. The outputs should be a range, too. In fact, the string functions
should become algorithms. Then they won't need to allocate any
memory at all.
[...]
What about using output ranges?
A great question. I tend to regard output ranges as suitable for a container to
expose. An algorithm reads an InputRange, and presents its output as another
InputRange. This is so that algorithms can be easily chained together by the
user, and the last algorithm in the chain would be std.algorithm.copy(OutputRange).
For example, we could implement toStringz() as an algorithm that looks like:
auto toStringz(S)(S s) {
return chain(s, repeat(0, 1))
}
and use it like this:
string s = ...;
char[] buffer = ...;
s.toStringz.copy(buffer);
Note how the algorithm version of toStringz does not allocate any memory. buffer
would be the output range, but note how what it actually is is, and how its
memory is allocated, is selected by the user.
(std.buffer.scopebuffer is ideal for this sort of usage.)
std.file is loaded with calls to toStringz(), each of which leaks memory quite
unnecessarily. Using an algorithm version of toStringz(), along with
scopebuffer, will neatly eliminated these leaks.
You might be tempted to think that these are just little leaks, who cares. But I
recently wrote a D program that did tens of thousands of file operations, and
those little leaks turned into a raging river.
