Smart pointers instead of GC?

Paulo Pinto pjmlp at progtools.org
Sun Feb 2 06:25:54 PST 2014


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


More information about the Digitalmars-d mailing list