测试类型是否是分配器的正确方法是什么？答案

【问题标题】：what is the correct way to test if a type is an allocator?测试类型是否是分配器的正确方法是什么？
【发布时间】：2019-01-23 13:49:33
【问题描述】：

在 SFINAE 上下文中编写 allocator_traits<T>::value_type 似乎是测试 T 类型是否实际上是分配器的可行方法。然而，这并不是特别优雅，过去我一直被角落案例所困扰。

因此我的问题是：如果 T 是分配器而 ::false 否则如何最好地实现包含 ::value 为 true 的 is_allocator<T> 特征？

【问题讨论】：

但是什么是分配器是？ :) 分配器是我们用户定义的概念，不是语言定义的。换句话说，你会用分配器做什么而你不会用其他类型做？换句话说，分配器有非常具体的用途。我发现很难想象这样一种场景，如果特定类型是分配器，则可以将其用作分配器，或者在不是分配器时以其他方式使用。换句话说，它是 XY 问题吗？
你可以检查它是否有分配功能。
@NathanOliver 是的，但是，我相信具有成员函数 allocate 但没有 ::value_type 且没有 allocator_traits 特化的类型不是分配器
@SergeyA 我同意显然只能检查 publich 接口语法，而不是对实现的期望。然而，这是一个超级通用的上下文，我只想验证一个类型是否支持分配器的语法要求。
@odinthenerd 因为我相信，没有其他选择（即当它在分配器上下文中使用时，它应该是一个分配器）我会说，只是接口。如果碰巧错过了函数或类型，则会产生编译器错误。这是我能给出的最好建议。

【解决方案1】：

在 SFINAE 上下文中编写 allocator_traits<T>::value_type 似乎是测试 T 类型是否实际上是分配器的可行方法。

我认为这还不够。这只会检查T 是否有value_type 并且可以重新绑定。 libstdc++ 和 libc++ 都将std::map<int, int> 视为该模型中的分配器。

标准中有a table of requirements 用于构成Allocator。我认为您最好的选择是检查几个表达式的有效性，即：

（其中X 是您要检查的类型，a 是X&，n 是allocator_traits<X>::size_type 类型的值）

如果有一种类型可以检查所有这些框并且仍然不是 allcoator，那么...¯\_(ツ)_/¯。

【讨论】：