Smart pointers instead of GC?

Frank Bauer y at z.com
Sat Feb 1 21:12:04 PST 2014


On Sunday, 2 February 2014 at 04:23:35 UTC, Adam Wilson wrote:
> Maybe, but my point is that even with no allocations in phobos, 
> you'd have to verify that ALL the libraries you use don't GC 
> allocate. That's why so many people in the ARC camp want to 
> make it the only GC system in D. Multiple GC systems increase 
> your cognitive load considerably.

Good point. What we DON'T want is a library that comes in 
MySuperLib-GC, MySuperLib-ARC, MySuperLib-Owning and 
MySuperLib-Borrowed flavors.

But I don't think that is necessary.

A library function would typically take arguments by reference 
aka as a Borrowed(T). GC(T), ARC(T) and Owning(T) convert equally 
well to Borrowed(T). So somebody who uses only GC(T) in her code 
could use the library just as easily as someone who prefers 
Owning(T). The library would be compatible with the two, because 
it does not own the (reference to the) passed object. GC(T) or 
Owning(T) at the call site would free the object automatically 
(at the next collection cycle or when leaving the scope). 
Everybody is happy!

All that is left for the caller is to choose whether she wants to 
use a library that uses GC *internally*. Interaction is possible 
in every combination:

1. I use GC(T),     the library uses GC(T) internally     -> 
works (with GC),
2. I use Owning(T), the library uses GC(T) internally     -> 
works (with GC),
3. I use GC(T),     the library uses Owning(T) internally -> 
works (with GC),
4. I use Owning(T), the library uses Owning(T) internally -> 
works (w/o GC).


More information about the Digitalmars-d mailing list