Re: [boost] [circular_buffer] some comments and suggestions
#1 I don't agree. I tried to design the circular_buffer as close as possible to the other std containers. Suppose the cirular_buffer does not allocate anything on construction - this means when you insert an element to the buffer, it will not be inserted because the capacity is 0. I think this is unnatural for std containers. On the other hand there is a note in the documentation that you should avoid using this constructor: "This constructor has been defined only due to compatibility with the STL container definition. Avoid using it because it may allocate very large amount of memory." #2 Agree with is_linearized(), I don't agree with special iterator - I cannot see the point - just use pointers as you mentioned. #3 Yes, maybe in the next version. What would be the method signature? Regards, Jan ----- Original Message ---- From: Thorsten Ottosen <thorsten.ottosen@dezide.com> To: "boost@lists.boost.org" <boost@lists.boost.org> Sent: Monday, 21 January, 2008 11:40:23 AM Subject: [boost] [circular_buffer] some comments and suggestions Hi Jan, #1 I was browsing through the docs in trunk. First I noticed that the default constructor has the follwoing postcondition: capacity() == max_size() && size() == 0 I find that somewhat unfortunate that it allocates a huge amount of memory. It seems to me that it is too easy to do that by coincidence. The usual rule for std containers is to never allocate by default and anticipate a call to reserve() or the first element. It also seems to me that this will create problems when the container is used in containers that might use default construction. #2 I think it would be useful to add a predicate called is_linearized(), so one can check if this property holds. Also, if this do hold, I should be able the get fast iterators to this linear segment, perhaps by calling .base() on the iterators which then simply return a pointer (I know I can get the pointers by array_one(), but I would more often need the iterators). #3 I think it would be useful to add rotate() as a member function. AFAICT, it can in many times (if not all) be much faster than std::rotate() because it can simply move a few elements and then simply adjust the iterators. -Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com
Jan Gaspar skrev:
> #1
> I don't agree. I tried to design the circular_buffer as close as possible to the other std containers.
> Suppose the cirular_buffer does not allocate anything on construction
- this means when you insert an element to the buffer, it will not be
inserted because the capacity is 0.
> I think this is unnatural for std containers. On the other hand there
is a note in the documentation that you should
>avoid using this constructor: "This constructor has been defined only
due to compatibility with the STL container definition. Avoid using it
because it may allocate very large amount of memory."
My point is that you cannot always control the use of the default
constructor ... libraries call it now and then, and it pretty much
renders circular_buffer unusable with those libraries.
Insertion is already different for circular_buffer, so I don't think it
is that important that push_back() does not insert anything. Instead,
add an assertion check to all insertion function that the capacity is >
0, and specify this as a precondition to all those functions.
> #2
> Agree with is_linearized(), I don't agree with special iterator - I cannot see the point - just use pointers as you mentioned.
Right, but I would prefer an easy, idiomatic way to get those pointers.
> #3
> Yes, maybe in the next version. What would be the method signature?
I guess this would be handy:
void rotate( const_iterator newBegin );
precondition: newBegin in [begin(),end()).
if we added a new overload taking three iterator arguments like,
std::rotate(), I think it might not yield any performance improvement
over the std::version.
-Thorsten
participants (2)
-
Jan Gaspar -
Thorsten Ottosen