I saw [this][0] proposal for adding ranges to C++'s standard
library. The [paper][1] looks at D style ranges, but concludes:

> Since iterators can implement D ranges, but D ranges cannot be used to implement iterators, we conclude that iterators form a more powerful and foundational basis.

What do you guys think?

[0]: https://isocpp.org/blog/2014/10/ranges
[1]: https://ericniebler.github.io/std/wg21/D4128.html

Am Fri, 17 Oct 2014 09:17:51 +0000
schrieb "ZombineDev" <valid_email@he.re>:

> I saw [this][0] proposal for adding ranges to C++'s standard library. The [paper][1] looks at D style ranges, but concludes:
> 
> > Since iterators can implement D ranges, but D ranges cannot be used to implement iterators, we conclude that iterators form a more powerful and foundational basis.
> 
> What do you guys think?
> 
> [0]: https://isocpp.org/blog/2014/10/ranges
> [1]: https://ericniebler.github.io/std/wg21/D4128.html

True. Iterators are more foundational, ranges are more
neat-o. ;)
When you look at this C++ function as part of a signal
processing home work you know why you don't want to see them
in top level code:

// C++

double mittelwert(const vector<double>& vektor)
{
	vector<double>::const_iterator it;
	double summe = 0;
	for (it = vektor.begin(); it != vektor.end(); ++it)
	{
		summe += *it;
	}
	return summe / vektor.size();
}

// D (removing iterators)

double mittelwert(in double[] vektor)
{
	double summe = 0;
	foreach (wert; vektor)
	{
		summe += wert;
	}
	return summe / vektor.length;
}

// D (using range sum function)

double mittelwert(in double[] vektor)
{
	return sum(vektor) / vektor.length;
}

-- 
Marco

On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote:
> Am Fri, 17 Oct 2014 09:17:51 +0000
> schrieb "ZombineDev" <valid_email@he.re>:
>
>> I saw [this][0] proposal for adding ranges to C++'s standard
>> library. The [paper][1] looks at D style ranges, but concludes:
>> 
>> > Since iterators can implement D ranges, but D ranges cannot be used to implement iterators, we conclude that iterators form a more powerful and foundational basis.
>> 
>> What do you guys think?
>> 
>> [0]: https://isocpp.org/blog/2014/10/ranges
>> [1]: https://ericniebler.github.io/std/wg21/D4128.html
>
> True. Iterators are more foundational, ranges are more
> neat-o. ;)
> When you look at this C++ function as part of a signal
> processing home work you know why you don't want to see them
> in top level code:
>
> // C++
>
> double mittelwert(const vector<double>& vektor)
> {
> 	vector<double>::const_iterator it;
> 	double summe = 0;
> 	for (it = vektor.begin(); it != vektor.end(); ++it)
> 	{
> 		summe += *it;
> 	}
> 	return summe / vektor.size();
> }
>
> // D (removing iterators)
>
> double mittelwert(in double[] vektor)
> {
> 	double summe = 0;
> 	foreach (wert; vektor)
> 	{
> 		summe += wert;
> 	}
> 	return summe / vektor.length;
> }
>
> // D (using range sum function)
>
> double mittelwert(in double[] vektor)
> {
> 	return sum(vektor) / vektor.length;
> }

No, the equivalent implementation in C++ is this:

double mittelwert(const vector<double>& vektor)
{
   double summe = 0;

   for(auto &x : vektor)
   {
      summe += x;
   }

   return summe / vektor.size();
}

On Friday, 17 October 2014 at 10:10:23 UTC, Olivier Grant wrote:
> On Friday, 17 October 2014 at 09:52:26 UTC, Marco Leise wrote:
>> Am Fri, 17 Oct 2014 09:17:51 +0000
>> schrieb "ZombineDev" <valid_email@he.re>:

> No, the equivalent implementation in C++ is this:
>


double mittelwert_accumulate(const vector<double>& vektor)
{
	return accumulate(vektor.begin(), vektor.end(), 0.0) / vektor.size();
}

On Friday, 17 October 2014 at 10:17:38 UTC, eles wrote:
> double mittelwert_accumulate(const vector<double>& vektor)
> {
> 	return accumulate(vektor.begin(), vektor.end(), 0.0) / vektor.size();
> }


template<typename T>
auto mittelwert_accumulate(const T& vektor){
  return accumulate(cbegin(vektor), cend(vektor), 0.0) / distance(cbegin(a), cend(a))
}

(not tested :^)

On Friday, 17 October 2014 at 11:44:29 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 17 October 2014 at 10:17:38 UTC, eles wrote:

> (not tested :^)

template<typename T>
auto mittelwert_accumulate2(const T &vektor) ->typename T::value_type
{
  return accumulate(vektor.cbegin(), vektor.cend(), static_cast<typename T::value_type>(0)) / distance(vektor.cbegin(), vektor.cend());
}

(gcc does not yet support std::cbegin() and std::cend()).

(tested :^)

On Friday, 17 October 2014 at 13:27:37 UTC, eles wrote:
> (gcc does not yet support std::cbegin() and std::cend()).
>
> (tested :^)

Thanks ;)

Like your new version, but I don't think it will work with regular arrays and maybe the accumulator will overflow if you sum a large number of ubytes? I think C++14 will make stuff easier. :-)

On Friday, 17 October 2014 at 09:17:52 UTC, ZombineDev wrote:
> I saw [this][0] proposal for adding ranges to C++'s standard
> library. The [paper][1] looks at D style ranges, but concludes:
>
>> Since iterators can implement D ranges, but D ranges cannot be used to implement iterators, we conclude that iterators form a more powerful and foundational basis.
>
> What do you guys think?
>
> [0]: https://isocpp.org/blog/2014/10/ranges
> [1]: https://ericniebler.github.io/std/wg21/D4128.html

One problem with C++ style iterators is composition, and their exponential growth, due to their "pair" approach. Indeed, more often than not, proper iteration *requires* the "it" *already* know where the underlying iterator ends. For example, a "stride" adapter iterator would look like this:

template <typename It>
struct StrideIt
{
    It current;
    It end;
    void operator++()
    {
        ++current;
        if (current != end)
            ++current;
    }
}

Then you combine it with:
StrideId<It> sit   (it,    itend);
StrideId<It> sitend(itend, itend);
for ( ; ++it ; it != itend)
    ...

As you can see, it quickly becomes bloated and cumbersome. In particular, it takes *tons* of lines of code, traits and what not to compose. C++11's "auto" make things somewhat simpler, but it is still bloated.

Another issue is that iterators model a *pointer* abstraction. Iterators *must* have "reference_t". ranges are more generic in the sense that they simply model iteration.

*THAT SAID*, as convenient as ranges are, they do suffer from the "shrink but can't grow" issue. In particular, you can't really "cut" a range the way you can with iterators: "first, middle, last". If you are using RA ranges with slicing, it doesn't show too much. However, if you are using generic bidir ranges, on containers such as "DList", you really start to feel the pain.

My personal feeling (IMO):
- Consuming, adapting, producing data: Ranges win hands down.
- Managing, shuffling or inserting elements in a container: To be honest, I prefer iterators.

Given how C++'s STL is container-centric, whereas D's phobos is range centric, I can totally understand both sides' position.

On 10/17/14 10:13 AM, monarch_dodra wrote:

> My personal feeling (IMO):
> - Consuming, adapting, producing data: Ranges win hands down.
> - Managing, shuffling or inserting elements in a container: To be
> honest, I prefer iterators.

Dcollections solves this.

-Steve

On 10/17/14, 2:17 AM, ZombineDev wrote:
> I saw [this][0] proposal for adding ranges to C++'s standard
> library. The [paper][1] looks at D style ranges, but concludes:
>
>> Since iterators can implement D ranges, but D ranges cannot be used to
>> implement iterators, we conclude that iterators form a more powerful
>> and foundational basis.
>
> What do you guys think?
>
> [0]: https://isocpp.org/blog/2014/10/ranges
> [1]: https://ericniebler.github.io/std/wg21/D4128.html

Yeah, it's true and somewhat self-evident in the sense that structure build upward (more structure from less). In the same vein pointers are more powerful than slices and untyped data more powerful than typed data.

Andrei