[boost] Re: Re: circular_buffer ver. 3.3

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2003-09-02 14:07:28

Hello Jano,

> > 5. Borland C++ Builder 6.4 doesn't allow to bring
> >    operator[] via using.
...
>
> What about just overriding operator[] for all compilers? (With the note
that some
> compilers doesn't support using for operators.)
>
Incentive for vendows to blush and fix the bug? AFAICS Borland won't anyway
:(

> > Also the "<< 1" and ">> 1" can be in this case safely replaced by * 2
and /
> > 2  (it is unsigned).
> What is wrong with "<<1" and ">>1". I think it is safe and it is more
effective
> for some compilers which don't optimize the *2 operation.
>
My feeling is it is a bit obscure. Modern compilers I know do this
optimisation.

> > Shrink algorithm can be:
> > a. allow hysteresis when shrinking
> >    if new_size < current_capacity / 3 then
shrink_to(std::max(min_capacity,
> > current_capacity / 2))
>
> Why current_capacity / 3 ?
>
Sorry, it was unclear:

new_capacity = min(2 * current_capacity, max_capacity)
if (new_capacity + new_capacity / 2 >= max_capacity) then new_capacity =
max_capacity

> > The constructors and set_capacity() would need one more paramerer or
> > overload,
> > capacity() could return pair<>. clear() would need change.
>
> Maybe new method can be introduced e.g. min_capacity(). The capacity
method stays
> unchanged.
>
Probably.

> > 9. circular_buffer_base.hpp and circular_buffer_adaptor.hpp:
> >    instead of check
> >
> > #if !defined(BOOST_NO_FUNCTION_TEMPLATE_ORDERING) || defined(BOOST_MSVC)
> >
> > is enough to use
> >
> > #if !defined(BOOST_NO_FUNCTION_TEMPLATE_ORDERING)
> >
> > (it is defined for MSVC).
>
> I don't know why, but this does not work. You have to include "||
> defined(BOOST_MSVC)" too.
>
Works on my machine, hmm...

It may be too pessimistic for future versions of MSVC.

> > 14. Btw, isn't cb_iterator::operator[]() added by mistake?
> >     I have never seen such an operation for iterator.
> No, iterators do have this operator.
>
Oops, newer used before :-o

> > 16. RAII vs try blocks:
...
> My colleague told me, if such a system exception ocurrs the destructor of
the
> exception guard won't be called. Check this out please. He also told me
that the
> system exceptions have nothing to do with C++ exceptions except that
catch(...)
> catches them. Btw. I would wonder if all the STL implementations would be
just
> wrong.
>
I did small test with Intel C++ and destructor gets called.

After checking newsgroups, it seems main objections are against:

catch(...)  {} // no re-throw inside

but:

catch(...) {
   ...
   throw;
}

should behave right.

------------
Few more notes:
1. It may be good to mention exception safety in the documentation (the
basic safety guarantee, that is).
2. Maybe header files (with exception circular_buffer.hpp and
circular_buffer_fwd.hpp) should be moved into subdirectory
boost/circular_buffer/.

/Pavel