Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

C++ Design Pattern for allocator type arguments

The C++03 standard library uses simple template type arguments when passing a type to a class which is meant to be an allocator. This is possible because of how templates work in C++. However, it isn't very straightforward and you might don't know what exactly the type definition should look like - especially in case of non standard types.

I thought it might be a good idea to use adaptor classes instread. I've created an example to show you what I mean:

#ifndef HPP_ALLOCATOR_ADAPTOR_INCLUDED
#define HPP_ALLOCATOR_ADAPTOR_INCLUDED


#include <memory>


template<typename T>
struct allocator_traits;

template<typename T, class allocator_type = std::allocator<T>>
class allocator_adaptor;


template<>
struct allocator_traits<void>
{
    typedef std::allocator<void>::const_pointer const_pointer;
    typedef std::allocator<void>::pointer       pointer;
    typedef std::allocator<void>::value_type    value_type;
};

template<typename T>
struct allocator_traits
{
    typedef typename std::allocator<T>::const_pointer   const_pointer;
    typedef typename std::allocator<T>::const_reference const_reference;
    typedef typename std::allocator<T>::difference_type difference_type;
    typedef typename std::allocator<T>::pointer         pointer;
    typedef typename std::allocator<T>::reference       reference;
    typedef typename std::allocator<T>::size_type       size_type;
    typedef typename std::allocator<T>::value_type      value_type;
};


template<class allocator_type>
class allocator_adaptor<void, allocator_type>
    : public allocator_traits<void>
{
public:
    template<typename U> struct rebind { typedef allocator_adaptor<U, allocator_type> other; };
};

template<typename T, class allocator_type>
class allocator_adaptor
    : public allocator_traits<T>
{
private:
    allocator_type m_impl;

public:
    template<typename U> struct rebind { typedef allocator_adaptor<U, allocator_type> other; };

    allocator_adaptor() throw() /*noexcept*/;
    allocator_adaptor(allocator_adaptor const&) throw() /*noexcept*/;
    allocator_adaptor(allocator_type const&) throw() /*noexcept*/;
    template<typename U> allocator_adaptor(allocator_adaptor<U, allocator_type> const&) throw() /*noexcept*/;
    ~allocator_adaptor() throw();

    pointer       address(reference x) const /*noexcept*/;
    const_pointer address(const_reference x) const /*noexcept*/;

    pointer   allocate  (size_type, allocator_traits<void>::const_pointer hint = 0);
    void      deallocate(pointer p, size_type n) /*noexcept*/;
    size_type max_size  () const throw() /*noexcept*/;

    template<class U, typename... argument_types> void construct(U* p, argument_types&&... args);
    template<class U> void destroy(U* p);
};


#endif /* HPP_ALLOCATOR_ADAPTOR_INCLUDED */

The implemention should be obvious. Here's some usage example.

template<class allocator_type>
int max_size(allocator_type const& alloc)
{
    // we don't know what kind of max_szie function will be called.
    return alloc.max_size();
}

template<typename T>
int max_size(allocator_adaptor<T> const& alloc)
{
    // we know what kind of max_size function will be called.
    return alloc.max_size();
}

is this an improvement compared to the usual way?

like image 394
0xbadf00d Avatar asked Nov 13 '22 21:11

0xbadf00d


1 Answers

Actually your point here is to introduce a construct member which is based on variadic arguments and allows you to write instead of:

typedef std::allocator<T> my_alloc;
my_alloc alloc;
my_alloc::pointer p = alloc.allocate(10);
alloc::construct(p, T(param1, param2, param3));
alloc::construct(p+1, T(param1, param2, param3));
//...

some easier form:

alloc::construct(p, param1, param2, param3);
alloc::construct(p+1, param1, param2, param3);

This seems to be a nice feature. On the other hand, you move all the initialization parameters, which will prohibit the proper initialization of the p+1 object. What if I want to repeat the initialization for the same parameters for multiple objects. I think your current approach will fail (and unfortunately not at compile-time).

like image 199
ovanes Avatar answered Dec 26 '22 01:12

ovanes