开发者

C++0x allocators

开发者 https://www.devze.com 2023-04-01 01:46 出处:网络
I observed that my copy of MSVC10 came with containers that appeared to allow state based allocators, and wrote a simple pool allocator, that allocates pools for a specific type.

I observed that my copy of MSVC10 came with containers that appeared to allow state based allocators, and wrote a simple pool allocator, that allocates pools for a specific type. However, I discovered that if _ITERATOR_DEBUG_LEVEL != 0 the MSVC vector creates a proxy allocator from the passed allocator (for iterator tracking?), uses the proxy, then lets the proxy fall out of scope, expecting the allocated memory to remain. This causes problems because my allocator attempts to release it's pool upon destruction. Is this allowed by the C++0x standard?

The code is roughly like this:

class _Container_proxy{};

template<class T, class _Alloc>
class vector {
     _Alloc _Alval;
public: 
    vector() {
        // construct _Alloc<_Container_proxy> _Alproxy
         typename _Alloc::template rebind<_Container_proxy>::other 
                 _Alproxy(_Alval);
        //allocate
        this->_Myproxy = _Alproxy.allocate(1);
        /*other stuff, but no deallocation*/
    } //_Alproxy goes out of scope

    ~_Vector_val() {    // destroy proxy
        // construct _Alloc<_Container_proxy> _Alproxy
        typename _Alloc::template rebind<_Container_proxy>::other
                 _Alproxy(_Alval);
        /*stuff, but no allocation*/
        _Alproxy.deallocate(this->_Myproxy, 1);
    } //_Alproxy goes out开发者_运维百科 of scope again


According to the giant table of allocator requirements in section 17.6.3.5, an allocator must be copyable. Containers are allowed to copy them freely. So you need to store the pool in a std::shared_ptr or something similar in order to prevent deletion while one of the allocators is in existence.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号