On Thursday, 15 March 2018 at 21:43:41 UTC, Steven Schveighoffer
wrote:
[snip]
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
I first remember him saying it with respect to C++'s allocators
[1]. The C++ containers in std include the allocator as part of
the type. I don't really recall what the reasoning was. I also
recall him saying it with respect to automem [2].
Automem includes the allocator among the template variables and
then puts the allocator in an enum (Atila says it only takes up
space in certain situations). I think the containers library does
something similar, but with an alias if state size is 0 and as a
member otherwise.
[1]
https://github.com/CppCon/CppCon2015/blob/master/Presentations/allocator%20Is%20to%20Allocation%20what%20vector%20Is%20to%20Vexation/allocator%20Is%20to%20Allocation%20what%20vector%20Is%20to%20Vexation%20-%20Andrei%20Alexandrescu%20-%20CppCon%202015.pdf
[2] https://forum.dlang.org/post/ocden9$11s6$1...@digitalmars.com
