Am Wed, 01 Oct 2014 02:21:44 -0700 schrieb Andrei Alexandrescu <seewebsiteforem...@erdani.org>:
> On 9/30/14, 9:49 AM, Johannes Pfau wrote: > > 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_. > > Agreed. > > > 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). > > Agreed. > > >>> 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? > > I'm not opposed. Here's what I think. > > As an approach to using Phobos without a GC, it's been suggested that > we supplement garbage-creating functions with new functions that use > output ranges everywhere, or lazy ranges everywhere. > > I think a better approach is to make memory management a policy that > makes convenient use of reference counting possible. So instead of > garbage there'd be reference counted stuff. > > Of course, to the extent using lazy computation and/or output ranges > is a good thing to have for various reasons, they remain valid > techniques that are and will continue being used in Phobos. > > My point is that acknowledging and systematically using reference > counted types is an essential part of the entire approach. > > > Andrei > > OK then I got you wrong and I agree with everything you wrote above. Thanks for clarifying.
