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