From: Nigel Stewart (nigels_at_[hidden])
Date: 2003-07-22 21:37:51
Oops, I stand corrected.
I had not understood the convention properly!
In a nutshell:
1. The capacity is preserved unless explicity
adjusted via set_capacity, or implicitly
changed by resize.
2. insert may cause front elements to be overwritten
3. rinsert may cause back elements to be overwritten
In this way, insert is related to push_back
in terms of semantics, and rinsert is related
Given that this could conceivably be swapped
around, do we have a rationale that we could
state in the documentation?
As the caveats:
Inserting to the front of a full buffer
would result in those front-most elements being
overwritten by the back-most. (No effect,
Reverse inserting to the back of a full buffer
would result in those back-most elements being
overwritten by the front-most. (No effect,
Jan Gaspar wrote:
> Hi Nigel,
> It cannot be done as you propose. Please check the archive.
> It can be done like this:
> cb.rinsert(cb.begin(), 2); // rinsert
> cb.push_front(2); // this is equivalent
> It will be documented and I think not everything can be driven by "the principle
> of least surprise".
>> > Inserting at the beginning or "close to the beginning"
>> > of the circular_buffer is another trap.
>> > boost::circular_buffer<int> cb(5, 1);
>> > cb.insert(cb.begin(), 2); // nothing will be inserted
>>The following should be exactly equivalent:
>> cb.insert(cb.begin(), 2);
>>As a proposed semantic:
>> Insertion to the front or back will always be
>> equivalent to a corresponding sequence of
>> push_front or push_back.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk