Am 02.02.2014 10:03, schrieb Martin Cejp:
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.
The problem with C++ is the C traps that live within and are the cause
of many C++ gotchas, as described by Bjarne on the "The Design and
Evolution of C++" book.
--
Paulo
