Idea #1 on integrating RC with GC

[Adam D. Ruppe]

On Wednesday, 5 February 2014 at 19:39:43 UTC, Andrei 
Alexandrescu wrote:
> You do figure that complicates usage considerably, right?

I don't see much evidence for that. Many, many newer modules in 
Phobos are currently allocation free yet still pretty easy to use.

A major source of little allocations in my code is std.conv and 
std.string. But these aren't difficult to change to external 
allocation, in theory at least:

string s = to!string(50); // GC allocates (I'd keep this for 
convenience and compatibility)

char[16] buffer;
char[] s = toBuffer(buffer[], 50); // same thing, using a buffer

char[] s = toLowerBuffer(buffer[], "FOO");
assert(buffer.ptr is s);
assert(s == "foo");


That's not hard to use (though remembering that s is a borrowed 
reference to a stack buffer might be - escape analysis is 
something we should really have).

And it gives full control over both allocation and deallocation. 
It'd take some changes in phobos, but so does the RCSlice sooo 
yeah, and this actually decouples it from the GC.

The tricky part might be making it work with buffers, growable 
buffers, sink functions, etc., but we've solved similar problems 
with input ranges.


> I was thinking RCSlice would be a better alternative.

I very rarely care about when little slices are freed. Large 
blocks of memory might be another story (I've used malloc+free 
for a big internal buffer in my png.d after getting memory leaks 
from false poitners with teh gc) but those can be handled on a 
case by case basis. std.base64 for example might make sense to 
return one of these animals.

I don't have a problem with refcounting on principle but most the 
time, it just doesn't matter.