KroMignon / angleproject

Automatically exported from code.google.com/p/angleproject
Other
0 stars 1 forks source link

pool_allocator<void> does not compile #932

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
According to std library requirements, allocators must support <void>. 
pool_allocator<void> does not compile. Please add

template<>
class pool_allocator<void> {
public:
    typedef void* pointer;
    typedef const void* const_pointer;
    typedef void value_type;

    template<class Other>
    struct rebind {
        typedef pool_allocator<Other> other;
    };

    pool_allocator() : allocator(GetGlobalPoolAllocator()) { }
    pool_allocator(TPoolAllocator& a) : allocator(&a) { }
    pool_allocator(const pool_allocator<void>& p) : allocator(p.allocator) { }

    template <class Other>
    pool_allocator<void>& operator=(const pool_allocator<Other>& p) {
        allocator = p.allocator;
        return *this;
    }

    template<class Other>
    pool_allocator(const pool_allocator<Other>& p) : allocator(&p.getAllocator()) { }

    bool operator==(const pool_allocator& rhs) const { return &getAllocator() == &rhs.getAllocator(); }
    bool operator!=(const pool_allocator& rhs) const { return &getAllocator() != &rhs.getAllocator(); }

    size_t max_size(int size) const { return static_cast<size_t>(-1) / size; }

    void setAllocator(TPoolAllocator* a) { allocator = a; }
    TPoolAllocator& getAllocator() const { return *allocator; }

protected:
    TPoolAllocator* allocator;
};

Original issue reported on code.google.com by arnoscho...@gmail.com on 27 Feb 2015 at 4:48

GoogleCodeExporter commented 9 years ago

Original comment by shannonw...@chromium.org on 27 Feb 2015 at 10:41

GoogleCodeExporter commented 9 years ago
Hi Arno. What are the symptoms of not having support for pool_allocator<void>? 
Your suggestion seems like a lot of code for something we never needed and will 
probably never use. Also, we're considering to rewrite the compiler's 
allocations using unique_ptr or similar approach which is less prone to leaks 
and more thread safe.

Original comment by c...@chromium.org on 12 Mar 2015 at 2:19