Allocator Part of Type

[Steven Schveighoffer]

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