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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
