On 3/15/18 6:30 PM, jmh530 wrote:
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.
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
Looks like what he means is that the allocator in C++ includes the type
as part of it's makeup. That's not the same thing. But it's hard to tell
from just a bunch of slides.
[2] https://forum.dlang.org/post/ocden9$11s6$1...@digitalmars.com
This does seem to suggest he thinks the idea is not good. I can't think
of an alternative that doesn't store the allocator as a member (if you
intend to use different allocators with different variables).
However, there is some further conversation on that from Martin Nowak
that may shed some light on the "anti-pattern" and what it really means.
Personally, I think you HAVE to have some sort of reference to an
allocator if you want custom allocation support in a container type. The
only other alternative is making the user of the type remember which
allocator the type needs to dealloacte and pass the allocator along when
doing memory management tasks. Seems horrible.
-Steve
