On Thu, Jul 17, 2014 at 06:32:58PM +0000, Dicebot via Digitalmars-d wrote:
> On Thursday, 17 July 2014 at 18:22:11 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >Actually, I've realized that output ranges are really only useful
> >when you want to store the final result. For data in mid-processing,
> >you really want to be exporting an input (or higher) range interface
> >instead, because functions that take output ranges are not
> >composable. And for storing final results, you just use
> >std.algorithm.copy, so there's really no need for many functions to
> >take an output range at all.
>
> Plain algorithm ranges rarely need to allocate at all so those are
> somewhat irrelevant to the topic. What I am speaking about are variety
> of utility functions like this:
>
> S detab(S)(S s, size_t tabSize = 8)
> if (isSomeString!S)
>
> this allocates result string. Proper alternative:
>
> S detab(S)(ref S output, size_t tabSize = 8)
> if (isSomeString!S);
>
> plus
>
> void detab(S, OR)(OR output, size_t tab_Size = 8)
> if ( isSomeString!S
> && isSomeString!(ElementType!OR)
> )
I think you're missing the input parameter. :)
void detab(S, OR)(S s, OR output, size_t tabSize = 8) { ... }
I argue that you can just turn it into this:
auto withoutTabs(S)(S s, size_t tabSize = 8)
{
static struct Result {
... // implementation here
}
static assert(isInputRange!Result);
return Result(s, tabSize);
}
auto myInput = "...";
auto detabbedInput = myInput.withoutTabs.array;
// Or:
MyOutputRange sink; // allocate using whatever scheme you want
myInput.withoutTabs.copy(sink);
The algorithm itself doesn't need to know where the result will end up
-- sink could be stdout, in which case no allocation is needed at all.
Or are you talking about in-place modification of the input string?
That's a different kettle o' fish.
T
--
EMACS = Extremely Massive And Cumbersome System
