
AMDG Eric Niebler <eric <at> boost-consulting.com> 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<bool> ordered_assign_impl; template<class T> struct ordered_assign : ordered_assign_impl< is_same<typename get_buffer_type<T>::type, no_buffer>::value
::template apply<T> {};
template<> struct ordered_assign_impl<true> { //use push_back }; template<> 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