Hi Jonathan
Thank you very much for your reply
However I think there has been a misunderstanding.
In the code of stl_tree.h we find the following two functions to
create and destroy nodes
363 _Link_type
364 _M_create_node(const value_type& __x)
365 {
366 _Link_type __tmp = _M_get_node();
367 try
368 { GET_ALLOCATOR().construct(&__tmp->_M_value_field, __x); }
369 catch(...)
370 {
371 _M_put_node(__tmp);
372 __throw_exception_again;
373 }
374 return __tmp;
375 }
387 void
388 _M_destroy_node(_Link_type __p)
389 {
390 GET_ALLOCATOR().destroy(&__p->_M_value_field);
391 _M_put_node(__p);
392 }
350 allocator_type
351 get_allocator() const
352 { return allocator_type(_M_get_Node_allocator()); }
//calls templated copy constructor in allocator.
353
Why is get_allocator() being called EVERY TIME construct_node and
destroy_node are called? Couldn't the output of get_allocator() be
stored in a pointer and be used for future construct_node destroy_node
calls?
On Thu, Aug 29, 2013 at 12:52 PM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote:
> On 29 August 2013 05:17, Umara Dissanayake wrote:
>> Hi,
>>
>> I have noticed in my development of a customized allocator for maps
>> that the library calls the templated copy constructor in the allocator
>> class each and every time the map is accessed (ex - through
>> operator[])
>
> Not every time it's accessed, only when creating/destroying nodes.
>
>> I understand that the templated copy constructor needs to be called to
>> get an allocator which can handle memory requests for Rb_Tree_Nodes.
>> What puzzles me is why this conversion couldn't be done once and the
>> resulting node allocator be used thereon after without converting the
>> allocator each and every time - which could be a hit on performance.
>
> The map needs to use Alloc<_Rb_tree_node> to allocate memory for a
> node, but it needs Alloc<value_type> to construct the element in the
> node, so the map either needs to store an instance of both
> specializations or it needs to store one and rebind it to get an
> instance of the other specialization as needed.
>
> However I have reported a defect against the standard regarding that
> requirement, see http://cplusplus.github.io/LWG/lwg-active.html#2218
> In C++11 mode my proposed change would allow the allocator to store an
> instance of Alloc<_Rb_tree_node> and to also use that same instance
> for constructing elements.
