Boost logo

Boost :

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-08-13 14:18:34


Eric Niebler <eric <at>> writes:

> I disagree with this. If anything non-trivial is going on in commit(),
> then the second version cannot be *efficiently* implemented in terms of
> the first, which means the second is necessarily the more primitive of
> the two.

If anything interesting is going on in commit()
then neither one can be implemented efficiently
in terms of the other. I was a bit unclear. I
thought that buffering was the only reason for
using the second form. Thus, I envisioned

template<class T>
struct get_buffer_type {
    typedef no_buffer type;


template<class T>
struct ordered_assign :
    is_same<typename get_buffer_type<T>::type, no_buffer>::value
>::template apply<T> {};

struct ordered_assign_impl<true> {
  //use push_back

struct ordered_assign_impl<false> {
  //use a range assignment.

> The inserter design (with commit()) came out of a design discussion with
> Dave A., which I took the time to review this morning. He was coming at
> the problem from the perspective of MTL4 -- matrices and vectors. For
> MTL4, he wanted generic ways of representing sparse data and of building
> sequences. We wanted a mechanism that was general. He imagined a desire
> to temporarily violate the invariants of a sequence while building it,
> and then using commit() to "make it good".
> <snip>

I see. The inserters make a lot more sense in
a larger context.

In Christ,
Steven Watanabe

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