Idea #1 on integrating RC with GC

Johannes Pfau nospam at example.com
Wed Feb 5 12:45:50 PST 2014


Am Wed, 05 Feb 2014 20:18:33 +0000
schrieb "Adam D. Ruppe" <destructionator at gmail.com>:

> 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");
> 
> 

I think using a template parameter to allow for all kinds of allocators
(std.allocator) is better. But of course it should have zero-overhead
for a static-buffer allocator. Or we just special case static buffers
_and_ add allocators ;-)

But as Andrei said that discussion is not part of this thread.



The main reason for RCSlice is not returning from Phobos functions, it's
passing slices to Phobos functions.

You can always create a RCSlice!string with any kind of string and as
Andrei wants them GC-backed anyway, you can just create the
RCSlice!string after the function returned a GC allocated string. (As
long as the function doesn't keep a reference)

But if we pass a RCd slice to a phobos function as a normal string,
we'd have to stop reference counting. While this doesn't matter for
GC-backed slices it basically means that manually allocated slices would
never be freed.

However, I wonder if that's really a problem in phobos. I'd guess most
functions accepting slice input don't store a reference. We should
probably start documenting that. (Or finish 'scope' as you already
said implicitly ;-). 


More information about the Digitalmars-d mailing list