Boost logo

Boost :

From: Pavol Droba (droba_at_[hidden])
Date: 2004-03-08 14:34:32


I'd like to cast my vote on the circular_buffer review.
I have read through all documentation, briefly skimmed through the
implementation and test code.

a.. What is your evaluation of the design?

The library follows the standard STL container conventions very closely.
Provided interface is sufficient and well defined. Debugging facility seems very useful.

One objection I have is following:
Interaface models Sequence concept, but one of the concept's requirements is missing.
There is no constructor taking just two iterators as a parameter. Initialization
from a pair of iterators is provided, but the signature does not match the requirements
of Sequence concept. It is not possible to use this container in generic algorithms,
that require such a constructor (this is quite common case IMHO).

I would like to see more adaptors in addtion to one provided. Concretely, one that
have been already mentioned, which provides means for notification when a
buffer is empty/full. This might be extremly useful.
Another adaptor I would like to see, is one, that disallows rewriting of the
old elements. Such an buffer can be used as a faster alternative to std::deque,
when a bounded buffer is sufficient. Checking for overflow can be provided by an
exception or an error code from insering operations.

b.. What is your evaluation of the implementation?

Implementaion seem quite solid. I have no objections.

As for the assign-construct/destruct discussion, I think, that one of options would be to
use a policy class to define the behaviour. Both approaches have their
own pros and cons. Assignment might bring some speedup and I would prefer it as default.
Construct/Destruct might be benefitial in some applications (f.e. an object is notified, by
a destructor, that it has been removed from buffer).

c.. What is your evaluation of the documentation?

Documentation seem sound and well prepared. I was able easily understand
how to use the library. Examples are illustrative enough for the common usage.

I have few suggestion, though. First of all, I don't like doxygen generated documenation
too much. This might be my personal preference, however it does not integrage
with other parts of documentation well. Source documentaion has different layout and format
than the rest and IMO it is little bit confusing to use two styles in one doc.

There is an obvious suggestion to solve this problem: convert docs to boost-book.

d.. What is your evaluation of the potential usefulness of the library?

I find the library useful for many application. Either as a bounded aging buffer
or as a faster alternative for deque when memory limit is benefitial or required.

e.. Did you try to use the library? With what compiler? Did you have any

I have compiled test cases without any problem on vc7.1 and gcc3.3.1 under cygwin

f.. How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?

I have spend about 2 to 3 hours studying the code, the documentation and reading
the discussions here on the list.

g.. Are you knowledgeable about the problem domain?

I have good knowledge about STL containers and concepts related to them.

h.. Do you think the library should be accepted as a Boost library?

I vote that the library should be ACCEPTED to boost.

It provides handy utility. Design and implementation is solid, documentation is acceptable.



Boost list run by bdawes at, gregod at, cpdaniel at, john at