對類AllocatorAwareContainer數據成員使用自定義分配器

給定一個非無狀態自定義分配器A（比如，競技場分配器，綁定到運行時已知大小的一些連續內存塊）和類S，其中包含AllocatorAwareContainer類型的文件夾：對類AllocatorAwareContainer數據成員使用自定義分配器

struct S 
{ 
    A() = default; 
    // another c-tors 
    std::vector<T> v; 
    std::shared_ptr<U> s; 
};

我想用A的一個子集（甚至全部）AllocatorAwareContainerS類的字段。很顯然，我應該爲S類提供彼此模板參數，改變類型的所有有趣的數據成員的相應如下：

template< typename A = std::allocator<void> > 
struct S 
{ 
    // c-tors 
    template< typename X > 
    using allocator = typename std::allocator_traits<A>::template rebind<X>::other; 
    std::vector< T, allocator<T> > v; 
    std::shared_ptr< U, allocator<U> > s; 
};

什麼是目前的構造變化和額外的構造函數（假設A不DefaultConstructible和任何其他可能的限制可能會成立）我應該嗎？

我應該將分配器A存儲在類S的其他字段嗎？

什麼是使用自定義分配器類的一般技巧？

來源

2015-10-05 Orient

我習慣於使用分配器感知的bsl容器和創建分配器感知類。標準容器及其分配器使用的主要區別是bsl使用指向分配器基類的指針（bslma::Allocator）。這種方法很好地擺脫了std::rebind-這使得事情複雜化已經比較複雜。否則，我認爲這些概念是翻譯的。我沒有使用分配器和標準庫容器的經驗。

有供其使用在實際工作以及分配器的兩個基本規則：

對象的分配也曾經建造不變化。
每個分配器感知類型應將作爲構造函數參數接收的分配器傳遞給所有分配器感知成員。

第二條規則意味着類的構造函數需要照顧他們所有的成員。在成員類型已知的情況下，確定是否需要分配器以及如何構造分配器是相當直接的。當成員類型是某種形式的泛型時，即它以某種形式依賴於模板參數時，通常不知道是否需要分配器。

當不清楚成員是否需要接收分配器時，使用bsl時使用的方法是容納一個被包裝的成員。更具體地說，成員將持有一個bslalg::ConstructorProxy<T>這將確定靜態與T支持構造函數採取分配器和適當通行證分配器或不。

來源

2015-10-05 11:09:30

會在這裏使用'std :: scoped_allocator_adaptor'嗎？ – legends2k

@ legends2k：這很有可能。但是，我沒有使用標準容器的分配器，所以我不知道。 –

@ legends2k對於'std :: scoped-allocator_adaptor'，應該有很多（部分）特殊化的'std :: uses_allocator '。 – Orient

對類AllocatorAwareContainer數據成員使用自定義分配器

回答

相關問題