Am Tue, 13 Sep 2016 18:16:27 +0000 schrieb Laeeth Isharc <laeethnos...@nospamlaeeth.com>:
> Thanks you for the clear explanation. So if you don't have GC > allocations within RC structures and pick one or the other, then > the concern does not apply? That's right. Often such structures contain collections of things, not just plain fields. And a list or a hash map working in a @nogc environment typically checks its contained type for any pointers with hasIndirections!T and if so adds its storage area to the GC scanned memory to be on the safe side. That means every collection needs a way to exempt its contents from GC scanning and the user needs to remember to tell it so. A practical example of that are the EMSI containers, but other containers, i.e. in my own private code look similar. https://github.com/economicmodeling/containers struct DynamicArray(T, Allocator = Mallocator, bool supportGC = shouldAddGCRange!T) { ... } Here, when you use a dynamic array you need to specify the type and allocator before you get to the point of opting out of GC scanning. Many will prefer concise code, go with GC scanning to be "better safe than sorry" or don't want to fiddle with the options as long as the program works. This is no complaint, I'm just trying to draw a picture of how people end up with more GC scanned memory than necessary. :) -- Marco