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


Reply via email to