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/s...
https://svn.boost.org/svn/boost/sandbox/statistics/support/libs/assign/doc/s...
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