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