4

I was wondering if boost::range or range_v3 will reconciliate free functions and member functions in a similar way that std::begin reconciliates STL containers and C-like arrays (in terms of coding genericity I mean)?

More particularly it would be convenient to me to call std::sort on a list that automatically calls the best possible implementation given by std::list::sort.

At the end, could member functions be seen as interfaces for their generic counterpart only (std::list::sort never called in client code)?

KevMoriarty
  • 43
  • 4
  • isn't this planned for '17 – sp2danny Aug 04 '15 at 18:53
  • @sp2danny There's a proposal to unify call syntax, making `f(x)` and `x.f()` roughly equivalent. However, I'm not sure if it helps here since range-v3 implements its algorithms as function objects rather than function templates. So `sort(L)` is really something like `sort_fn()(L)`. If the latter fails (because `L` isn't a `RandomAccessRange`), will it go back to the original syntax and try L.sort()? I'm not sure. – edflanders Aug 05 '15 at 11:57

1 Answers1

2

AFAIK, neither library you mention deals with this directly. There is a push to deal with this kind of thing more generally in C++17, including a proposal to make f(x) and x.f() equivalent, but as I mentioned in the comment above, I'm unclear if it will work with range-v3's algorithms.

I did notice an interesting comment in range-v3's sort.hpp: // TODO Forward iterators, like EoP?. So, perhaps Niebler does have ideas to support a more generic sort. ("EoP" is Elements of Programming by Alex Stepanov.)

One complication: A generic sort uses iterators to reorder values, while list::sort() reorders the links themselves. The distinction is important if you care what iterators point to after the sort, so you'd still need a way to select which sort you want. One could even argue that sort() should never call list::sort(), given the different semantics.

edflanders
  • 213
  • 1
  • 6
  • The way I see it in the paper, the only way that proposal could solve OP's problem is if they choose the alternative #6 (Bjarne's proposal), which would make `sort(myList)` prefer the member function `myList.sort()`. I'm not sure if that alternative will be chosen though, as it potentially breaks code – KABoissonneault Aug 05 '15 at 12:23
  • As I read it, any of the options except "do nothing" would solve the problem if `sort` were a normal function. But, `ranges::sort` is an alias for a function object, so I'm not sure what happens. – edflanders Aug 05 '15 at 12:38