On 6/21/11 10:16 PM, Lorenzo Caminiti wrote:
Perhaps similarly, I red all v2 docs and compiled all the tutorial examples. However, I am not familiar with v1 and I decided that I needed to go back and study v1 in order to understand why v2 is better/more useful -- so I am reading v1 docs now :)
I accept the general criticism that the presentation is not clear. However, please refer to my message to Brendon and let me know if these clarifications are helpful. As for why v2 is an improvement over v1, let me explain what motivated it - First, there are two important functionalities in 1.0, container generation (list_of now called deque) and list-inserters (not called put) that I bridged together via a crtp class for better code reuse. For example, the proxy object (now called interpreter) returned by list_of has functions repeat and repeat_fun, but the list_inserter independently defines similar functions, if I recall correctly. - Second, I've tried to look under the hood of v1 and see if more code decoupling could be extracted from it. In v2, data-generation and the modifier invoked to insert its result are orthogonal. This is seen under section Option in the tutorial. By parameterizing data-generation and the modifier it's possible to extend either arbitrarily. Modifiers are no longer restricted to the basic ones (push, insert ...), and by the way, list_of (from v1) only "knows" one way to insert elements, push_back, a restriction that is lifted for its successor, deque. - Third, it's now the same interface for value container and pointer containers. In fact, all container categories share the same interface : put and csv_put<>(). - Fourth, trying to figure out conversion in Boost.Assign 1.0 taught me some very worthwhile idioms. However, I have tried to make the interface a tad simpler with a unique function convert<>(), rather than to_adapter<>() and to_container<>(). It is described here: https://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/bo... As regards to ref + chain, please refer to my previous messages. In a private conversation, it has been suggested that a modifier option is not as intuitive as a function dedicated to a particular modifier. For example, csv_put<I, push_front_>(cont, a1,…,aI, …, z1, zI); is not as clear as: push_front<I>( cont, a1,…,a1, …, z1, …,zI); which I can concur with. It would be feasible to allow that as well, but it's going to cost more compilation time, at least under C++03. Naturally, this is mitigated by keeping headers separate for each option, push_front, push_back etc, as is the case under directory /std in v1. Finally, this cost can be drastically reduced (if I'm thinking right) with a small sacrifice to elegance: push_front<I>( cont )( a1,…,a1, …, z1, …,zI); // Thanks for your feedback, and don't hesitate to ask more questions.