GCs in the news

[Dicebot via Digitalmars-d]

On Friday, 18 July 2014 at 00:08:17 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> 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.

Yes this looks better.