On 13/05/2017 12:50, Glen Fernandes wrote:
What do you want to know?
1. The storage for the node should be allocated with the Allocator's 'allocate()', for an allocator instance 'a' whose value_type is the containers node type (i.e. 'a' can be achieved by rebinding an existing allocator instance in the normal way).
2. The node object itself would be constructed in the normal way - e.g. placement new to construct the node object.
3. The containers' value_type object within the node must be constructed by allocator_traits<U>::construct(u, p, args...) where u of type U is a rebound copy of the allocator such that the allocator's value_type is the container's value_type.
4. Similar to 3, for destruction of the container's value_type object should be destroyed by allocator_traits<U>::destroy(u, p)
5. Similar to 2, the node object is destroyed in the normal way - e.g. invoking the destructor of the node type.
Yeah, that's what it sounded like it said. But those rules seem very peculiar to me. Why wouldn't you use allocator_traits<node>::construct to construct the node type as well instead of using placement new directly? That way you only ever need one allocator instance, that for the node type. Why is it sensible to call allocate with a different type than construct, if the reason to not call construct is to avoid leaking the node type externally? In particular, these rules seem to basically require that the node type be trivially-constructible, because you can't legally call the node constructor and then call the value constructor where the value is a field of the node; you'd have to construct the node, destroy the value, then re-construct the value, which seems well over the line into crazypants territory. It all seems very arbitrary to me.