
Let's assume I get paid for writing a TPS report, every day, involving 100 unit-tests such as the one below.
array<int, 4> log_constants = {1, 10, 100, 1000}; vector<int> cont; int n = 2; foreach(i, log_constants) int x = log10(i); for(int j = 0; j< n;++j) { cont.push_back(x); }
I doesn't matter, really, how the values are arranged or what kind of boss you have. I don't know if I got the above code correctly, but it doesn't matter. The point is that it's readable.
Indeed, it's readable. But I talked about 100 unit tests that vary a bit. Let's settle for 5. The STL way: array<int, 1> log_constants = { a1 }; vector<int> cont; int n = n1; foreach(i, log_constants) int x = f1(i); for(int j = 0; j < n;++j) { cont.push_front(x); } } array<int, 2> log_constants = { a2, b2 }; vector<int> cont; int n = n2; foreach(i, log_constants) int x = f2(i); for(int j = 0; j < n;++j) { cont.push_front(x); } } array<int, 3> log_constants = { a3, b3, c3 }; vector<int> cont; int n = n3; foreach(i, log_constants) int x = f3(i); for(int j = 0; j < n;++j) { cont.push_front(x); } } array<int, 4> log_constants = { a4, b4, c4, d4 }; vector<int> cont; int n = n4; foreach(i, log_constants) int x = f4(i); for(int j = 0; j < n;++j) { cont.push_front(x); } } array<int, 5> log_constants = { a5, b5, c5, d5, e5 }; vector<int> cont; int n = n5; foreach(i, log_constants) int x = f5(i); for(int j = 0; j < n;++j) { cont.push_front(x); } } Assign v2 way: csv( // 1 deque<int, push_front_>( _nil ) % ( _data = f1 ) % ( _repeat = n1 ), a1 ); csv( // 2 deque<int, push_front_>( _nil ) % ( _data = f2 ) % ( _repeat = n2 ), a2, b2 ); csv( // 3 deque<int, push_front_>( _nil ) % ( _data = f3 ) % ( _repeat = n3 ), a3, b3, c3 ); csv( // 4 deque<int, push_front_>( _nil ) % ( _data = f4 ) % ( _repeat = n4 ), a4, b4, c4, d4 ); csv( // 5 deque<int, push_front_>( _nil ) % ( _data = f5 ) % ( _repeat = n5 ), a5, b5, c5, d5, e5 ); Isn't this more clear, and less error prone? It is not that much, and not "crucial", but the claim of the library is just as modest: "Its core utility is a compact interface for executing the repetitive tasks of assigning or inserting elements in a container". As for v1 vs v2, I have already stated 3 improvements that you have not refuted. What's left to prove, in your eyes, is that the changes benefits the user. For instance, with list_of, you have to contend with push_back, if I recall correctly. Second, you can invoke fun() in place of % ( _data = f ) repeat() in place of and repeat() in place of % ( _repeat = n ) and fun_repeat() in place of % ( _data = f ) % ( _repeat = n ); That's about it, whereas you are not limited in the number of options in v2. See here, however: https://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/bo... Furthermore, it's open for extension i.e. you can write your own _option, should the available options be insufficient to meet your needs.
could compact that myself quite a bit with some useful snippets if my daily work involved this kind of code repeatedly.
Not with STL, if the structure of your program changes often : you would have to rewrite a new snippet often as well.
I would still like to a see a clear, concise and easy to read example that shows: * The example can't be expressed neatly with V1.
I think I answered that.
* The example can't be expressed neatly with standard tools, such as Boost.Range + Boost.Lamba/Phoenix,
Why don't you show me how to do it with Range + Lambda, and if necessary I'll move to more complicated examples?