Re: [boost] [review] Review of PolyCollection starts today (May 3rd)

Subject: Re: [boost] [review] Review of PolyCollection starts today (May 3rd)
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-14 23:02:14

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.