Subject: Re: [boost] [mini-review] Update of Boost.Assign (13th-19th of June)
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2010-06-16 18:22:19
On 16/06/10 16:45, er wrote:
> John Bytheway wrote:
>>> I guess it wouldn't be an insurmountable task to overload csv() on the
>>> number of arguments, internally calling list_of(), and returning its
>> That sounds sensible. I think there should be such a function.
> OK, will take that into consideration but more about that below.
> Meanwhile, it's already possible to do
> std::vector<int> vec = (list_of(1),2,3);
That's nice to know (if not really elegant), and FWIW I certainly didn't
pick it up from the docs.
>>> What is complicating things, however, is that list_of() itself is
>>> overloaded on the number of arguments.
>>> creates an anonymous list of elements created like this : T(x,y) and
>>> If you want to achieve the same thing with cref_csv, you have to do:
>> I don't understand why that is a complication. In this case it would be
>> logical for the user to use list_of instead (at least from the
>> perspective of amount of typing).
> I would tend to always use cref_list_of(a)(b)(c) rather than
> list_of(a)(b)(c), because the first one is generally faster, see
Wow, those differences are far more dramatic than I would have expected;
it looks like more than ten thousand fold in some cases! I may have to
look at the code to understand this better...
> and offers a more comprehensive interface such as indexing (operator).
> The function list_of() shines, however, in other areas, such as being
> able to call
> typedef std::pair<const k_type,t_type> pair_;
> map = list_of<pair_>(a,b)(c,d);
> (by the way this is how map_list_of(a,b)(c,d) is implemented) whereas
> the alternative calls for more typing:
> map = cref_list_of(pair_(a,b))(pair_(c,d));
> So I agree that it is logical to have csv() paired with list_of(), but
> it's only feasible for a subset of the interface of list_of(), which is
> (at least) just as well provided by cref_list_of()/cref_csv().
> Another subset of the interface is
> which could not have been implemented for cref_list_of(). The closest
> match is
> cref_list_of(a)(b) && v;
> but in the first case, the rhs elements are copied into an internal
> vector. In the second case no copying takes place, it works by keeping
> references to the two ranges, which is potentially faster.
There are clearly a lot more subtleties here than I appreciated. The
impression I got from the docs seems different from the one I'm now
getting from you; the docs make heavy use of list_of where you seem to
be advising against it. Perhaps I'm extrapolating too much from the
tutorial, and should have read the reference in more detail...
> So overall, we have two sets of functions which differ quite
> significantly in their interface and implementation. The question
> perhaps, is if we want to leave them apart or merge the desirable
> features into one.
I'm not sure which two sets you're referring to. Is it the *ref* ones
on the one hand and list_of on the other?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk