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: er (erwann.rogard_at_[hidden])
Date: 2010-06-16 11:45:34

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);

>> 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

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.

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.

> 
> On a related subject (and perhaps slightly beyond the scope of a
> mini-review), have you considered a perfect forwarding version of any of
> these functions?  Or even move-enabling the by-value ones?  You're

My guess, here, is that you would like to see ref_csv() and cref_list() 
merged into one function that takes either of lvalues or rvalues. Is my 
interpretation correct?

> already  justifying the _ref versions on grounds of speed; this would be
> the logical next step in that direction. Personally I would be happy to
> have such only in C++0x and not bother with move-emulation in C++03, but
> then I don't program in C++03 any more if I can possibly help it :).
> 
> John Bytheway
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>