Re: [boost] Re: circular_buffer ver. 3.3 [long]
? I don't know yet. I have to admit that I read the article about the mojo technique just briefly. I will let you know when I decide. Jano -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5930-0735 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] circular_buffer ver. 3.3
Hi all!
Another beast was born. You can find it at
http://groups.yahoo.com/group/boost/files/circular_buffer.zip
New features:
- Added circular_buffer_space_optimized adaptor + documentation.
- Introduced circular_bufferT::data() method.
- Updated documentation (including source code documentation).
- Bug fixes.
Some comments:
1. IMO the macro based exception handling isn't needed, it is better
to use RAII, like:
...
can be replaced by:
void set_capacity(size_type new_capacity) {
if (new_capacity == capacity()) return;
pointer buff = allocate(new_capacity);
struct deleter_t {
pointer data;
size_type capacity;
deleter_t(pointer p, size_type s) : data(p), capacity(s) {}
~deleter_t() { deallocate(data, capacity); }
};
deleter_t guard(buff, new_capacity);
size_type new_size = new_capacity size() ? new_capacity : size();
std::uninitialized_copy(end() - new_size, end(), buff);
destroy();
m_size = new_size;
m_buff = m_first = buff;
m_end = m_buff + new_capacity;
m_last = full() ? m_buff : m_buff + size();
guard.data = 0;
}
I think this is not a good idea because
- it won't work - the ~deleter_t() destructor does not have access to
the deallocate() method
- the original macros are more explanatory (it is easier to understand)
- every STL implementation is using such macros
-
I tried (Intel 7):
circular_buffer aa(10);
aa.assign(3, 1.0);
and got error:
I think it should already compile for both Intel and Borland.
Internal checks: maybe something like this can be used:
Done.
Small note: the source code contains some tabs. Boost requirement is to use
spaces only.
I forgot. Now should be everything OK.
S pozdravom,
Jano
P.S. I will be on holiday next week.
--
Jan Gaspar | [EMAIL PROTECTED]
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel +421(2)5930-0735 | Fax +421(2)5443-5512
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: circular_buffer update
Hi Pavel,
I agree with most of your comments.
2. in function cb_iterator::operator -(), shouldn't it be std::less instead
of less? (actually I do not see why isn't enough here).
I call less() just because efficiency reasons. If I called operator it would
result in unnecessary calls to create_internal_iterator().
5. Similarly in circular_buffer::allocate(). (I wonder where
std::length_error
does come from?)
The STL delivered with MSVC7 does it like this. In your opinion what should it
throw?
Once again unused space overhead. What about this adaptor?
template class T class Adaptor {
public:
typedef typename circular_bufferT::iterator iterator;
typedef typename circular_bufferT::size_type size_type;
private:
size_type m_final_capacity;
circular_bufferT m_buff;
public:
Adaptor(size_type capacity) : m_final_capacity(capacity), m_buff(1) {}
iterator begin() { return m_buff.begin(); }
iterator end() { return m_buff.end(); }
size_type size() const { return m_buff.size(); }
size_type capacity() const { return m_final_capacity; }
T operator [] (size_type index) { return m_buff[index]; }
void push_back(const T item) {
check_capacity();
m_buff.push_back(item);
}
iterator insert(iterator pos, const T item) {
check_capacity();
return m_buff.insert(pos, item);
}
private:
void check_capacity() {
if (m_buff.full() m_buff.size() m_final_capacity) {
size_type new_capacity = m_buff.size() * 2;
if (new_capacity m_final_capacity)
new_capacity = m_final_capacity;
m_buff.set_capacity(new_capacity);
}
}
};
Jan
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] circular_buffer update
Hi all! The updated circular_buffer implementation can be found at the common place http://groups.yahoo.com/group/boost/files/circular_buffer.zip Please review it and remind me if I forgot to add some feature or fix something. Comments to the update: - Added exception handling. Please review this carefully, I'm not sure I have done this properly. - Changed implementation of the circular_buffer::resize() method. - circular_buffer: insert(pos, n, item) works correctly now. - Updated documentation (but the source code documentation stays unchanged). - Many other fixes. ToDo list: - Add T* circular_bufferT::data(); method. - Improve source code documentation (add pre/post conditions). - Maybe later the Mojo technique will be used. Maybe. Regarding unused space overhead I share the Nigel's opinion. The circular_buffer was designed with fixed allocated memory. It will just complicate things. For example statements regarding iterator invalidation won't be true any more. On contrary it is quite easy to adapt std::list, std::slist or std::deque to achieve this goal. You can just push_back() elements at the end of e.g. std:list. In case the size of the container exceeds the desired capacity you just remove the element from the front. To Nigel: Thank you very much for the documentation. I really like it. I changed the implementation of the resize() method - it will remove elements from the front if necessary. There was just one small bug in the Simple example: int a = pop_back(); // a is 5 int b = pop_front(); // b is 3 should be like this: int a = back(); // a is 5 int b = front(); // b is 3 And one misunderstanding in the Caveats: begin() == end() only if the circular_buffer is empty (it cannot be valid for the full buffer except one special case when the capacity == 0). Regards, Jan -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5930-0735 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] circular_buffer: minor feature request
I think, I changed mind. The flatten() method can be substituted by something like this: void doSomething(const int* pInt, size_t numInts); // C API circular_bufferint intBuffer(10); ... // fill the buffer somehow vectorint v(intBuffer.begin(), intBuffer.end());// copy if (!v.empty()) doSomething(v[0], v.size());// pass the data to the API // v[0] v[1] ... v[n] I think, we should rather keep the interface minimal. Jan Pavel Vozenilek wrote: Would it be possible to add helper function 'flatten()' into circular_buffer? After invocation, user would be sure of: buff[0] buff[1] ... buff[n] In other words, user will be able to treat circular_buffer content as continuous array of values in this moment. It is not earth shaking feature, it violates 'minimal interface' ideal but can be handy: - when legacy C function requires continuous array (like Win32 API) - when buffer is being saved to file or written to socket - special purpose adaptor could present result as (nonresizable) vector Alternatives are simple but much more CPU/memory expensive. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5930-0735 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Formal Review Request: circular_buffer
It is not generated file, you can edit it directly. Jan Nigel Stewart wrote: would you like some proof-reading for the documentation? I would very appreciate this! Is the file circular_buffer/doc/circular_buffer.html generated from some other file, or should I simply hand-edit it? Cheers, Nigel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5930-0735 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Quick thought on circular_buffer
No, because of iterator invalidation. Jan Daryle Walker wrote: Could circular_buffer be done like std::stack and std::queue, as an adapter for a regular container class? You may have to have a custom iterator, though. Daryle ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5930-0735 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] circular_buffer: minor feature request
Ok, it would be possible. Jan Pavel Vozenilek wrote: Would it be possible to add helper function 'flatten()' into circular_buffer? After invocation, user would be sure of: buff[0] buff[1] ... buff[n] In other words, user will be able to treat circular_buffer content as continuous array of values in this moment. It is not earth shaking feature, it violates 'minimal interface' ideal but can be handy: - when legacy C function requires continuous array (like Win32 API) - when buffer is being saved to file or written to socket - special purpose adaptor could present result as (nonresizable) vector Alternatives are simple but much more CPU/memory expensive. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5930-0735 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Formal Review Request: circular_buffer [long]
Pavel Vozenilek wrote:
Hello Jan,
Few more comments + answers.
1. Documentation: can circular_buffer be used as
container for stack/queue/priority_queue?
Yes, it can be. But I think, it is not necessary to mention it in the
documentation explicitly. Rather it is more important to mention that everyone is
encouraged to create an adaptor of this container (whatever he/she likes not only
stack or queue).
2. When BOOST_NO_EXCEPTION is defined, library
shouldn't throw but call function
throw_exception() from throw_exception.hpp
(or abort).
OK, I will try to follow it.
3. This fragment fails:
struct Test {}
circular_bufferTest a(2);
a.push_back(Test());
a.push_back(a[0]);
Instance of Test is overwritten (by construct())
and not destroyed in second push_back().
I don't understand this. IMHO there will be 2 copies of Test(). Nothing should be
destroyed in the second push_back(). I think, everything is OK.
This may be problem for insert()s as well.
I am not sure whether solving this kind of problems
is worth of the increased complexity. I do not know
what Standard mandates for such a circumstances.
4. It may be useful to have circular_buffer
constructor taking external buffer (e.g. static
or on stack) and using it internally.
(Feature has some similarity to std::streambuf.)
External buffer could lead to lower heap
fragmentation in apps.
Maybe. But it will complicate things, because couldn't delete this buffer and I
will have to treat this case specially. So, maybe later.
5. Currently functions like insert/erase cannot use
reverse iterators (similarly to standard
containers).
Some structures like LRU could find use for it.
I don't want to bother with this.
--
Jan Gaspar [EMAIL PROTECTED] wrote ...
3. cb_iterator: is the m_end value needed?
It can be computed using 'm_it == m_buff-m_last' in
those few (~2) places it is needed and if eliminated,
iterator will get smaller (by 30%) and simpler.
Yes, the m_end member is needed. Suppose the circular_buffer is full. Then
m_buff-m_first == m_buff-m_last. If there is no m_end variable how would
you
recognize that the iterator points to the beginning or end?
a) on compilers I use sizeof(bool) == 4 so removing it would have impact
b) what about setting m_it == m_buff every time iterator gets to the end?:
bool is_end() {
return m_buff == m_it;
}
Operator ++, --, , +=, -=, == can do the check and if needed they may
fetch the m_buff-m_last.
Since m_buff is already in some registry the check should impact
performance too much.
Should or shouldn't impact performance? What about setting m_it to 0 ?
5. In cb_iterator::operator-(): result of the expression
' it *this' can be saved and not computed second time.
But it is not used second time.
My mistake.
7. cb_iterator::operator!=(): it may be more efficient to code
it as 'm_it != it.m_it ...' instead of !operator==().
I do not know if compilers are allowed to change logical
expression and if, how good they are in it.
Maybe. But everyone uses it like this.
Everyone uses
for (iter i = buff.begin(); i != buff.end(); ++i)
While only small help, it may have impact in innermost loops.
OK
8. cb_iterator::operator(): the ASSERTS here are useless.
Function compare() doesn't return anything else
than -1/0/1 - I see it.
Yes, they are useless. But
1) omitting them doesn't speed up the execution (in general)
Well, excerpt from MSVC 7 help:
void main(int p)
{
switch(p){
case 1:
func1(1);
break;
case 2:
func1(-1);
break;
default:
__assume(0);
// This tells the optimizer that the default
// cannot be reached. As so it does not have to generate
// the extra code to check that 'p' has a value
// not represented by a case arm. This makes the switch
// run faster.
}
}
2) suppose if someone changes the compare() method implementation ...
Then the check should be within compare()
3) this code is clean, you should always provide the default option
IMHO not in this case. I struck my eyes.
However this is all unimportant detail.
OK
9. OTOH there are places where ASSERT can be inserted:
- ensuring two iterators come from the same buffer
- checking iterators are within valid range
- checking type of iterators is the same (reverse / normal)
circular_buffer is a STL compliant container - no STL container is doing
this.
STLport, newer Dinkumware and maybe even Metrowerks STL provides
DEBUG mode.
I may help you with this. It is however orthogonal to anything
else with the lib and can be added later into finished code.
I will appreciate this.
14. circular_buffer
Re: [boost] Re: Formal Review Request: circular_buffer
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. Jan Nigel Stewart wrote: Jan, I have closely proof-read the HTML document and intend to respond with a new draft shortly. There is one point I would like to raise for discussion: Inserting at the beginning or close to the beginning of the circular_buffer is another trap. boost::circular_bufferint cb(5, 1); cb.insert(cb.begin(), 2); // nothing will be inserted By way of the principle of least surprise I think that insert should _always_ succeed. Inserting to the front should always overwrite the back, and vice versa. The concept of old and new serves only to confuse the issue IMHO - there is a front and back, (or left and right) but the circular buffer should not assume that the front-most are the oldest or newest. (The circular buffer can be _used_ as a FIFO, but does not _enforce_ FIFO, since it allows both push and pop from each end) The following should be exactly equivalent: cb.insert(cb.begin(), 2); cb.push_front(2); We may have discussed this already, I havn't checked the archives, but it appears to me as hazardous. As a proposed semantic: Insertion to the front or back will always be equivalent to a corresponding sequence of push_front or push_back. What are the semantics of inserting a huge sequence to the middle of a circular buffer? What exactly gets kept? Nigel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5930-0735 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] circular buffer
Hi all!
The updated implementation and docs of the circular buffer (formerly called cyclic
buffer) can be found at
http://groups.yahoo.com/group/boost/files/circular_buffer.zip
To Howard Hinnant:
Probably I won't have time for doing the circular_deque but you can achieve the
insert method by adapting the circular buffer.
template class T class Adaptor {
private:
circular_bufferT m_buff;
public:
typedef typename circular_bufferT::iterator iterator;
typedef typename circular_bufferT::size_type size_type;
Adaptor(size_type capacity) : m_buff(capacity) {}
template class InputIterator
Adaptor(size_type capacity, InputIterator first, InputIterator last)
: m_buff(capacity, first, last) {}
iterator begin() { return m_buff.begin(); }
iterator end() { return m_buff.end(); }
size_type size() const { return m_buff.size(); }
size_type capacity() const { return m_buff.capacity(); }
T operator [] (size_type index) { return m_buff[index]; }
template class InputIterator
void insert(iterator pos, InputIterator first, InputIterator last) {
size_type new_size = size() + distance(first, last);
if (new_size capacity()) {
circular_bufferT buff(new_size, begin(), pos);
buff.insert(buff.end(), first, last);
buff.insert(buff.end(), pos, end());
m_buff.swap(buff);
} else {
m_buff.insert(pos, first, last);
}
}
};
Regards,
Jan
--
Jan Gaspar | [EMAIL PROTECTED]
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel +421(2)5930-0735 | Fax +421(2)5443-5512
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review Request: cyclic_buffer
Hi all Cyclics! I want to summarize what we have till now. What should be changed in the proposed cyclic_buffer. - Rename to circular_buffer. - Add push_front() and pop_front(). - resize() to behave similarly to vector::resize(). - change_capacity() becomes again change_capacity(). I think the name change_capacity best reflects what the method really does. The vector::reserve() can only increase the capacity, never decrease - which may be confusing. And at last the circular_buffer is not vector so it can have different methods from vector. - insert() will always increase the size and possibly can increase the capacity (if not sufficient). Regards, Jan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review Request: cyclic_buffer
Hi Howard!
I like your idea. But (referring to the Nigel Stewart's posting) what would you
propose for the insert? Should I not provide it?
Jan
Howard Hinnant wrote:
In article [EMAIL PROTECTED], Alisdair Meredith
[EMAIL PROTECTED] wrote:
| The one true circular buffer template is a nigh impossible goal,
| because it means so many things to different people.
snip
| I would certainly like the documentation to explain the tradeoffs made
| in the implementation, and why this particular variation was chosen as
| most appropriate for the general case.
Indeed! Excellent post!
Perhaps container adaptors could be applied to a sufficiently
generalized circular buffer.
What is the one true queue? There isn't one. It is best a container
adaptor (policy based if you prefer). I suspect that a more general
circular buffer, restricted by various adaptors, might serve more uses
with less code.
The circular buffer I've needed (and coded) fits none of aforementioned
descriptions. But it is a circular buffer nonetheless.
For my money, the general circular buffer is one that exists in a
contiguous array, but with an arbitrary begin and end within that
array, capable of wrapping around the end of the physical memory:
+---+---+---+---+---+---+---+---+---+---+
| 4 | 5 | | | | | 0 | 1 | 2 | 3 |
+---+---+---+---+---+---+---+---+---+---+
^ ^
| |
endbegin
Constant time push/pop_front, constant time push/pop_back. When begin
and end collide, reallocation automatically happens vector-like.
This data structure can be efficiently coded with a 4-word data
structure. For example: data_ptr, capacity, size, begin_ptr (there
are other variations that also only take 4 words).
From this you can write adaptors to constrain capacity, have push_back
overwrite front(), throw an exception on size() exceeding capacity(),
or whatever else you need to do.
You can't adapt any other std::container to do this job because vector
is the only one with capacity, but vector doesn't have a constant time
push/pop_front. But I believe you can adapt the above described
container to meet the needs of other circular buffer requirements.
For example:
template class T, class Container = general_cyclic_bufferT
class my_cyclic_buffer
{
public:
// typedefs ...
my_cyclic_buffer(size_type cap) {c.reserve(cap);}
reference operator[](size_type n) {return c[n];}
// etc.
void push_back(const value_type x)
{
if (capacity() != 0)
{
if (c.size() == c.capacity())
c.pop_front();
c.push_back(x);
}
}
change_capacity(size_type new_cap)
{
if (new_cap c.capacity())
c.reserve(new_cap);
else if (new_cap c.capacity())
{
c.erase(c.begin(), c.begin() + c.size() - new_cap);
Container tmp(c); // assumes tmp.capacity() == c.size()
c.swap(tmp);
}
}
// etc.
private:
Container c;
};
--
Howard Hinnant
Metrowerks
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--
Jan Gaspar | [EMAIL PROTECTED]
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel +421(2)5930-0734 | Fax +421(2)5443-5512
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Review Request: cyclic_buffer
Maybe the /EHa option will help. Paul A. Bristow wrote: This now looks very extensively tested. But when I tried to build the test.cpp using MSVC 7.0 and Boost 1.30, there are zillions of errors from the test modules. Do I need to use a more recent version of the test code? Thanks Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jan Gaspar | Sent: Wednesday, June 04, 2003 10:49 AM | To: [EMAIL PROTECTED] | Subject: [boost] Review Request: cyclic_buffer | | | Hi all! | | The cyclic buffer implementation and documentation (cyclic_buffer.zip) can be | found at: | http://groups.yahoo.com/group/boost/files/ | | Regards, | | Jan | | | -- | Jan Gaspar | [EMAIL PROTECTED] | Whitestein Technologies | www.whitestein.com | Panenska 28 | SK-81103 Bratislava | Slovak Republic | Tel +421(2)5930-0721 | Fax +421(2)5443-5512 | | | ___ | Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5930-0721 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Review Request: cyclic_buffer
Hi Paul! I used the Boost version 1.29 and I was able to compile it under MSVC7 with no error messages. Jan Paul A. Bristow wrote: This now looks very extensively tested. But when I tried to build the test.cpp using MSVC 7.0 and Boost 1.30, there are zillions of errors from the test modules. Do I need to use a more recent version of the test code? Thanks Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jan Gaspar | Sent: Wednesday, June 04, 2003 10:49 AM | To: [EMAIL PROTECTED] | Subject: [boost] Review Request: cyclic_buffer | | | Hi all! | | The cyclic buffer implementation and documentation (cyclic_buffer.zip) can be | found at: | http://groups.yahoo.com/group/boost/files/ | | Regards, | | Jan | | | -- | Jan Gaspar | [EMAIL PROTECTED] | Whitestein Technologies | www.whitestein.com | Panenska 28 | SK-81103 Bratislava | Slovak Republic | Tel +421(2)5930-0721 | Fax +421(2)5443-5512 | | | ___ | Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5930-0721 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Review Request: cyclic_buffer
Even with boost 1.30 I got just some warnings, but no errors. I don't know what's wrong. Jan Paul A. Bristow wrote: This now looks very extensively tested. But when I tried to build the test.cpp using MSVC 7.0 and Boost 1.30, there are zillions of errors from the test modules. Do I need to use a more recent version of the test code? Thanks Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jan Gaspar | Sent: Wednesday, June 04, 2003 10:49 AM | To: [EMAIL PROTECTED] | Subject: [boost] Review Request: cyclic_buffer | | | Hi all! | | The cyclic buffer implementation and documentation (cyclic_buffer.zip) can be | found at: | http://groups.yahoo.com/group/boost/files/ | | Regards, | | Jan | | | -- | Jan Gaspar | [EMAIL PROTECTED] | Whitestein Technologies | www.whitestein.com | Panenska 28 | SK-81103 Bratislava | Slovak Republic | Tel +421(2)5930-0721 | Fax +421(2)5443-5512 | | | ___ | Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5930-0721 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Review Request: cyclic_buffer
Hi all! The cyclic buffer implementation and documentation (cyclic_buffer.zip) can be found at: http://groups.yahoo.com/group/boost/files/ Regards, Jan -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5930-0721 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] cyclic buffer
Rob Stewart wrote: From: Jan Gaspar [EMAIL PROTECTED] This is something different - it is an iterator; if it reaches an end of the container it shifts to its beginning. Cyclic buffer is a container with different capabilities. I can send it to you, if you want. Of course it is. However, since your circular buffer is merely adapting a deque, you could just as well use Gennadiy's iterator adapter to adapt the relevant (probably begin() and end()) iterators of a deque or vector or You could even change your implementation to use Gennadiy's iterator adapter. Your class could be just a deque and an adapted iterator. I could but I don't want to. I don't want to mix two different concepts: circular buffer and circular iterator. I think that circular iterator is a standalone concept which can be used over any kind of container (even over circular buffer). BTW I'm improving the circular buffer implementation - it will adapt a vector. This will result in performance increase and improvement of iterator invalidation. Neal D. Becker wrote: This is from Gennadiy Rozental. I believe this is the latest version. Please correct me if not. Since it is small, I'll just post it here: ... -- Rob Stewart [EMAIL PROTECTED] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- Jan Gaspar | [EMAIL PROTECTED] Whitestein Technologies | www.whitestein.com Panenska 28 | SK-81103 Bratislava | Slovak Republic Tel +421(2)5443-5502 | Fax +421(2)5443-5512 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
