On 6/19/11 6:36 PM, er wrote:

On 6/16/11 5:56 PM, John Bytheway wrote:

...

Please consider looking at the library and submitting a review.

And please allow me to spark a bit of interest: { // Boost.Assign 2.0 using namespace boost::assign::v2; map_ map; csv_put<2>( map, "jan", 31, "feb", 28, "mar", 31 ); } }

Let's see a few variants (continuing the same example) #include <boost/range/algorithm/copy.hpp> #include <boost/assign/v2/include/do_csv_put.hpp> #include <boost/assign/v2/include/csv_deque_ext.hpp> #include <iostream> #include <iterator> // Variant #2 { // Boost.Assign 2.0 using namespace boost::assign::v2; map_ map; boost::copy( map | do_csv_put<2>( "jan", 31, "feb", 28, "mar", 31 ) | boost::adaptors::map_keys, std::ostream_iterator<str_>( std::cout, " ") ); // prints feb jan mar } // Variant #3 { // Boost.Assign 2.0 using namespace boost::assign::v2; map_ map = converter( csv_deque<p_, 2>( "jan", 31, "feb", 28, "mar", 31 ) ); } PS: - csv_deque<p_, I>( a1,...aI, ..., z1,...,zI ) is same as deque<p_>( a1, ..., aI)...(z1, ..., zI) - deque's nearest equivalent in Boost.Assign ( 1.0 ) is list_of - do_csv_put<>() is C++0x only as of current revision Any questions?

...

Where to get it ===============

The documentation is online at:

<http://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/index.html>

For some reason the code examples for this library remind me of ruby, in that when I first saw ruby code it was completely unreadable.

I'm not sure the pipe, dot and comma usage is really intuitive, nor csv. I'm pretty good at guessing TLA meanings, but csv meant nothing to me until I saw "comma seperated values" somewhere in the tutorial or something. "csv_" might as well be "_", it would be shorter and just as intuitive. "put" is at least intuitive. I think "values" would be more intuitive than csv and if it were me I'd probably name csv<2> "value_pairs", but then I don't mind typing. Typing time should not correlate to productivity. Longer names don't increase code complexity. It isn't clear to me that the library syntax reduces code complexity.

These are useful comments, thanks. Would this be a viable alternative? a) Variadic form, unchanged: put( cont )( args1 ... )... (argsn... ); b) As a replacement for csv_put<I>(), where I represents a fixed arity put<I>( cont, a1,...,aI, ..., z1, ..., zI ); c) Abandon the basic form csv_put() (no integer template) overload altogether. d) The pipe syntax then becomes: cont | _do_put.for_each( range ); cont | _do_put.for_each<I>( range_tuples ); cont | do_put<I>( a1,...,aI, ..., z1, ..., zI ); About your other comments: - operator| has a similar meaning in Boost.Range under adaptors. - Feel free to suggest another prefix than 'do'. - Dot is borrowed from Boost.Assign (1.0). - There are no comma operators anymore. - Prefix _ is reserved for const objects (not sure the proper word for it) HTH, and will give some thought to your other questions.

On 20/06/11 18:36, Simonson, Lucanus J wrote: <snip>

I very much like initializer list syntax, but the syntax for this library doesn't give me any warm feelings. Perhaps we need motivating examples and a little bit of rationale for *why* such a library should exist. Does it make doing something much easier in a templated context or is it just a quest to type less when using standard containers in code that looks like the examples? I ordinarily only initialize containers to literals when writing unit tests.

I think unit tests are indeed an important use case for such a library. That's where I use the existing Boost.Assign. John Bytheway

On 21/06/11 21:47, Simonson, Lucanus J wrote:

John Bytheway wrote:

...

On 20/06/11 18:36, Simonson, Lucanus J wrote: <snip>

...

I very much like initializer list syntax, but the syntax for this library doesn't give me any warm feelings. Perhaps we need motivating examples and a little bit of rationale for *why* such a library should exist. Does it make doing something much easier in a templated context or is it just a quest to type less when using standard containers in code that looks like the examples? I ordinarily only initialize containers to literals when writing unit tests.

I think unit tests are indeed an important use case for such a library. That's where I use the existing Boost.Assign.

In unit tests I tend to write ugly code like:

std::vector<Point> pts; pts.push_back(Point(0,0)); pts.push_back(Point(0,10)); pts.push_back(Point(10,10)); pts.push_back(Point(10,0)); Polygon pgn(pts.begin(), pts.end()); assert(boost::polygon::area(pgn) == 100);

only because I'm lazy and I'm not really concerned about whether my unit test code is elegant. Unit tests is where I need such a library most, but care least.

If you'd like more specific evidence, here's a unit test from a program of mine using Assign v1 where it saves a great deal of code over the above approach: auto result = do_outcome_test( list_of("7 4 H:8")("2 D:9 H:J"), list_of("r")("")("")("")("t"), list_of ("21")("Sk")("20")("18") ("C9")("CQ")("CJ")("CN") ("12")("16")("19")("17") ("10")("14")("13")("15") (" 8")("CK")(" 9")("11") ("SJ")("St")("S8")("SN") ("HK")("H9")(" 5")("HQ") (" 6")("DN")(" 3")("DK") ("DQ")("DJ")("Dt")("SK") ("Ht")("H7")(" 1")("HN") ("C8")("S9")("C7")("Ct") ("D8")("S7")("D7")("SQ") ); BOOST_CHECK(result.scores == list_of(0)(0)(0)(0)); BOOST_CHECK_EQUAL(result.outcome.string(), "t4");

I don't understand the motivation for having this library if using C++0x initializer lists is an option. What then is the point of C++0x only library features?

What features are you thinking of? I think it is primarily that the library takes advantage of C++0x where possible to go better or faster, rather than providing 0x-only features.

Allowing a filter function to be applied on each element as it initializes the container seems somewhat of a stretch.

Well, here are a few possible reasons why it's reasonable to take advantage of C++0x features to solve problems for which initializer lists would be a better solution: - gcc supported variadic templates and rvalue references before initializer lists. clang doesn't support the latter yet. So, there are compilers out there where these features can be used and initializer lists cannot. - Containers have to explicitly support initializer lists. There are plenty out there that don't, and most probably never will. - You can write code which works under both C++03 and 0x, but will compile and/or run faster in 0x.

We can't have

template <typename T> boost::range<T> get_range(T*, std::size_t size);

foo(get_range({"a", "b", "c"}, 3);

or even

template<typename T, int size> boost:range<T> get_range(T[size]);

foo(get_range({"a", "b", "c"});

as a simple range adaptor for C-style array so that we can use regular array initializer lists as a range, but have to go through an intermediate c-sytle array instead.

I get this error: test.cpp:6: error: expected primary-expression before '{' token when I try, so I guess we can't pass C++98 initializer lists directly into functions. Even if we could that would only get us half way since we still wouldn't have initializer lists for elements of the array.

Oh well, Luke

Sorry, I don't really understand your point. Indeed this failing of C++98 is one of the motivations for the Assign library. Even in gcc 4.5 in 0x mode I can't do this: void f(std::array<int, 3> const&) { } f({0, 1, 2}); I'm not sure whether it is supposed to work by the standard. The analogous thing with std::vector does work. John

On 6/21/11 4:19 PM, Brendon Costa wrote:

Hi,

I did briefly skim over the docs and compare between v1 and v2. The only point I have right now is that the docs for v2 are much less motivating compared to v1. The examples provided in v1 are clear and simple. In v2 I find the syntax less clear for describing the purpose of what is trying to be achieved. This could just be a documentation issue or an issue in the new library I have not had a chance to look through it thoroughly.

Noted, thanks. Perhaps I should have focused more on the core : * For filling a container: put( cont )( a, b )( c, d, e )( f, g, h ); // Variadic form csv_put<2>( cont, a1, b1, a2, b2, a3, b3 ); // Fixed arity Based on Simonson's comments I suggested an even simpler syntax, essentially renaming csv_put<I>() to put<I>(), but for now I'll stick to what already exists. * To initialize a container: // Variadic form: C cont = converter( deque<T>( a, b )( c, d, e )( f, g, h ) ); // Fixed arity: C cont = converter( csv_deque<T, 1>( a1, b1, a2, b2, a3, b3 ) ); A similar approach follows to construct a container in place (Called explicit conversion in the tutorial). Truth is, this covers a wide span of needs, perhaps most needs. Everything else that is talked about in the tutorial might have obfuscated it, I guess, as pertaining to filling & inserting. Thanks, therefore, for you feedback. Any more questions? Reference arrays and chaining can be seen as independent from the above and were the topic of a mini-review in June. Please consider looking at those as well. Thanks.

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of er Sent: Tuesday, June 21, 2011 10:41 PM To: boost@lists.boost.org Cc: boost-users@lists.boost.org Subject: Re: [boost] [review][assign] Formal review of Assign v2 ongoing

Based on Simonson's comments I suggested an even simpler syntax, essentially renaming csv_put<I>() to put<I>(), but for now I'll stick to what already exists.

I've been reading the docs and following this thread. csv_put also left me thinking "Huh?" and I still can't see what 'comma separated values' has anything to do with it. It doesn't seem to express the 'fixed number of things' concept at all? put seems clear enough - if you can overload it (and all csv variants) as you suggest with put<N>. Otherwise 'put_fixed' or 'fixed_put' might be clearer? Paul PS Seems to me that all this assign stuff seems very complicated for something really quite simple. It exposes the weakness in C++ language design - arrays are not 1st class citizens, and still are not, and having POD interferes with simple initialisation. But we stuck with that :-( And I support this assign.v2 library as a pragmatic solution, as assign.v1 was.

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.

On 6/22/11 11:47 AM, lcaminiti wrote:

lcaminiti wrote:

...

One question: How do users extend the library to make it work with user-defined containers different from the ones supported "out of the box"? http://svn.boost.org/svn/boost/sandbox/assign_v2/libs/assign/v2/doc/html/boo...

Can anyone comment also on the question above? (Maybe it's trivial but still I'd like to know...)

If you want to use a container with a modifier that is already known to the library, such as insert(), you can already do: csv_put<insert_, I>( my_cont, a1,...aI, ..., z1, ...,zI); //(*) although remember I have already made the point that this interface insert<I>( my_cont )( a1,...aI, ..., z1, ...,zI) is probably quite easy to implement as well, if requested. If your container is of the same flavor as push_back but with a special name, such as my_push_back(), you need to expand these macros: #include <boost/assign/v2/option/modifier/std.hpp> BOOST_ASSIGN_V2_OPTION_STD_MODIFIER_TAG(my_push_back) BOOST_ASSIGN_V2_OPTION_STD_MODIFIER(my_push_back) There are modifiers that are not standard (STD). For example, iterate depends on a state, n, which is the starting index (By the way, this index is restricted to zero in v1, I think). You might be able to guess how to proceed by following this example https://svn.boost.org/svn/boost/sandbox/assign_v2/boost/assign/v2/option/mod... If not, let me know, and I'll try to elaborate. Finally, if you want, say, insert() to be your default i.e. (*) is same as csv_put<I>( my_cont, a1,...aI, ..., z1, ...,zI); there are two cases. If your container falls into the category 'associative', for which insert is used by default, you need to put at the top of your headers, a header that expands this macro: #include <boost/assign/v2/support/traits/aux_/value_container.hpp> BOOST_ASSIGN_V2_TRAITS_CONTAINER_CATEGORY(SeqPar, IsCategory, Identifier, SeqArg) as shown here: https://svn.boost.org/svn/boost/sandbox/assign_v2/boost/assign/v2/support/tr... If you container does not fall into category 'associative', you would have to file in a feature request to override this file https://svn.boost.org/svn/boost/sandbox/assign_v2/boost/assign/v2/interprete... with a new switch statement. Unfortunately, this file is not open for extension. Someone with a good grasp of macros might be able to suggest a remedy.

Thanks a lot!

My pleasure, thanks for your interest.

--Lorenzo

-- View this message in context: http://boost.2283326.n4.nabble.com/review-assign-Formal-review-of-Assign-v2-... Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost