Stewart, Robert escribió:
Andrew Sutton wrote: On Tuesday, June 09, 2009 9:07 AM
People will expect that a monotonic::foo<..> is like a foo<..>, and they will accept that it requires a storage argument. But they will find it harder to accept that it requires retooling from a type-argument level of the allocator.
Why incur the overhead of expectation, when foo<T, monotonic::allocator<T>> gives you exactly what you want?
There's a problem with using an allocator for the node based containers: they use the allocator to allocate the elements but not the nodes. That implies free store (de)allocations for the nodes which is contrary to the intended purpose of this proposal.
Umm, I beg to differ. If we have a node-based container xxx<T,...,custom_allocator<T> > and node<T> is the internal node type, the container is required to do the allocation using an allocator of type custom_allocator<T>::rebind<node<T> >::other. The container is not allowed to do any kind of allocation using other means than the custom_allocator<X> family of allocators. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
There's a problem with using an allocator for the node based containers: they use the allocator to allocate the elements but not the nodes. That implies free store (de)allocations for the nodes which is contrary to the intended purpose of this proposal.
Umm, I beg to differ. If we have a node-based container
xxx<T,...,custom_allocator<T> >
Right. Furthermore, if the node structure is (roughly): template <typename T> struct node { T data; node *prev, *next; }; How would you separate the allocation of node<T> and node<T>.data? Andrew Sutton andrew.n.sutton@gmail.com
Andrew Sutton wrote On Tuesday, June 09, 2009 9:41 AM
There's a problem with using an allocator for the node based containers: they use the allocator to allocate the elements but not the nodes. That implies free store (de)allocations for the nodes which is contrary to the intended purpose of this proposal.
Umm, I beg to differ. If we have a node-based container
xxx<T,...,custom_allocator<T> >
Right. Furthermore, if the node structure is (roughly):
template <typename T> struct node { T data; node *prev, *next; };
How would you separate the allocation of node<T> and node<T>.data?
template <typename T> struct node { T * data; node * prev; node * next; }; Even with yours, custom_allocator<T> is not the same as custom_allocator<node<T>>. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
How would you separate the allocation of node<T> and node<T>.data?
template <typename T> struct node { T * data; node * prev; node * next; };
Even with yours, custom_allocator<T> is not the same as
custom_allocator<node<T>>.
If you were going to design your list to require extra allocation and indirection, sure. Since (I believe that) none of the node-based structures in the std namespace directly allocate objects of type T, it's kind of a moot point. I think this discussion really gets to the heart of the complexity of allocation strategies for data structures that require nested, multi-type allocations. As this problem exists for all allocator types, I think it's way out of the scope of whether or not Christian should be duplicating all of the containers or simply introducing a new allocator type. Andrew Sutton andrew.n.sutton@gmail.com
joaquin@tid.es wrote: On Tuesday, June 09, 2009 9:34 AM
Stewart, Robert escribió:
There's a problem with using an allocator for the node based containers: they use the allocator to allocate the elements but not the nodes. That implies free store (de)allocations for the nodes which is contrary to the intended purpose of this proposal.
Umm, I beg to differ. If we have a node-based container
xxx<T,...,custom_allocator<T> >
and node<T> is the internal node type, the container is required to do the allocation using an allocator of type
custom_allocator<T>::rebind<node<T> >::other.
The container is not allowed to do any kind of allocation using other means than the custom_allocator<X> family of allocators.
If custom_allocator<node<T> > is not specialized to do the same as custom_allocator<T>, or to use the same memory pool, then it doesn't fit the proposal. It is possible that the primary specialization uses the free store and only specific specializations use the custom pool. Since you can't know the node type of a standard container, you can't specialize for it. Since the node is likely of a different size than the element type, the nodes cannot be put into the same pool as the elements, which greatly complicates using an allocator for the proposed purpose. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (3)
-
Andrew Sutton -
joaquin＠tid.es -
Stewart, Robert