Re: [boost] [mini-review] Update of Boost.Assign (13th-19th of June)

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.
>>>    list_of<T>(x,y)(z,w)
>>> creates an anonymous list of elements created like this : T(x,y) and
>>> T(z,w).
>>>
>>> If you want to achieve the same thing with cref_csv, you have to do:
>>>     cref_csv(T(x,y),T(z,w))
>>
>> 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
> 
> https://svn.boost.org/svn/boost/sandbox/statistics/support/libs/assign/doc/speed.txt
> 
> https://svn.boost.org/svn/boost/sandbox/statistics/support/libs/assign/doc/speed2.txt

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
> 
>   list_of(a)(b).range(v);
> 
> 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?

John Bytheway