On 3/15/18 3:36 PM, jmh530 wrote:
I recall some talk Andrei did where he said it was a bad idea to make
the allocator part of the type. However, the container library in
dlang-community(says it is backed with std.experimental.allocator)
contains allocator as part of the type. Automem does too. Honestly, I
would think you would really be hobbled if you didn't. For instance, if
you want to expand a DynamicArray using the built-in ~= operator, then
you really need to know what the allocator is. Without ~= you'd have to
rely on functions (maybe member functions, maybe not).
So I suppose I'm wondering why is it a bad thing to include the
allocator as part of the type and why is it that it seems like in
practice that's how it is done anyway.
I don't know if I've heard Andrei talk about that, but I definitely have
made it part of the type for types that need to allocate. The only other
possibility is to accept and use an Allocator object (i.e. the interface).
I suppose the main reason you may want to not make it part of the type
is if you want to compare/assign two types built with different
allocators. But then I don't know why you would want to do that.
But I just thought of this too -- maybe he said you should make it a
part of the struct itself? That is, you shouldn't make the allocator a
member, but the allocator itself can be part of the type?
Not sure.
-Steve
