On Sunday, 2 February 2014 at 05:12:05 UTC, Frank Bauer wrote:
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).
This exists. It's called C++.
I've pretty much given up on GC and do all my allocations in the
real-time path manually. In a game, there shouldn't be that much
stuff to allocate once live, anyway.
