RFC: moving forward with @nogc Phobos
Johannes Pfau via Digitalmars-d
digitalmars-d at puremagic.com
Tue Sep 30 09:49:47 PDT 2014
Am Tue, 30 Sep 2014 05:23:29 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at 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?
More information about the Digitalmars-d
mailing list