5

std::allocator_traits works its magic automatically when I provide an STL-style container with an allocator that has a single template parameter but it doesn't when I provide an STL-style container with an allocator that has two template parameters but is otherwise similar.

What do I need to do to tell std::allocator_traits how to interact with an allocator that has more than one template parameter? Is it possible to get std::allocator_traits to provide reasonable defaults in this case?

As an example, if I take the simple allocator Howard Hinnant provides in Allocator Boilerplate and feed it to a std::vector<> then all is well. If I add a dummy int parameter to the allocator template (and make slight modifications as needed) then I get compiler errors because the compiler couldn't find rebind, among other things.

Here's that description in code:

http://coliru.stacked-crooked.com/a/173c57264137a351

If I have to specialize std::allocator_traits myself in this case, is there a way to still get the defaults?

Praxeolitic
  • 22,455
  • 16
  • 75
  • 126
  • @bolov I want `std::allocator_traits` to fill in most of the details for me though. Is there any advantage to specializing `std::allocator_traits` vs completing the allocator concept without it? – Praxeolitic Jan 18 '16 at 18:20
  • @bolov that is not recommended, just provide your own `rebind` in the allocator, see my anwer. – TemplateRex Jan 18 '16 at 20:21
  • Start un-commenting some of the things in "Allocator Boilerplate" to fix the compile-time errors. Of course you'll have to do more than uncomment, you'll have to make whatever you do uncomment consistent with your allocator. Start with `rebind`. That may be the only other thing you have to not default, which would be a lot easier than specializing `allocator_traits`. – Howard Hinnant Jan 18 '16 at 21:31
  • @HowardHinnant curiuously, libc++ does compile with the OP's example, whereas libstdc++ doesn't. Do you know/remember what libc++ does for allocators with non-type extra parameters (I glanced at the source, but it seemed like only the regular `Alloc` was being matched. – TemplateRex Jan 18 '16 at 21:51
  • 1
    @TemplateRex: My best guess is that libc++'s `vector` doesn't bother calling `rebind`. The OP's example will likely fail with another container that must call `rebind`. – Howard Hinnant Jan 18 '16 at 21:56
  • @HowardHinnant just checked, with `std::list` instead of `std::vector`, libc++ also doesn't compile. See also [this Q&A](http://stackoverflow.com/a/15225165/819272) where @JonathanWakely explains libstdc++ practice of always going through `rebind`. – TemplateRex Jan 18 '16 at 23:03
  • 2
    @TemplateRex: Yeah, libc++ actively rejects the idea that accepting/compiling `vector>` is doing the client a favor. libc++ goes out of its way to notify the client asap if there is a mismatch like this between the allocator and container: https://github.com/llvm-mirror/libcxx/blob/master/include/vector#L479-L480 The motivation for this behavior is because program logic may depend on two independently declared containers having the same type. And if their type differs only by accidentally misdeclared allocators, best to know at compile time, asap. – Howard Hinnant Jan 19 '16 at 00:50
  • Fwiw, I learned this lesson years before while developing the CodeWarrior std::lib. – Howard Hinnant Jan 19 '16 at 00:54

1 Answers1

8

The Standard only provides a default rebind for allocators with multiple template type parameters:

17.6.3.5 Allocator requirements [allocator.requirements]

3 Note A: The member class template rebind in the table above is effectively a typedef template. [ Note: In general, if the name Allocator is bound to SomeAllocator<T>, then Allocator::rebind<U>::other is the same type as SomeAllocator<U>, where SomeAllocator<T>::value_type is T and SomeAllocator<U>:: value_type is U. — end note ] If Allocator is a class template instantiation of the form SomeAllocator<T, Args>, where Args is zero or more type arguments, and Allocator does not supply a rebind member template, the standard allocator_traits template uses SomeAllocator<U, Args> > in place of Allocator:: rebind<U>::other by default. For allocator types that are not template instantiations of the above form, no default is provided.

Since you have a non-type (int) parameter, there is no default provided. The fix is simple: just add your own rebind to your allocator.

template<class T, int I>
class allocator_w_int
{
    // as before

    template<class U>
    struct rebind { using other = allocator_w_int<U, I>; };    
};

Live Example

As to the rationale of allowing for allocators of the form Allocator<T, Args...> but not for allocators of the form Alloc<T, Ns...>, one can only guess, but then it would also lead to the plethora of Alloc<T, Args.., Ns...> etc. etc.. This is why template-metaprogramming libraries (such as Boost.MPL) always wrap their non-type parameters N of type T inside things like integral_constant<T, N>. This would also be a route for you, by defining 

template<class T, class Arg>
class allocator_w_int; // leave undefined

template<int N>
using int_ = std::integral_constant<int, N>;

template<class T, int I>
class allocator_w_int<T, int_<I>>
{
    // replace all occurances of I, J --> int_<I>, int_<J>
};

Live Example

TemplateRex
  • 69,038
  • 19
  • 164
  • 304