On May 14, 1:30 pm, Scott Meyers <use...@aristeia.com> wrote:

> I respect the work involved to get anything into C++0x, but looking only
> at the
> resulting API, range-based for-loops come across as a restricted taste
> of what
> continues to be otherwise forbidden fruit.

I embarrassingly didn't even find out about ranges until I stumbled
across a presentation by Alexandrescu about ranges in D (and how he
believes they are better than iterators with respect to algorithms). I
started a thread in comp.lang.c++.moderated to learn more about his
point-of-view, and Andrei's been more than patient. Perhaps if the 0x
range wasn't iterator-based it would have been easier to do. I have to
agree that the Range Concept feature seems somewhat incomplete in 0x
without support in the algorithms.

I found this (oldish) proposal by Thorsten Ottosen:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1871.html
and it looks like it's in the holding pattern for TR2 for lack of time/
manpower to get it included in 0x.

I just hope TR2 isn't five years away.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

C++0x specifies the Range concept and uses it in range-based for loops,
but I
don't see any support for it among algorithms.  The C++0x FAQ at
http://www.research.att.com/~bs/C++0xFAQ.html#concepts notes:

> Being able to classify and distinguish different types of types, we can
  > overload based on the kind of types passed. For example
>
>  // iterator-based standard sort (with concepts):
>  template<Random_access_iterator Iter>
>   requires Comparable<Iter::value_type>
>  void sort(Iter first, Iter last); // use the usual implementation
>
>  // container-based sort:
>  template<Container Cont>
>   requires Comparable<Cont::value_type>
>  void sort(Cont& c)
>  {
>   sort(c.begin(),c.end());    // simply call the iterator version
>  }
>
>  void f(vector<int>& v)
>  {
>   sort(v.begin(), v.end());   // one way
>   sort(v);                    // another way
>   // ...
>  }

I don't see such overloads in the C++0x draft, and I know that having to
explicitly specify begin and end iterators for full-container operations
has
been a usability sore point among users since, well, since pretty much
forever.

Is there a reason why C++0x does not overload the algorithms to work on
types
supporting the Range concept?

Thanks,

Scott

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On May 11, 9:48 pm, Scott Meyers <use...@aristeia.com> wrote:
> C++0x specifies the Range concept and uses it in range-based for loops,
> but I
> don't see any support for it among algorithms.  The C++0x FAQ athttp://www.research.att.com/~bs/C++0xFAQ.html#conceptsnotes:
>
> > Being able to classify and distinguish different types of types, we can
>
>   > overload based on the kind of types passed. For example
>
>
>
>
>
> >    // iterator-based standard sort (with concepts):
> >    template<Random_access_iterator Iter>
> >            requires Comparable<Iter::value_type>
> >    void sort(Iter first, Iter last); // use the usual implementation
>
> >    // container-based sort:
> >    template<Container Cont>
> >            requires Comparable<Cont::value_type>
> >    void sort(Cont& c)
> >    {
> >            sort(c.begin(),c.end());    // simply call the iterator version
> >    }
>
> >    void f(vector<int>& v)
> >    {
> >            sort(v.begin(), v.end());   // one way
> >            sort(v);                    // another way
> >            // ...
> >    }
>
> I don't see such overloads in the C++0x draft, and I know that having to
> explicitly specify begin and end iterators for full-container operations
> has
> been a usability sore point among users since, well, since pretty much
> forever.
>
> Is there a reason why C++0x does not overload the algorithms to work on
> types
> supporting the Range concept?

So far as I know, nobody made a proposal that addressed all of the
issues, or even (AFAIK) one which covers the easy cases and shows that
it is consistent with a path that will later generalize to cover other
cases.  In fact I don't recall seeing *any* formal proposal to add
range-based algorithms.  There's clearly some prior art out there, but
I haven't seen a consensus that any one particular library is ready
for standardization.

There are simple cases that are uncontroversial: sort is one such.
The more interesting cases are algorithms which work on a range and
return an iterator: should their range-based counterparts continue to
return an iterator, or should they return a range?  if the latter,
which range?

-- James


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:
> C++0x specifies the Range concept and uses it in range-based for loops,
> but I
> don't see any support for it among algorithms.  The C++0x FAQ at
> http://www.research.att.com/~bs/C++0xFAQ.html#concepts notes:
>
>> Being able to classify and distinguish different types of types, we can
>  > overload based on the kind of types passed. For example
>>
>>     // iterator-based standard sort (with concepts):
>>     template<Random_access_iterator Iter>
>>         requires Comparable<Iter::value_type>
>>     void sort(Iter first, Iter last); // use the usual implementation
>>
>>     // container-based sort:
>>     template<Container Cont>
>>         requires Comparable<Cont::value_type>
>>     void sort(Cont& c)
>>     {
>>         sort(c.begin(),c.end());    // simply call the iterator version
>>     }
>>
>>     void f(vector<int>& v)
>>     {
>>         sort(v.begin(), v.end());   // one way
>>         sort(v);                    // another way
>>         // ...
>>     }
>
> I don't see such overloads in the C++0x draft, and I know that having to
> explicitly specify begin and end iterators for full-container operations
> has
> been a usability sore point among users since, well, since pretty much
> forever.
>
> Is there a reason why C++0x does not overload the algorithms to work on
> types supporting the Range concept?

Time. At some point it becomes better to ship a standard than endlessly
improve a draft.

There is a lot of interest in ranges. Andrei Alexandrescu's BoostCon
keynote last week was devoted to a more radical range approach than just
adding some overloads. But for now the C++ committee is focused on
resolving C++0x CD1 issues and getting C++0x out the door. More work on
ranges will have to wait for TR2.

--Beman

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Scott Meyers" <usenet@aristeia.com> wrote in message
news:iaadnbFeA7oS8pXXnZ2dnUVZ_v2dnZ2d@posted.hevanet...
>
> C++0x specifies the Range concept and uses it in range-based for loops, but I
> don't see any support for it among algorithms.

Range support is not complete in C++0x.
The original range proposal was N1871.

The proposal was template based, and included some basic
infrastructure, algorithm overloads (both the stand alone algorithms,
and the container member algorithms), a range class template (and
sub_range class template), and finally a powerful range adapter
utility, that creates lazy evaluated range adaptations.

I'm not fully clear on the pupose of the range class template, but I
think it was a nessisary component of the range adapters.

The end result was that the following would compile and function sanely:
int main()
{
 int array[]={8,4,6,3,7,4,4};
 std::sort(array);
 std::copy(array|std::reverse), std::ostream_iterator(std::cout, " "));
 //That prints the rvalues of array in reverse order

 std::vector<int> vec(50);
 std::generate(vec,std::rnd);

 std::vector<int> vec2(vec|std::filtered([](int x){return x%100}));
 //vec2 becomes a vector of 50 integers with values between 0 and 49 inclusive
 std::sort(vec2);
 std::copy(array|std::uniqued), std::ostream_iterator(std::cout, " "));
 //That prints the unique values vec2 in sorted order.
 return 0;
}


Now, that did not go in. We now have a range concept.
We also have a range-based for loop, and some basic infrastructure.
Range based alorthm overloads may require additional range concepts,
and definately must be checked closely, to avoid bugs in things like
const propegation.

As for range adapters, they should be possible, but are more
controversial (syntax issues among others).

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Joe Smith wrote:
> Now, that did not go in. We now have a range concept.
> We also have a range-based for loop, and some basic infrastructure.

It's unfortunate the way it turned out, IMO, because I think I'm not the
only
one taking a first serious look at C++0x and seeing that I can write a
for loop
over anything supporting ranges, but I can't do the same with for_each
or any
other algorithm.

I respect the work involved to get anything into C++0x, but looking only
at the
resulting API, range-based for-loops come across as a restricted taste
of what
continues to be otherwise forbidden fruit.

Scott

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]