Topic: add index iteration to range-based for?


Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 14 Feb 2014 16:15:42 -0500
Raw View
Q: What is the most common form of 'for' loop?
A: for (i =3D 0; i < end; ++i)

Related to a thread=C2=B9 I started on the general discussion forum,=20
something occurred to me...

Currently, writing something like 'for (auto i : 40)' is an error=20
(because there is no std::begin(int)). Would it be a horrible, horrible=20
idea to enhance the standard [library] so that such a for loop would=20
iterate over the half-open range [0, 40)? (I would assume this would=20
only apply to integer types. And probably not enum types; that might be=20
a separate proposal, but is more complicated, so I want to ignore it for=20
now.)

I use 'library' in []'s as one obvious problem is if someone has already=20
done something like this in their own code. This could be implemented so=20
as to not change the behavior of such code by implementing the feature=20
at the language level instead, i.e. only use the above-described=20
behavior if there is no std::begin for the "container", but the=20
"container" type is an integer type. So the behavior of code already=20
overloading std::begin(<integer type>) won't change, but the compiler=20
would newly fall back on zero-based, half-open index iteration if the=20
RHS type is an integer type for which no std::begin / std::end is=20
defined (which currently is an error).

(=C2=B9 http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.general/2801)

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 14 Feb 2014 13:26:32 -0800
Raw View
Em sex 14 fev 2014, =E0s 16:15:42, Matthew Woehlke escreveu:
> Currently, writing something like 'for (auto i : 40)' is an error=20
> (because there is no std::begin(int)). Would it be a horrible, horrible=
=20
> idea to enhance the standard [library] so that such a for loop would=20
> iterate over the half-open range [0, 40)?

Probably not. We should probably do, however:

 for (auto i : std::range(0, 40))

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.


Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 14 Feb 2014 16:33:48 -0500
Raw View
--001a11c25deab9498b04f2648f07
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 14, 2014 at 4:15 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:

> Q: What is the most common form of 'for' loop?
> A: for (i =3D 0; i < end; ++i)
>
> Related to a thread=B9 I started on the general discussion forum, somethi=
ng
> occurred to me...
>
> Currently, writing something like 'for (auto i : 40)' is an error (becaus=
e
> there is no std::begin(int)). Would it be a horrible, horrible idea to
> enhance the standard [library] so that such a for loop would iterate over
> the half-open range [0, 40)? (I would assume this would only apply to
> integer types. And probably not enum types; that might be a separate
> proposal, but is more complicated, so I want to ignore it for now.)
>
> I use 'library' in []'s as one obvious problem is if someone has already
> done something like this in their own code. This could be implemented so =
as
> to not change the behavior of such code by implementing the feature at th=
e
> language level instead, i.e. only use the above-described behavior if the=
re
> is no std::begin for the "container", but the "container" type is an
> integer type. So the behavior of code already overloading
> std::begin(<integer type>) won't change, but the compiler would newly fal=
l
> back on zero-based, half-open index iteration if the RHS type is an integ=
er
> type for which no std::begin / std::end is defined (which currently is an
> error).
>
>

You are not allowed to overload std::begin(int).  You can only overload
std::begin(MyType).  So no problem there..

But does range-based-for call std::begin or ADL begin()?



> (=B9 http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.general/2801)
>
> --
> Matthew
>
> --
>
> --- You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
> proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c25deab9498b04f2648f07
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Feb 14, 2014 at 4:15 PM, Matthew Woehlke <span dir=3D"ltr">=
&lt;<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_=
triad@users.sourceforge.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Q: What is the most common form of &#39;for&=
#39; loop?<br>
A: for (i =3D 0; i &lt; end; ++i)<br>
<br>
Related to a thread=B9 I started on the general discussion forum, something=
 occurred to me...<br>
<br>
Currently, writing something like &#39;for (auto i : 40)&#39; is an error (=
because there is no std::begin(int)). Would it be a horrible, horrible idea=
 to enhance the standard [library] so that such a for loop would iterate ov=
er the half-open range [0, 40)? (I would assume this would only apply to in=
teger types. And probably not enum types; that might be a separate proposal=
, but is more complicated, so I want to ignore it for now.)<br>

<br>
I use &#39;library&#39; in []&#39;s as one obvious problem is if someone ha=
s already done something like this in their own code. This could be impleme=
nted so as to not change the behavior of such code by implementing the feat=
ure at the language level instead, i.e. only use the above-described behavi=
or if there is no std::begin for the &quot;container&quot;, but the &quot;c=
ontainer&quot; type is an integer type. So the behavior of code already ove=
rloading std::begin(&lt;integer type&gt;) won&#39;t change, but the compile=
r would newly fall back on zero-based, half-open index iteration if the RHS=
 type is an integer type for which no std::begin / std::end is defined (whi=
ch currently is an error).<br>

<br></blockquote><div><br><br></div><div>You are not allowed to overload st=
d::begin(int).=A0 You can only overload std::begin(MyType).=A0 So no proble=
m there..<br><br>But does range-based-for call std::begin or ADL begin()?<b=
r>
<br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(=B9 <a href=3D"http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.gener=
al/2801" target=3D"_blank">http://permalink.gmane.org/<u></u>gmane.comp.lan=
g.c++.isocpp.<u></u>general/2801</a>)<span class=3D"HOEnZb"><font color=3D"=
#888888"><br>

<br>
-- <br>
Matthew<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</font></span></blockquote></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c25deab9498b04f2648f07--

.


Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Fri, 14 Feb 2014 22:38:25 +0100
Raw View
2014-02-14 22:33 GMT+01:00 Tony V E <tvaneerd@gmail.com>:
> You are not allowed to overload std::begin(int).  You can only overload
> std::begin(MyType).  So no problem there..

You mean specialize, right? There is no freedom to add any overloads
of functions or function template to namespace std.

> But does range-based-for call std::begin or ADL begin()?

It essentially performs ADL begin() (Ignoring member functions for the moment).

- Daniel

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 14 Feb 2014 23:39:03 +0200
Raw View
On 14 February 2014 23:33, Tony V E <tvaneerd@gmail.com> wrote:
> You are not allowed to overload std::begin(int).  You can only overload
> std::begin(MyType).  So no problem there..
> But does range-based-for call std::begin or ADL begin()?

[stmt.ranged]/1, the bulleted list:

"otherwise, begin-expr and end-expr are begin(__range) and
end(__range), respectively, where begin
and end are looked up in the associated namespaces (3.4.2). [ Note:
Ordinary unqualified lookup (3.4.1)
is not performed. -- end note ]"

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.


Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 14 Feb 2014 17:03:59 -0500
Raw View
On 2014-02-14 16:26, Thiago Macieira wrote:
> Em sex 14 fev 2014, =C3=A0s 16:15:42, Matthew Woehlke escreveu:
>> Currently, writing something like 'for (auto i : 40)' is an error
>> (because there is no std::begin(int)). Would it be a horrible, horrible
>> idea to enhance the standard [library] so that such a for loop would
>> iterate over the half-open range [0, 40)?
>
> Probably not. We should probably do, however:
>
>  for (auto i : std::range(0, 40))

That was my original thought in the 'general' thread. Although, I'll=20
note that, besides being less typing, there is less code to optimize=20
away with the unadorned integer case, even if support is library level.

Also, I feel pretty strongly that the above should support the same=20
arguments as Python, i.e. 'std::range(40)' is equivalent to what you=20
wrote. (Also, the step size I think would be nice, but I feel more=20
strongly about the single-argument with implicit start =3D=3D 0).

I'd also really like to see, if it won't make an implementation to=20
terrible, an optional parameter for the type of range (i.e. open, LCRO=20
or closed, with LCRO being default). At least closed I think would have=20
use cases (e.g. iterate over all possible values of 'char').

FWIW, I don't consider the two options orthogonal. In fact, the bare=20
number case would ideally use the iterators from 'std::range' (or=20
whatever it would be called; N3350 already proposed a "std::range" as=20
something entirely different).

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 14 Feb 2014 16:12:35 -0800
Raw View
This is a multi-part message in MIME format.

--nextPart1771136.LQ6QNKPqMr
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

Em sex 14 fev 2014, =E0s 17:03:59, Matthew Woehlke escreveu:
> FWIW, I don't consider the two options orthogonal. In fact, the bare=20
> number case would ideally use the iterators from 'std::range' (or=20
> whatever it would be called; N3350 already proposed a "std::range" as=20
> something entirely different).

std::numeric_range then. See attached.

Code generated of the two functions at the end by GCC 4.9 (minus the stack=
=20
alignment code):

_Z1gv:
        call    _Z1fv
        call    _Z1fv
        jmp     _Z1fv

_Z1hv:
        xorl    %edi, %edi
        call    _Z1fi
        movl    $2, %edi
        call    _Z1fi
        movl    $4, %edi
        jmp     _Z1fi

Or if you prefer reading LLVM (Clang 3.4):

define void @_Z1gv() #0 {
  tail call void @_Z1fv()
  tail call void @_Z1fv()
  tail call void @_Z1fv()
  ret void
}

; Function Attrs: uwtable
define void @_Z1hv() #0 {
  tail call void @_Z1fi(i32 0)
  tail call void @_Z1fi(i32 2)
  tail call void @_Z1fi(i32 4)
  ret void
}

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--nextPart1771136.LQ6QNKPqMr
Content-Disposition: attachment; filename="numeric_range.cpp"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-c++src; charset="UTF-8"; name="numeric_range.cpp"

/*
 * This file is published in the public domain by the author
 */

template <typename T>
struct numeric_range_holder
{
    struct const_iterator
    {
        T current, step;
        constexpr const_iterator(T current, T step)
            : current(current), step(step)
        {}

        T operator*() const { return current; }
        const_iterator &operator++() { current += step; return *this; }
        bool operator !=(const const_iterator &other) { return current != other.current; }
    };

    const T initial, step, final;
    constexpr numeric_range_holder(T initial, T final, T step)
        : initial(initial), step(step),
          final(recalculate_final(initial, final, step))
    {}

    const_iterator begin() const { return const_iterator(initial, step); }
    const_iterator end() const { return const_iterator(final, step); }

    constexpr static T recalculate_final(T initial, T final, T step)
    {
        return initial + (final + step - 1 - initial) / step * step;
    }
};

template <typename T>
constexpr numeric_range_holder<T> numeric_range(T final)
{
    return numeric_range_holder<T>(T(0), final, T(1));
}

template <typename T>
constexpr numeric_range_holder<T> numeric_range(T initial, T final, T step = T(1))
{
    return numeric_range_holder<T>(initial, final, step);
}

// -- TEST --
void f();
void f(int);
void g()
{
    for (auto i : numeric_range(3)) f();
}
void h()
{
    for (auto i : numeric_range(0, 5, 2)) f(i);
}

--nextPart1771136.LQ6QNKPqMr--


.


Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 12 Mar 2014 06:38:20 -0700 (PDT)
Raw View
------=_Part_531_11644150.1394631500540
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think that std::range should be a function. This could then be overloaded=
=20
to accept different types of parameters, The overloads then return differen=
t
semi-opaue objects which have begin() and end() defined. This way range(40)=
=20
does not conflict with range(vector<int>) or range (iterator, iterator).

The default implementation would probably be for a container:


template<typename C> iterator_pair_range<C::iterator> range(C& cont)
{=20
    return  iterator_pair_range<C::iterator>(std::begin(cont), std::end(con=
t
));=20
}


enable_if will have to be used to make 40 work, but that's not a big deal.

Then we can also overload range for arrays (capturing their compile time=20
size) and pointers (with a zero ending assumption) or with an explicit=20
length as second parameter.

These overloads will allow range-based algorithms on legacy data types, not=
=20
only on stl compatible containers.



Den l=C3=B6rdagen den 15:e februari 2014 kl. 01:12:35 UTC+1 skrev Thiago=20
Macieira:
>
> Em sex 14 fev 2014, =C3=A0s 17:03:59, Matthew Woehlke escreveu:=20
> > FWIW, I don't consider the two options orthogonal. In fact, the bare=20
> > number case would ideally use the iterators from 'std::range' (or=20
> > whatever it would be called; N3350 already proposed a "std::range" as=
=20
> > something entirely different).=20
>
> std::numeric_range then. See attached.=20
>
> Code generated of the two functions at the end by GCC 4.9 (minus the stac=
k=20
> alignment code):=20
>
> _Z1gv:=20
>         call    _Z1fv=20
>         call    _Z1fv=20
>         jmp     _Z1fv=20
>
> _Z1hv:=20
>         xorl    %edi, %edi=20
>         call    _Z1fi=20
>         movl    $2, %edi=20
>         call    _Z1fi=20
>         movl    $4, %edi=20
>         jmp     _Z1fi=20
>
> Or if you prefer reading LLVM (Clang 3.4):=20
>
> define void @_Z1gv() #0 {=20
>   tail call void @_Z1fv()=20
>   tail call void @_Z1fv()=20
>   tail call void @_Z1fv()=20
>   ret void=20
> }=20
>
> ; Function Attrs: uwtable=20
> define void @_Z1hv() #0 {=20
>   tail call void @_Z1fi(i32 0)=20
>   tail call void @_Z1fi(i32 2)=20
>   tail call void @_Z1fi(i32 4)=20
>   ret void=20
> }=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>       PGP/GPG: 0x6EF45358; fingerprint:=20
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358=20
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_531_11644150.1394631500540
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think that std::range should be a function. This could t=
hen be overloaded to accept different types of parameters, The overloads th=
en return different<div>semi-opaue objects which have begin() and end() def=
ined. This way range(40) does not conflict with range(vector&lt;int&gt;) or=
 range (iterator, iterator).</div><div><br></div><div>The default implement=
ation would probably be for a container:</div><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187=
, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">temp=
late</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> C</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> iterator_pair_range</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">C</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">iterator</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> range</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">C</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> cont</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> <br>&nbsp; &nbsp; </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp;iterator_pair_ra=
nge</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">C</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">iterator</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">begin</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">cont</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">),</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">end</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">cont</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">));</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> <br></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br><br></span></div></code></div><div><br><span style=
=3D"font-size: 13px;">enable_if will have to be used to make 40 work, but t=
hat's not a big deal.</span></div><div><span style=3D"font-size: 13px;"><br=
></span></div><div><span style=3D"font-size: 13px;">Then we can also overlo=
ad range for arrays (capturing their compile time size) and pointers (with =
a zero ending assumption) or with an explicit length as second parameter.</=
span></div><div><span style=3D"font-size: 13px;"><br></span></div><div><spa=
n style=3D"font-size: 13px;">These overloads will allow range-based algorit=
hms on legacy data types, not only on stl compatible containers.</span></di=
v><div><span style=3D"font-size: 13px;"><br></span></div><div><br><br>Den l=
=C3=B6rdagen den 15:e februari 2014 kl. 01:12:35 UTC+1 skrev Thiago Macieir=
a:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Em sex 14 fev 2014, =C3=A0s =
17:03:59, Matthew Woehlke escreveu:
<br>&gt; FWIW, I don't consider the two options orthogonal. In fact, the ba=
re=20
<br>&gt; number case would ideally use the iterators from 'std::range' (or=
=20
<br>&gt; whatever it would be called; N3350 already proposed a "std::range"=
 as=20
<br>&gt; something entirely different).
<br>
<br>std::numeric_range then. See attached.
<br>
<br>Code generated of the two functions at the end by GCC 4.9 (minus the st=
ack=20
<br>alignment code):
<br>
<br>_Z1gv:
<br>&nbsp; &nbsp; &nbsp; &nbsp; call &nbsp; &nbsp;_Z1fv
<br>&nbsp; &nbsp; &nbsp; &nbsp; call &nbsp; &nbsp;_Z1fv
<br>&nbsp; &nbsp; &nbsp; &nbsp; jmp &nbsp; &nbsp; _Z1fv
<br>
<br>_Z1hv:
<br>&nbsp; &nbsp; &nbsp; &nbsp; xorl &nbsp; &nbsp;%edi, %edi
<br>&nbsp; &nbsp; &nbsp; &nbsp; call &nbsp; &nbsp;_Z1fi
<br>&nbsp; &nbsp; &nbsp; &nbsp; movl &nbsp; &nbsp;$2, %edi
<br>&nbsp; &nbsp; &nbsp; &nbsp; call &nbsp; &nbsp;_Z1fi
<br>&nbsp; &nbsp; &nbsp; &nbsp; movl &nbsp; &nbsp;$4, %edi
<br>&nbsp; &nbsp; &nbsp; &nbsp; jmp &nbsp; &nbsp; _Z1fi
<br>
<br>Or if you prefer reading LLVM (Clang 3.4):
<br>
<br>define void @_Z1gv() #0 {
<br>&nbsp; tail call void @_Z1fv()
<br>&nbsp; tail call void @_Z1fv()
<br>&nbsp; tail call void @_Z1fv()
<br>&nbsp; ret void
<br>}
<br>
<br>; Function Attrs: uwtable
<br>define void @_Z1hv() #0 {
<br>&nbsp; tail call void @_Z1fi(i32 0)
<br>&nbsp; tail call void @_Z1fi(i32 2)
<br>&nbsp; tail call void @_Z1fi(i32 4)
<br>&nbsp; ret void
<br>}
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br></blockquote></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_531_11644150.1394631500540--

.


Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 12 Mar 2014 11:29:51 -0400
Raw View
On 2014-03-12 09:38, Bengt Gustafsson wrote:
> I think that std::range should be a function. This could then be overloaded
> to accept different types of parameters, The overloads then return different
> semi-opaue objects which have begin() and end() defined. This way range(40)
> does not conflict with range(vector<int>) or range (iterator, iterator).
>
> The default implementation would probably be for a container:
>
>
> template<typename C> iterator_pair_range<C::iterator> range(C& cont)
> {
>      return  iterator_pair_range<C::iterator>(std::begin(cont), std::end(cont
> ));
> }

What does "range" mean w.r.t. a container or pointer? To me, that is
very strange syntax; I would much rather name such an operator 'iterate'
than 'range'. And even then, for containers, what would be the use case?
You might as well just return the container itself for all the
difference it will make.

Let's focus on indices, as those make sense.

So we could have:

   index_range(T max)
   index_range(T begin, T end, T step = auto, options = half_open)

The 'step = auto' is optional, with auto == 0 meaning to use 1 if begin
<= end, else -1. I do also want to support closed ranges if possible...

(I agree these are functions returning an object; in fact, they must be
implemented that way for automatic type deduction to kick in, and since
*having* type deduction is sort-of the point...)


I could also see doing:

   iterate(T* ptr)

....where start() -> ptr, end() -> 'magic' object such that iter == end
is true when *iter == 0.

Or we could just standardize std::begin(T*) and std::end(T*) to have
that behavior?

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.