Re: [boost] [circular_buffer] some comments and suggestions
#1
yes, I agree the default capacity will be zero then. And I like the idea of assertion in push_back, insert...
I can change it in the trunk but I'm not sure I should chage it in the 1.35 release branch at this stage.
#2
Coud you show the example how do you want to get the special iterator?
#3
yes, it makes sense
Jan
----- Original Message ----
From: Thorsten Ottosen <thorsten.ottosen@dezide.com>
To: boost@lists.boost.org
Sent: Monday, 21 January, 2008 9:54:46 PM
Subject: Re: [boost] [circular_buffer] some comments and suggestions
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
_______________________________________________
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:
I can change it in the trunk but I'm not sure I should chage it in the 1.35 release branch at this stage.
yeah, we should probably leave the release branch alone, except for triviality.
#2 Coud you show the example how do you want to get the special iterator?
If I were to use the array_one() or array_two() functions, I would need to know which one that spanned the buffer given is_linearized() was true. (I pressume it would be array_one()). But, since the interface already exposes both normal and reverse iterators, it would be cool if it also worked for reverse iterators. In Boost.Iterator, the wrapped iterators are accessible as iter.base(), and I think it makes sense to reuse that scheme, just with a slightly different name. So if is_linearized() is true, the following efficient ranges could be valid: [begin().array_ptr(),end().array_ptr()) [rbegin().array_ptr(),rend().array_ptr()) -Thorsten
participants (2)
-
Jan Gaspar -
Thorsten Ottosen