Am Tue, 30 Sep 2014 05:23:29 -0700 schrieb Andrei Alexandrescu <seewebsiteforem...@erdani.org>:
> On 9/30/14, 1:34 AM, Johannes Pfau wrote: > > So you propose RC + global/thread local allocators as the solution > > for all memory related problems as 'memory management is not > > allocation'. And you claim that using output ranges / providing > > buffers / allocators is not an option because it only works in some > > special cases? > > Correct. I assume you meant an irony/sarcasm somewhere :o). The sarcasm is supposed to be here: '_all_ memory related problems' ;-) I guess my point is that although RC is useful in some cases output ranges / sink delegates / pre-allocated buffers are still necessary in other cases and RC is not the solution for _everything_. As Manu often pointed out sometimes you do not want any dynamic allocation (toStringz in games is a good example) and here RC doesn't help. Another example is format which can already write to output ranges and uses sink delegates internally. That's a much better abstraction than simply returning a reference counted string (allocated with a thread local allocator). Using sink delegates internally is also more efficient than creating temporary RCStrings. And sometimes there's no allocation at all this way (directly writing to a socket/file). > > > What if I don't want automated memory _management_? What if I want a > > function to use a stack buffer? Or if I want to free manually? > > > > If I want std.string.toStringz to put the result into a temporary > > stack buffer your solution doesn't help at all. Passing an ouput > > range, allocator or buffer would all solve this. > > Correct. The output of toStringz would be either a GC string or an RC > string. But why not provide 3 overloads then? toStringz(OutputRange) string toStringz(Policy) //char*, actually RCString toStringz(Policy) The notion I got from some of your posts is that you're opposed to such overloads, or did I misinterpret that?
