Topic: New std::count() template
Author: =?UTF-8?Q?Ren=C3=A9_Eng?= <gemini67@gmail.com>
Date: Thu, 18 Sep 2014 23:42:22 -0700 (PDT)
Raw View
------=_Part_886_1114278868.1411108942316
Content-Type: text/plain; charset=UTF-8
The C++ Standard Library already contains count() and count_if() in the
algorithms library.
Both these template function return the number of elements satisfying a
certain condition.
I propose to add a third version which does not require a condition to
check:
template< class InputIt >
typename iterator_traits<InputIt>::difference_type count( InputIt first,
InputIt last );
Background:
'Real' containers like vector<>, map<> etc. provide a size() function that
returns the number of elements. Of course it would be wise to keep and use
these functions.
However, if you have a class that provides iterator semantics but does
*not* actually have a container of some kind that holds the values, then
you have to actually iterate over all values and count them to be able to
return the number. For this use case you would use the new count() template
function without condition.
Real life example: Class that contains an enumerator and provides iterators
to iterate over the values of the iterator.
--
---
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/.
------=_Part_886_1114278868.1411108942316
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The C++ Standard Library already contains count() and coun=
t_if() in the algorithms library.<br>Both these template function return th=
e number of elements satisfying a certain condition.<br><br>I propose to ad=
d a third version which does not require a condition to check:<br><div><spa=
n class=3D"mw-geshi cpp source-cpp"><span class=3D"kw1"><br>template</span>=
<span class=3D"sy1"><</span> <span class=3D"kw1">class</span> InputIt <s=
pan class=3D"kw1"></span><span class=3D"sy1">></span><p><span class=3D"k=
w1">typename</span> iterator_traits<span class=3D"sy1"><</span>InputIt<s=
pan class=3D"sy1">></span><span class=3D"sy4">::</span><span class=3D"me=
2">difference_type</span> count<span class=3D"br0">(</span> InputIt first, =
InputIt last <span class=3D"br0">)</span><span class=3D"sy4">;</span></p><p=
><br><span class=3D"sy4"></span></p><p><span class=3D"sy4">Background:<br>'=
Real' containers like vector<>, map<> etc. provide a size() fun=
ction that returns the number of elements. Of course it would be wise to ke=
ep and use these functions.<br>However, if you have a class that provides i=
terator semantics but does *not* actually have a container of some kind tha=
t holds the values, then you have to actually iterate over all values and c=
ount them to be able to return the number. For this use case you would use =
the new count() template function without condition.</span></p><p><span cla=
ss=3D"sy4">Real life example: Class that contains an enumerator and provide=
s iterators to iterate over the values of the iterator.</span></p><p><span =
class=3D"sy4"><br></span></p></span></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" 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_886_1114278868.1411108942316--
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Fri, 19 Sep 2014 07:46:07 +0100
Raw View
--Apple-Mail-63452EB4-3BCD-459B-83D4-7268571467CB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
What advantage does this give over std::distance?
> On 19 Sep 2014, at 07:42, Ren=C3=A9 Eng <gemini67@gmail.com> wrote:
>=20
> The C++ Standard Library already contains count() and count_if() in the a=
lgorithms library.
> Both these template function return the number of elements satisfying a c=
ertain condition.
>=20
> I propose to add a third version which does not require a condition to ch=
eck:
>=20
> template< class InputIt >
> typename iterator_traits<InputIt>::difference_type count( InputIt first, =
InputIt last );
>=20
>=20
>=20
> Background:
> 'Real' containers like vector<>, map<> etc. provide a size() function tha=
t returns the number of elements. Of course it would be wise to keep and us=
e these functions.
> However, if you have a class that provides iterator semantics but does *n=
ot* actually have a container of some kind that holds the values, then you =
have to actually iterate over all values and count them to be able to retur=
n the number. For this use case you would use the new count() template func=
tion without condition.
>=20
> Real life example: Class that contains an enumerator and provides iterato=
rs to iterate over the values of the iterator.
>=20
>=20
>=20
> --=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=
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-propo=
sals/.
--=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/.
--Apple-Mail-63452EB4-3BCD-459B-83D4-7268571467CB
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>What advantage does this give over=
std::distance?</div><div><br><br><br></div><div><br>On 19 Sep 2014, at 07:=
42, Ren=C3=A9 Eng <<a href=3D"mailto:gemini67@gmail.com">gemini67@gmail.=
com</a>> wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"=
ltr">The C++ Standard Library already contains count() and count_if() in th=
e algorithms library.<br>Both these template function return the number of =
elements satisfying a certain condition.<br><br>I propose to add a third ve=
rsion which does not require a condition to check:<br><div><span class=3D"m=
w-geshi cpp source-cpp"><span class=3D"kw1"><br>template</span><span class=
=3D"sy1"><</span> <span class=3D"kw1">class</span> InputIt <span class=
=3D"kw1"></span><span class=3D"sy1">></span><p><span class=3D"kw1">typen=
ame</span> iterator_traits<span class=3D"sy1"><</span>InputIt<span class=
=3D"sy1">></span><span class=3D"sy4">::</span><span class=3D"me2">differ=
ence_type</span> count<span class=3D"br0">(</span> InputIt first, InputIt l=
ast <span class=3D"br0">)</span><span class=3D"sy4">;</span></p><p><br><spa=
n class=3D"sy4"></span></p><p><span class=3D"sy4">Background:<br>'Real' con=
tainers like vector<>, map<> etc. provide a size() function tha=
t returns the number of elements. Of course it would be wise to keep and us=
e these functions.<br>However, if you have a class that provides iterator s=
emantics but does *not* actually have a container of some kind that holds t=
he values, then you have to actually iterate over all values and count them=
to be able to return the number. For this use case you would use the new c=
ount() template function without condition.</span></p><p><span class=3D"sy4=
">Real life example: Class that contains an enumerator and provides iterato=
rs to iterate over the values of the iterator.</span></p><p><span class=3D"=
sy4"><br></span></p></span></div></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" 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>
</div></blockquote></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail-63452EB4-3BCD-459B-83D4-7268571467CB--
.
Author: =?UTF-8?Q?Ren=C3=A9_Eng?= <gemini67@gmail.com>
Date: Thu, 18 Sep 2014 23:52:14 -0700 (PDT)
Raw View
------=_Part_970_798256645.1411109534805
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Mea culpa: Of course none
std::distance<> is missing in the list of algorithms of cppreference.com,=
=20
and I never used it before. So I just didn't think of it. Sorry.
Am Freitag, 19. September 2014 08:46:10 UTC+2 schrieb Jonathan Coe:
>
> What advantage does this give over std::distance?
>
>
>
>
> On 19 Sep 2014, at 07:42, Ren=C3=A9 Eng <gemi...@gmail.com <javascript:>>=
=20
> wrote:
>
> The C++ Standard Library already contains count() and count_if() in the=
=20
> algorithms library.
> Both these template function return the number of elements satisfying a=
=20
> certain condition.
>
> I propose to add a third version which does not require a condition to=20
> check:
>
> template< class InputIt >
>
> typename iterator_traits<InputIt>::difference_type count( InputIt first,=
=20
> InputIt last );
>
>
> Background:
> 'Real' containers like vector<>, map<> etc. provide a size() function tha=
t=20
> returns the number of elements. Of course it would be wise to keep and us=
e=20
> these functions.
> However, if you have a class that provides iterator semantics but does=20
> *not* actually have a container of some kind that holds the values, then=
=20
> you have to actually iterate over all values and count them to be able to=
=20
> return the number. For this use case you would use the new count() templa=
te=20
> function without condition.
>
> Real life example: Class that contains an enumerator and provides=20
> iterators to iterate over the values of the iterator.
>
>
> --=20
>
> ---=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> Visit this group at=20
> 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/.
------=_Part_970_798256645.1411109534805
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Mea culpa: Of course none<br><br>std::distance<> is =
missing in the list of algorithms of cppreference.com, and I never used it =
before. So I just didn't think of it. Sorry.<br><br><br>Am Freitag, 19. Sep=
tember 2014 08:46:10 UTC+2 schrieb Jonathan Coe:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"auto"><div>What advantage does this give over=
std::distance?</div><div><br><br><br></div><div><br>On 19 Sep 2014, at 07:=
42, Ren=C3=A9 Eng <<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"vB0tqH7DvGYJ" onmousedown=3D"this.href=3D'javascript:';return=
true;" onclick=3D"this.href=3D'javascript:';return true;">gemi...@gmail.co=
m</a>> wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"lt=
r">The C++ Standard Library already contains count() and count_if() in the =
algorithms library.<br>Both these template function return the number of el=
ements satisfying a certain condition.<br><br>I propose to add a third vers=
ion which does not require a condition to check:<br><div><span><span><br>te=
mplate</span><span><</span> <span>class</span> InputIt <span></span><spa=
n>></span><p><span>typename</span> iterator_traits<span><</span>Input=
It<span>></span><span>::</span><span>diff<wbr>erence_type</span> count<s=
pan>(</span> InputIt first, InputIt last <span>)</span><span>;</span></p><p=
><br><span></span></p><p><span>Background:<br>'Real' containers like vector=
<>, map<> etc. provide a size() function that returns the numbe=
r of elements. Of course it would be wise to keep and use these functions.<=
br>However, if you have a class that provides iterator semantics but does *=
not* actually have a container of some kind that holds the values, then you=
have to actually iterate over all values and count them to be able to retu=
rn the number. For this use case you would use the new count() template fun=
ction without condition.</span></p><p><span>Real life example: Class that c=
ontains an enumerator and provides iterators to iterate over the values of =
the iterator.</span></p><p><span><br></span></p></span></div></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
vB0tqH7DvGYJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclic=
k=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.or=
g</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"vB0tqH7DvGYJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></blockquote></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_970_798256645.1411109534805--
.
Author: Nicola Gigante <nicola.gigante@gmail.com>
Date: Fri, 19 Sep 2014 13:42:57 +0200
Raw View
Il giorno 19/set/2014, alle ore 08:52, Ren=C3=A9 Eng <gemini67@gmail.com> h=
a scritto:
>=20
> Mea culpa: Of course none
>=20
> std::distance<> is missing in the list of algorithms of cppreference.com,=
and I never used it before. So I just didn't think of it. Sorry.
>=20
It happens. Anyway, it's listed under the "Iterator library" section rather=
than as an algorithm.=20
http://en.cppreference.com/w/cpp/iterator/distance
Bye,
Nicola
--=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, 19 Sep 2014 10:23:59 -0400
Raw View
--047d7b3a83ae28818005036bda71
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Sep 19, 2014 at 7:42 AM, Nicola Gigante <nicola.gigante@gmail.com>
wrote:
> Il giorno 19/set/2014, alle ore 08:52, Ren=C3=A9 Eng <gemini67@gmail.com>=
ha
> scritto:
> >
> > Mea culpa: Of course none
> >
> > std::distance<> is missing in the list of algorithms of cppreference.co=
m,
> and I never used it before. So I just didn't think of it. Sorry.
> >
>
> It happens. Anyway, it's listed under the "Iterator library" section
> rather than as an algorithm.
>
> http://en.cppreference.com/w/cpp/iterator/distance
>
> Bye,
> Nicola
>
>
It might be nice to have one term/concept that covers all cases. a
std::count() that took a single container or 2 iterators, and automatically
handled arrays, would be nice. ie remove all the
sizeof(arr)/sizeof(arr[0]) hacks.
std::count(vec); // calls vec.size()
std::count(arr); // returns # elements of built in array
std::count(begin, end); // std::distance
etc.
std::count(container, val) overloading gets tricky, but is doable.
Tony
--=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/.
--047d7b3a83ae28818005036bda71
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Sep 19, 2014 at 7:42 AM, Nicola Gigante <span dir=3D"ltr"><<=
a href=3D"mailto:nicola.gigante@gmail.com" target=3D"_blank">nicola.gigante=
@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Il giorn=
o 19/set/2014, alle ore 08:52, Ren=C3=A9 Eng <<a href=3D"mailto:gemini67=
@gmail.com">gemini67@gmail.com</a>> ha scritto:<br>
<span class=3D"">><br>
> Mea culpa: Of course none<br>
><br>
> std::distance<> is missing in the list of algorithms of <a href=
=3D"http://cppreference.com" target=3D"_blank">cppreference.com</a>, and I =
never used it before. So I just didn't think of it. Sorry.<br>
><br>
<br>
</span>It happens. Anyway, it's listed under the "Iterator library=
" section rather than as an algorithm.<br>
<br>
<a href=3D"http://en.cppreference.com/w/cpp/iterator/distance" target=3D"_b=
lank">http://en.cppreference.com/w/cpp/iterator/distance</a><br>
<br>
Bye,<br>
Nicola<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br><br></div><div>It might be nice to have one term/concept that covers all=
cases.=C2=A0 a std::count() that took a single container or 2 iterators, a=
nd automatically handled arrays, would be nice.=C2=A0 ie remove all the siz=
eof(arr)/sizeof(arr[0]) hacks.<br><br>std::count(vec); // calls vec.size()<=
br>std::count(arr);=C2=A0 // returns # elements of built in array<br></div>=
<div>std::count(begin, end); // std::distance<br><br></div><div>etc.<br><br=
>std::count(container, val) overloading gets tricky, but is doable.<br><br>=
</div><div>Tony<br></div></div></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" 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 />
--047d7b3a83ae28818005036bda71--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 19 Sep 2014 08:01:37 -0700
Raw View
On Friday 19 September 2014 10:23:59 Tony V E wrote:
> std::count(vec); // calls vec.size()
std::distance(std::begin(vec), std::end(vec));
> std::count(arr); // returns # elements of built in array
std::distance(std::begin(arr), std::end(arr));
> std::count(begin, end); // std::distance
But the convenience would be nice, indeed.
--
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
--
---
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: Tony V E <tvaneerd@gmail.com>
Date: Fri, 19 Sep 2014 11:31:28 -0400
Raw View
--089e0160bf987122b005036ccbf8
Content-Type: text/plain; charset=UTF-8
On Fri, Sep 19, 2014 at 11:01 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Friday 19 September 2014 10:23:59 Tony V E wrote:
> > std::count(vec); // calls vec.size()
>
> std::distance(std::begin(vec), std::end(vec));
>
And if it was a map instead of a vector? Or templatized, such that I don't
know: map? vector? array?
>
> > std::count(arr); // returns # elements of built in array
>
> std::distance(std::begin(arr), std::end(arr));
>
> > std::count(begin, end); // std::distance
>
> But the convenience would be nice, indeed.
>
> --
> 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
>
> --
>
> ---
> 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/.
>
--
---
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/.
--089e0160bf987122b005036ccbf8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Sep 19, 2014 at 11:01 AM, Thiago Macieira <span dir=3D"ltr"><=
;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.o=
rg</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
>On Friday 19 September 2014 10:23:59 Tony V E wrote:<br>
> std::count(vec); // calls vec.size()<br>
<br>
</span>std::distance(std::begin(vec), std::end(vec));<br></blockquote><div>=
<br></div><div>And if it was a map instead of a vector? Or templatized, suc=
h that I don't know: map? vector? array?<br>=C2=A0<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<span class=3D""><br>
> std::count(arr);=C2=A0 // returns # elements of built in array<br>
<br>
</span>std::distance(std::begin(arr), std::end(arr));<br>
<span class=3D""><br>
> std::count(begin, end); // std::distance<br>
<br>
</span>But the convenience would be nice, indeed.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></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" 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 />
--089e0160bf987122b005036ccbf8--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 19 Sep 2014 09:52:33 -0700
Raw View
On Friday 19 September 2014 11:31:28 Tony V E wrote:
> > std::distance(std::begin(vec), std::end(vec));
>
> And if it was a map instead of a vector? Or templatized, such that I don't
> know: map? vector? array?
I just meant that this could be the implementation.
template <typename T>
typename iterator_traits<T>::difference_type count(const T &container)
{
return distance(begin(container), end(container));
}
And it looks like the std::iterator_traits partial specialisation for arrays
is missing. The begin/end overloads for them are there.
--
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
--
---
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: Myriachan <myriachan@gmail.com>
Date: Fri, 19 Sep 2014 20:00:05 -0700 (PDT)
Raw View
------=_Part_4569_476474635.1411182005277
Content-Type: text/plain; charset=UTF-8
On Friday, September 19, 2014 9:52:40 AM UTC-7, Thiago Macieira wrote:
>
> On Friday 19 September 2014 11:31:28 Tony V E wrote:
> > > std::distance(std::begin(vec), std::end(vec));
> >
> > And if it was a map instead of a vector? Or templatized, such that I
> don't
> > know: map? vector? array?
>
> I just meant that this could be the implementation.
>
> template <typename T>
> typename iterator_traits<T>::difference_type count(const T &container)
> {
> return distance(begin(container), end(container));
> }
>
> And it looks like the std::iterator_traits partial specialisation for
> arrays
> is missing. The begin/end overloads for them are there.
>
>
std::count ought to have a separate specialization for arrays so that we
can *finally* have a built-in "countof" equivalent in the language after
two and a half decades:
template <typename T, size_t S>
constexpr size_t count(const T (&)[S])
{
return S;
}
(The important part being that std::distance is not constexpr, and pointer
subtraction is not legal in a *core-constant-expression*...? cppreference
says so but I didn't find that text in the Standard in a quick look.)
This won't support volatile arrays, but that's still a vast improvement
over nothing at all.
Melissa
--
---
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/.
------=_Part_4569_476474635.1411182005277
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, September 19, 2014 9:52:40 AM UTC-7, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Friday 19 Septe=
mber 2014 11:31:28 Tony V E wrote:
<br>> > std::distance(std::begin(vec), std::end(vec));
<br>>=20
<br>> And if it was a map instead of a vector? Or templatized, such that=
I don't
<br>> know: map? vector? array?
<br>
<br>I just meant that this could be the implementation.
<br>
<br>template <typename T>
<br>typename iterator_traits<T>::<wbr>difference_type count(const T &=
amp;container)
<br>{
<br> return distance(begin(c=
ontainer), end(container));
<br>}
<br>
<br>And it looks like the std::iterator_traits partial specialisation for a=
rrays=20
<br>is missing. The begin/end overloads for them are there.
<br><br></blockquote><div><br><span style=3D"font-family: courier new,monos=
pace;">std::count</span> ought to have a separate specialization for arrays=
so that we can <i>finally</i> have a built-in "countof" equivalent in the =
language after two and a half decades:<br><br><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">template</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
size_t S</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> size_t count</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> T </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(&)[</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">S</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">])</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> S</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></=
div></code></div><br>(The important part being that <span style=3D"font-fam=
ily: courier new,monospace;">std::distance</span> is not <span style=3D"fon=
t-family: courier new,monospace;">constexpr</span>, and pointer subtraction=
is not legal in a <i>core-constant-expression</i>...? cppreference s=
ays so but I didn't find that text in the Standard in a quick look.)<br><br=
>This won't support volatile arrays, but that's still a vast improvement ov=
er nothing at all.<br><br>Melissa<br></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" 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_4569_476474635.1411182005277--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 20 Sep 2014 12:52:05 +0800
Raw View
--Apple-Mail=_F79230C6-A620-442D-B0BF-89EC15A1922E
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-20, at 11:00 AM, Myriachan <myriachan@gmail.com> wrote:
> (The important part being that std::distance is not constexpr, and pointer subtraction is not legal in a core-constant-expression...? cppreference says so but I didn't find that text in the Standard in a quick look.)
C++11 forbids "a subtraction (5.7) where both operands are pointers" in the list of constant expression don't-do's. C++14 legalized it already.
> This won't support volatile arrays, but that's still a vast improvement over nothing at all.
Another overload will fix that, if additional volatile qualification wouldn't (I won't ask why not).
std::count would be a parallel to std::begin and std::end, but I don't understand why it should also have an iterator-pair overload with the same result as std::distance.
--
---
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/.
--Apple-Mail=_F79230C6-A620-442D-B0BF-89EC15A1922E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–20, at 11:00 AM, Myriachan <<a href=3D"mailto:myriachan@g=
mail.com">myriachan@gmail.com</a>> wrote:</div><br class=3D"Apple-interc=
hange-newline"><blockquote type=3D"cite"><div style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=
=3D"ltr"><div>(The important part being that<span class=3D"Apple-converted-=
space"> </span><span style=3D"font-family: 'courier new', monospace;">=
std::distance</span><span class=3D"Apple-converted-space"> </span>is n=
ot<span class=3D"Apple-converted-space"> </span><span style=3D"font-fa=
mily: 'courier new', monospace;">constexpr</span>, and pointer subtraction =
is not legal in a<span class=3D"Apple-converted-space"> </span><i>core=
-constant-expression</i>...? cppreference says so but I didn't find t=
hat text in the Standard in a quick look.)<br></div></div></div></blockquot=
e><div><br></div><div>C++11 forbids "a subtraction (5.7) where both operand=
s are pointers” in the list of constant expression don’t-do&rsq=
uo;s. C++14 legalized it already.</div><br><blockquote type=3D"cite"><div s=
tyle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-v=
ariant: normal; font-weight: normal; letter-spacing: normal; line-height: n=
ormal; orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-st=
roke-width: 0px;"><div dir=3D"ltr"><div>This won't support volatile arrays,=
but that's still a vast improvement over nothing at all.<br></div></div></=
div></blockquote><div><br></div><div>Another overload will fix that, if add=
itional volatile qualification wouldn’t (I won’t ask why not).<=
/div></div><br><div><font face=3D"Courier">std::count</font> would be a par=
allel to <font face=3D"Courier">std::begin</font> and <font face=3D"Courier=
">std::end</font>, but I don’t understand why it should also have an =
iterator-pair overload with the same result as <font face=3D"Courier">std::=
distance</font>.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_F79230C6-A620-442D-B0BF-89EC15A1922E--
.
Author: Myriachan <myriachan@gmail.com>
Date: Fri, 19 Sep 2014 22:32:48 -0700 (PDT)
Raw View
------=_Part_2300_901975521.1411191168684
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, September 19, 2014 9:52:25 PM UTC-7, David Krauss wrote:
>
>
> On 2014=E2=80=9309=E2=80=9320, at 11:00 AM, Myriachan <myri...@gmail.com =
<javascript:>>=20
> wrote:
>
> (The important part being that std::distance is not constexpr, and=20
> pointer subtraction is not legal in a *core-constant-expression*...? =20
> cppreference says so but I didn't find that text in the Standard in a qui=
ck=20
> look.)
>
>
> C++11 forbids "a subtraction (5.7) where both operands are pointers=E2=80=
=9D in=20
> the list of constant expression don=E2=80=99t-do=E2=80=99s. C++14 legaliz=
ed it already.
>
Ah OK, it's just a cppreference.com C++14 omission, then. std::distance=20
not being constexpr is the more fundamental problem, though.
> This won't support volatile arrays, but that's still a vast improvement=
=20
> over nothing at all.
>
>
> Another overload will fix that, if additional volatile qualification=20
> wouldn=E2=80=99t (I won=E2=80=99t ask why not).
>
>
I don't know whether it is a language rule or it is a GCC bug, but GCC=20
rejects attempts to pass volatile arrays to constexpr functions with:
prog.cc: In function 'int main()':
prog.cc:18:94: error: expression 'meow' has side-effects
volatile int meow[5]; std::printf("%zu\n",=20
std::integral_constant<std::size_t, count(meow)>::value);
=
=20
^
I think GCC is complaining because of this rule [expr.const]/2.7:
2. A *conditional-expression* e is a *core constant expression* unless the=
=20
evaluation of e, following the rules of the
abstract machine (1.9), would evaluate one of the following expressions:
....
=E2=80=94 an lvalue-to-rvalue conversion (4.1) unless it is applied to
=E2=80=94 a non-volatile glvalue of integral or enumeration type that r=
efers to=20
a non-volatile const object with
a preceding initialization, initialized with a constant expression=
=20
[ *Note:* a string literal (2.14.5)
corresponds to an array of such objects. =E2=80=94*end note* ], or
=E2=80=94 a non-volatile glvalue that refers to a non-volatile object d=
efined=20
with constexpr, or that refers
to a non-mutable sub-object of such an object, or
=E2=80=94 a non-volatile glvalue of literal type that refers to a non-v=
olatile=20
object whose lifetime began
within the evalution of e;
(Nice typo there with "evalution"...GitHub is far too difficult to use and=
=20
understand in order for me to report it, though. Go figure that it's much=
=20
easier to report substantive errors than trivial errors.)
meow didn't exist before evaluation of e, sure, but is an lvalue-to-rvalue=
=20
conversion happening? It's initializing an lvalue reference, not=20
converting an lvalue to an rvalue, right? Clang accepts it, so maybe it's=
=20
just a GCC bug.
Melissa
--=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_2300_901975521.1411191168684
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, September 19, 2014 9:52:25 PM UTC-7, David Krau=
ss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wr=
ap:break-word"><br><div><div>On 2014=E2=80=9309=E2=80=9320, at 11:00 AM, My=
riachan <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"WEOoxdeXtIUJ" onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;">myri...@gmail.com</a>> =
wrote:</div><br><blockquote type=3D"cite"><div style=3D"font-family:Helveti=
ca;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;=
letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;t=
ext-transform:none;white-space:normal;word-spacing:0px"><div dir=3D"ltr"><d=
iv>(The important part being that<span> </span><span style=3D"font-fam=
ily:'courier new',monospace">std::distance</span><span> </span>is not<=
span> </span><span style=3D"font-family:'courier new',monospace">const=
expr</span>, and pointer subtraction is not legal in a<span> </span><i=
>core-constant-expression</i>...?<wbr> cppreference says so but I did=
n't find that text in the Standard in a quick look.)<br></div></div></div><=
/blockquote><div><br></div><div>C++11 forbids "a subtraction (5.7) where bo=
th operands are pointers=E2=80=9D in the list of constant expression don=E2=
=80=99t-do=E2=80=99s. C++14 legalized it already.</div></div></div></blockq=
uote><div><br>Ah OK, it's just a cppreference.com C++14 omission, then.&nbs=
p; <span style=3D"font-family: courier new,monospace;">std::distance</span>=
not being constexpr is the more fundamental problem, though.<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div><div><blockquote type=3D"cite=
"><div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font=
-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal=
;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px"><div dir=3D"ltr"><div>This won't support volatile arrays, b=
ut that's still a vast improvement over nothing at all.<br></div></div></di=
v></blockquote><div><br></div><div>Another overload will fix that, if addit=
ional volatile qualification wouldn=E2=80=99t (I won=E2=80=99t ask why not)=
..</div></div><br></div></blockquote><div><br>I don't know whether it is a l=
anguage rule or it is a GCC bug, but GCC rejects attempts to pass <span sty=
le=3D"font-family: courier new,monospace;">volatile</span> arrays to <span =
style=3D"font-family: courier new,monospace;">constexpr</span> functions wi=
th:<br><br><span style=3D"font-family: courier new,monospace;">prog.cc: In =
function 'int main()':<br>prog.cc:18:94: error: expression 'meow' has side-=
effects<br> volatile int meow[5]; std::printf("%zu\n", st=
d::integral_constant<std::size_t, count(meow)>::value);<br> =
=
&nb=
sp; =
&n=
bsp; =
=
=
=
 =
; =
=
^<=
br></span><br>I think GCC is complaining because of this rule [expr.const]/=
2.7:<br><br>2. A <i>conditional-expression</i> <span style=3D"font-family: =
courier new,monospace;">e</span> is a <i>core constant expression</i> unles=
s the evaluation of <span style=3D"font-family: courier new,monospace;">e</=
span>, following the rules of the<br>abstract machine (1.9), would evaluate=
one of the following expressions:<br>...<br>=E2=80=94 an lvalue-to-rvalue =
conversion (4.1) unless it is applied to<br> =E2=80=94 a =
non-volatile glvalue of integral or enumeration type that refers to a non-v=
olatile const object with<br> a p=
receding initialization, initialized with a constant expression [ <i>Note:<=
/i> a string literal (2.14.5)<br> correspon=
ds to an array of such objects. =E2=80=94<i>end note</i> ], or<br> &nb=
sp; =E2=80=94 a non-volatile glvalue that refers to a non-volatile ob=
ject defined with <span style=3D"font-family: courier new,monospace;">const=
expr</span>, or that refers<br> t=
o a non-mutable sub-object of such an object, or<br> =E2=
=80=94 a non-volatile glvalue of literal type that refers to a non-volatile=
object whose lifetime began<br> =
within the evalution of <span style=3D"font-family: courier new,monospace;"=
>e</span>;<br><br>(Nice typo there with "evalution"...GitHub is far too dif=
ficult to use and understand in order for me to report it, though. Go=
figure that it's much easier to report substantive errors than trivial err=
ors.)<br><br><span style=3D"font-family: courier new,monospace;">meow</span=
> didn't exist before evaluation of <span style=3D"font-family: courier new=
,monospace;">e</span>, sure, but is an lvalue-to-rvalue conversion happenin=
g? It's initializing an lvalue reference, not converting an lvalue to=
an rvalue, right? Clang accepts it, so maybe it's just a GCC bug.<br=
><br>Melissa<br></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" 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_2300_901975521.1411191168684--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 20 Sep 2014 14:31:34 +0800
Raw View
--Apple-Mail=_DEA48E03-96EA-444B-880C-A41278773293
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-20, at 1:32 PM, Myriachan <myriachan@gmail.com> wrote:
> I think GCC is complaining because of this rule [expr.const]/2.7:
>
> 2. A conditional-expression e is a core constant expression unless the evaluation of e, following the rules of the
> abstract machine (1.9), would evaluate one of the following expressions:
> ...
> -- an lvalue-to-rvalue conversion (4.1) unless it is applied to
I don't think that count(meow) should cause any lvalue-to-rvalue conversion.
Clang accepts the example, but it still does even without volatile qualification on the parameter. The only way I can imagine that working is by performing lvalue-to-rvalue conversion on the entire array argument, which would have side effects.
GCC continues to insist there is a side effect in evaluating the id-expression meow, even if the lvalue-to-rvalue conversion is totally excluded by passing &meow by address. And, it likewise freely discards the volatile qualifier even with -pedantic.
Bah. Not really worth worrying about, I guess.
--
---
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/.
--Apple-Mail=_DEA48E03-96EA-444B-880C-A41278773293
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–20, at 1:32 PM, Myriachan <<a href=3D"mailto:myriachan@gm=
ail.com">myriachan@gmail.com</a>> wrote:</div><br class=3D"Apple-interch=
ange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div>I think GCC i=
s complaining because of this rule [expr.const]/2.7:<br><br>2. A <i>conditi=
onal-expression</i> <span style=3D"font-family: courier new,monospace;">e</=
span> is a <i>core constant expression</i> unless the evaluation of <span s=
tyle=3D"font-family: courier new,monospace;">e</span>, following the rules =
of the<br>abstract machine (1.9), would evaluate one of the following expre=
ssions:<br>...<br>— an lvalue-to-rvalue conversion (4.1) unless it is=
applied to<br></div></div></blockquote><div><br></div><div>I don’t t=
hink that <font face=3D"Courier">count(meow)</font> should cause any lvalue=
-to-rvalue conversion.</div><div><br></div><div>Clang accepts the example, =
but it still does even without <font face=3D"Courier">volatile</font> quali=
fication on the parameter. The only way I can imagine that working is by pe=
rforming lvalue-to-rvalue conversion on the entire array argument, which wo=
uld have side effects.</div><div><br></div><div>GCC continues to insist the=
re is a side effect in evaluating the id-expression <font face=3D"Cour=
ier">meow</font>, even if the lvalue-to-rvalue conversion is totally exclud=
ed by passing <font face=3D"Courier">&meow</font> by address. And,=
it likewise freely discards the <span style=3D"font-family: Courier;"=
>volatile</span> qualifier even with <font face=3D"Courier">-pedantic<=
/font>.</div><div><br></div><div>Bah. Not really worth worrying about, I gu=
ess.</div></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_DEA48E03-96EA-444B-880C-A41278773293--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 23 Sep 2014 15:14:27 -0700
Raw View
--047d7b3a7e30fd096d0503c2e377
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Sep 19, 2014 at 11:31 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9309=E2=80=9320, at 1:32 PM, Myriachan <myriachan@gmail.com=
> wrote:
>
> I think GCC is complaining because of this rule [expr.const]/2.7:
>
> 2. A *conditional-expression* e is a *core constant expression* unless
> the evaluation of e, following the rules of the
> abstract machine (1.9), would evaluate one of the following expressions:
> ...
> =E2=80=94 an lvalue-to-rvalue conversion (4.1) unless it is applied to
>
>
> I don=E2=80=99t think that count(meow) should cause any lvalue-to-rvalue
> conversion.
>
> Clang accepts the example, but it still does even without volatile
> qualification on the parameter. The only way I can imagine that working i=
s
> by performing lvalue-to-rvalue conversion on the entire array argument,
> which would have side effects.
>
If I've correctly understood what code you tested...
template <typename T, size_t S> constexpr size_t count(const T (&)[S]) {
return S; }
volatile int meow[5];
std::printf("%zu\n", std::integral_constant<std::size_t,
count(meow)>::value);
.... it's just deducing T=3Dvolatile int, S =3D 5, then binding the resultin=
g
const volatile int (&)[5] directly to the array.
> GCC continues to insist there is a side effect in evaluating the
> id-expression meow, even if the lvalue-to-rvalue conversion is totally
> excluded by passing &meow by address. And, it likewise freely discards
> the volatile qualifier even with -pedantic.
>
> Bah. Not really worth worrying about, I guess.
>
> --
>
> ---
> 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/.
--047d7b3a7e30fd096d0503c2e377
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Sep 19, 2014 at 11:31 PM, David Krauss <span dir=3D"ltr"><<a href=3D=
"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><s=
pan class=3D""><div>On 2014=E2=80=9309=E2=80=9320, at 1:32 PM, Myriachan &l=
t;<a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.=
com</a>> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div=
>I think GCC is complaining because of this rule [expr.const]/2.7:<br><br>2=
.. A <i>conditional-expression</i> <span style=3D"font-family:'courier n=
ew',monospace">e</span> is a <i>core constant expression</i> unless the=
evaluation of <span style=3D"font-family:'courier new',monospace">=
e</span>, following the rules of the<br>abstract machine (1.9), would evalu=
ate one of the following expressions:<br>...<br>=E2=80=94 an lvalue-to-rval=
ue conversion (4.1) unless it is applied to<br></div></div></blockquote><di=
v><br></div></span><div>I don=E2=80=99t think that <font face=3D"Courier">c=
ount(meow)</font> should cause any lvalue-to-rvalue conversion.</div><div><=
br></div><div>Clang accepts the example, but it still does even without <fo=
nt face=3D"Courier">volatile</font> qualification on the parameter. The onl=
y way I can imagine that working is by performing lvalue-to-rvalue conversi=
on on the entire array argument, which would have side effects.</div></div>=
</div></blockquote><div><br></div><div>If I've correctly understood wha=
t code you tested...</div><div><br></div><div><div>=C2=A0 template <type=
name T, size_t S> constexpr size_t count(const T (&)[S]) { return S;=
}</div></div><div><div>=C2=A0 volatile int meow[5];</div><div>=C2=A0 std::=
printf("%zu\n", std::integral_constant<std::size_t, count(meow=
)>::value);</div></div><div><br></div><div>... it's just deducing T=
=3Dvolatile int, S =3D 5, then binding the resulting const volatile int (&a=
mp;)[5] directly to the array.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word"><div><div>GCC continues to insist there is a=
side effect in evaluating the id-expression=C2=A0<font face=3D"Courier">me=
ow</font>, even if the lvalue-to-rvalue conversion is totally excluded by p=
assing=C2=A0<font face=3D"Courier">&meow</font> by address. And, it lik=
ewise freely discards the=C2=A0<span style=3D"font-family:Courier">volatile=
</span>=C2=A0qualifier even with <font face=3D"Courier">-pedantic</font>.</=
div><div><br></div><div>Bah. Not really worth worrying about, I guess.</div=
></div><br></div><div class=3D""><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@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/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></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" 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 />
--047d7b3a7e30fd096d0503c2e377--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 24 Sep 2014 06:38:09 +0800
Raw View
--Apple-Mail=_CB04B643-FE53-4B79-B416-3525DAD9E7F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-24, at 6:14 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> template <typename T, size_t S> constexpr size_t count(const T (&)[S]) =
{ return S; }
> volatile int meow[5];
> std::printf("%zu\n", std::integral_constant<std::size_t, count(meow)>::=
value);
>=20
> ... it's just deducing T=3Dvolatile int, S =3D 5, then binding the result=
ing const volatile int (&)[5] directly to the array.
Yes, looks like I forgot that qualified types may be deduced. The const & o=
verload is alone sufficient because a const & parameter binds to anything. =
A universal reference would also work. Replacing the typename T parameter w=
ith int causes Clang to complain. Sorry for the noise!
--=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/.
--Apple-Mail=_CB04B643-FE53-4B79-B416-3525DAD9E7F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–24, at 6:14 AM, Richard Smith <<a href=3D"mailto:richard@=
metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; line-height: normal; orphans: auto;=
text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>&n=
bsp; template <typename T, size_t S> constexpr size_t count(const T (=
&)[S]) { return S; }</div><div><div> volatile int meow[5];</div><=
div> std::printf("%zu\n", std::integral_constant<std::size_t, coun=
t(meow)>::value);</div></div><div><br></div><div>... it's just deducing =
T=3Dvolatile int, S =3D 5, then binding the resulting const volatile int (&=
amp;)[5] directly to the array.</div></div></div></div></div></blockquote><=
div><br></div><div>Yes, looks like I forgot that qualified types may be ded=
uced. The <font face=3D"Courier">const &</font> overload is alone suffi=
cient because a <font face=3D"Courier">const &</font> parameter binds t=
o anything. A universal reference would also work. Replacing the <font face=
=3D"Courier">typename T</font> parameter with <font face=3D"Courier">int</f=
ont> causes Clang to complain. Sorry for the noise!</div></div><br></body><=
/html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_CB04B643-FE53-4B79-B416-3525DAD9E7F3--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 02 Oct 2014 18:35:43 -0400
Raw View
On 2014-09-19 10:23, Tony V E wrote:
> It might be nice to have one term/concept that covers all cases. a
> std::count() that took a single container or 2 iterators, and automatically
> handled arrays, would be nice. ie remove all the
> sizeof(arr)/sizeof(arr[0]) hacks.
In fact I was just thinking this the other day, in a different context.
One of these days I'm going to try again at std::index_range (or
whatever color that bikeshed is these days), and one thing I'd love to
see is the ability to pass a counter /or container/. For the container
case I was going to have it use a std::count or such that could be
overloaded by users (in the manner of begin/end) to work on custom
container types.
In general I think it would be a good idea to have a std::count that can
take a container type (including user-defined types) and return the
number of items.
To Thiago's comment... taking the distance of begin() to end() might be
very inefficient for some container types (e.g. think of a linked list
container that keeps a node count; its ::size() might be O(1), but
std::distance would be O(N)).
--
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/.
.