[interprocess][circular_buffer] specialized containers should have container template argument
Hi Ion and Jan, I often use these containers: flat_set, flat_map and circular_buffer. They are great. However, we can make them faster if you allow a new template argument. For example template < class T, class Alloc, class Buffer = /* some default */
class circular_buffer; template < typename T, typename Pred, typename Alloc class PushBackContainer = /* some default */
class flat_set; My motivation is that these can perform somewhat better e.g. with an array (for circular_buffer), or auto_buffer (for flat_set/flat_map). I think even some very simply array wrapper would be useable with flat_set. The EA STL implementation has this features. What do you think? -Thorsten
Hi Thorsten, I'm sorry but I don't have time for this. I can still do circullar_buffer bug fixing and maintenance but have no time for new development as my priorities have changed. Thank you for understanding. Regards, Jan ----- Original Message ---- From: Thorsten Ottosen <thorsten.ottosen@dezide.com> To: "boost@lists.boost.org" <boost@lists.boost.org> Sent: Friday, 1 May, 2009 10:44:09 Subject: [boost] [interprocess][circular_buffer] specialized containers should have container template argument Hi Ion and Jan, I often use these containers: flat_set, flat_map and circular_buffer. They are great. However, we can make them faster if you allow a new template argument. For example template < class T, class Alloc, class Buffer = /* some default */
class circular_buffer; template < typename T, typename Pred, typename Alloc class PushBackContainer = /* some default */
class flat_set; My motivation is that these can perform somewhat better e.g. with an array (for circular_buffer), or auto_buffer (for flat_set/flat_map). I think even some very simply array wrapper would be useable with flat_set. The EA STL implementation has this features. What do you think? -Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jan Gaspar skrev:
Hi Thorsten,
I'm sorry but I don't have time for this. I can still do circullar_buffer bug fixing and maintenance but have no time for new development as my priorities have changed.
Thank you for understanding.
No problem. Maybe we should try to find a new maintainer also. regards -Thorsten
Thorsten Ottosen wrote:
However, we can make them faster if you allow a new template argument. For example template < typename T, typename Pred, typename Alloc class PushBackContainer = /* some default */
class flat_set;
My motivation is that these can perform somewhat better e.g. with an array (for circular_buffer), or auto_buffer (for flat_set/flat_map). I think even some very simply array wrapper would be useable with flat_set.
Interesting, but it seems that PushBackContainer and Allocator overlap. auto_buffer is basically an allocator. But flat_xxx could be implemented in any sequence container with random-access iterators (we need them for binary search), so maybe it could be interesting to have more generic classes like map_sequence<>, set_sequence (names are horrible I know, but it's just an example): template<class Sequence> class set_sequence; set_sequence<vector<T>> set_sequence<deque<T>> or something more similar to std::queue: template<class T, class Sequence> class set_sequence; Anyway, my opinion is that we should only use a minimal interface for Sequence ((r/c)begin,(r/c)end, insert, erase, clear()). Another option would be something like: template< class T , class Allocator , class Sequence = vector<T, A> > flat_set; and we should require (as we require for allocator::value_type) that Sequence::value_type is T and Sequence::allocator_type is Allocator.
The EA STL implementation has this features.
I will look at this. Is there any public
What do you think?
These days I don't have much time and I have other improvements with higher priority but I will add to the to-do list. Thanks, Ion
Ion Gaztañaga skrev:
Thorsten Ottosen wrote:
However, we can make them faster if you allow a new template argument. For example template < typename T, typename Pred, typename Alloc class PushBackContainer = /* some default */
class flat_set;
My motivation is that these can perform somewhat better e.g. with an array (for circular_buffer), or auto_buffer (for flat_set/flat_map). I think even some very simply array wrapper would be useable with flat_set.
Interesting, but it seems that PushBackContainer and Allocator overlap.
Right. But see below.
auto_buffer is basically an allocator. But flat_xxx could be implemented in any sequence container with random-access iterators (we need them for binary search), so maybe it could be interesting to have more generic classes like map_sequence<>, set_sequence (names are horrible I know, but it's just an example):
template<class Sequence> class set_sequence;
set_sequence<vector<T>> set_sequence<deque<T>>
or something more similar to std::queue:
template<class T, class Sequence> class set_sequence;
Anyway, my opinion is that we should only use a minimal interface for Sequence ((r/c)begin,(r/c)end, insert, erase, clear()).
I think you only need: begin() [const and non-const] end() [ditto] insert() erase() [clear will be defined in terms of erase]
Another option would be something like:
template< class T , class Allocator , class Sequence = vector<T, A> > flat_set;
and we should require (as we require for allocator::value_type) that Sequence::value_type is T and Sequence::allocator_type is Allocator.
Right on. We currently have: template< class T , class Allocator , class Pred
flat_set; So just do template< class T , class Allocator , class Pred , class Sequence = vector<T, Allocator> > flat_set;
The EA STL implementation has this features.
I will look at this. Is there any public
Don't think so. It's described in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
What do you think?
These days I don't have much time and I have other improvements with higher priority but I will add to the to-do list.
Thanks ... it doesn't have high priority. -Thorsten
I've used circular buffer. IMHO, the best interface would be template<class T> class circular_buffer { circular_buffer(RandomAcccessIterator<T> start, RandomAccessIterator<T> end); }; Robert Ramey Ion Gaztañaga wrote:
Thorsten Ottosen wrote:
However, we can make them faster if you allow a new template argument. For example template < typename T, typename Pred, typename Alloc class PushBackContainer = /* some default */
class flat_set;
My motivation is that these can perform somewhat better e.g. with an array (for circular_buffer), or auto_buffer (for flat_set/flat_map). I think even some very simply array wrapper would be useable with flat_set.
Interesting, but it seems that PushBackContainer and Allocator overlap. auto_buffer is basically an allocator. But flat_xxx could be implemented in any sequence container with random-access iterators (we need them for binary search), so maybe it could be interesting to have more generic classes like map_sequence<>, set_sequence (names are horrible I know, but it's just an example):
template<class Sequence> class set_sequence;
set_sequence<vector<T>> set_sequence<deque<T>>
or something more similar to std::queue:
template<class T, class Sequence> class set_sequence;
Anyway, my opinion is that we should only use a minimal interface for Sequence ((r/c)begin,(r/c)end, insert, erase, clear()).
Another option would be something like:
template< class T , class Allocator , class Sequence = vector<T, A> > flat_set;
and we should require (as we require for allocator::value_type) that Sequence::value_type is T and Sequence::allocator_type is Allocator.
The EA STL implementation has this features.
I will look at this. Is there any public
What do you think?
These days I don't have much time and I have other improvements with higher priority but I will add to the to-do list.
Thanks,
Ion _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Ion Gaztañaga -
Jan Gaspar -
Robert Ramey -
Thorsten Ottosen