Topic: Generic std::size, a la std::begin
Author: Jeaye Wilkerson <contact@jeaye.com>
Date: Wed, 1 Oct 2014 01:00:55 -0700 (PDT)
Raw View
------=_Part_1001_708181512.1412150455215
Content-Type: text/plain; charset=UTF-8
Folks,
The stdlib could use a few new function templates to aid in creating
generic interfaces. With C++11, we were given std::begin to account for the
fact that C-style arrays are valid containers. I propose we add a very
similar set of functions of accessing the size of containers, including
C-style arrays. The interface is as follows:
template <typename T>
auto size(T &c);
template <typename T>
auto size(T const &c);
template <typename T, std::size_t N>
std::size_t constexpr size(T (&arr)[N]);
A working implementation and some example code is included here:
http://coliru.stacked-crooked.com/a/a321818e19f0efae
The two main benefits of this addition are as follows:
1. Support for C-style arrays in generic implementations; this also
makes the std::xxx_n series more compatible with C-style arrays
2. Allowance of user-provided fully specialized versions of std::size
for custom types
An example of 2 being: http://coliru.stacked-crooked.com/a/12c71f9970e37463
Regards,
Jeaye
--
---
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_1001_708181512.1412150455215
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Folks,<br><br>The stdlib could use a few new function temp=
lates to aid in creating generic interfaces. With C++11, we were given std:=
:begin to account for the fact that C-style arrays are valid containers. I =
propose we add a very similar set of functions of accessing the size of con=
tainers, including C-style arrays. The interface is as follows:<br><br><div=
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #008;" class=3D"styled-by-prettify">template</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><pre><a name=3D"line-2"></a><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> size</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">T </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">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><a name=3D"line-3"></a><span style=3D"color: #008;" class=3D"style=
d-by-prettify">template</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ty=
pename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><a name=
=3D"line-4"></a><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> size</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">T </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">c</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><a name=3D"line-5"></a><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">template</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">size_t N</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><a name=3D"line-6=
"></a><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">size_t </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> size</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">T </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(&</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">arr</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">)[</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">N</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]);=
</span></pre></div></code></div><br>A working implementation and some examp=
le code is included here: <a href=3D"http://coliru.stacked-crooked.com/a/a3=
21818e19f0efae">http://coliru.stacked-crooked.com/a/a321818e19f0efae</a><br=
><br>The two main benefits of this addition are as follows:<br><ol><li>Supp=
ort for C-style arrays in generic implementations; this also makes the std:=
:xxx_n series more compatible with C-style arrays</li><li>Allowance of user=
-provided fully specialized versions of std::size for custom types</li></ol=
><p>An example of 2 being: <a href=3D"http://coliru.stacked-crooked.com/a/1=
2c71f9970e37463">http://coliru.stacked-crooked.com/a/12c71f9970e37463</a></=
p><p>Regards,<br>Jeaye<br></p></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_1001_708181512.1412150455215--
.
Author: Jeaye <contact@jeaye.com>
Date: Sat, 4 Oct 2014 08:44:46 +0800
Raw View
I should note, the current alternative is
std::distance(std::begin(arr), std::end(arr))
which is
1. Not constexpr
2. Terribly verbose
Regards,
Jeaye
On Wed, Oct 01, 2014 at 01:00:55AM -0700, Jeaye Wilkerson wrote:
> Folks,
>=20
> The stdlib could use a few new function templates to aid in creating
> generic interfaces. With C++11, we were given std::begin to account fo=
r
> the fact that C-style arrays are valid containers. I propose we add a =
very
> similar set of functions of accessing the size of containers, includin=
g
> C-style arrays. The interface is as follows:
>=20
> template <typename T>
>=20
> auto size(T &c);
> template <typename T>
> auto size(T const &c);
> template <typename T, std::size_t N>
> std::size_t constexpr size(T (&arr)[N]);
>=20
> A working implementation and some example code is included here:
> [1]http://coliru.stacked-crooked.com/a/a321818e19f0efae
>=20
> The two main benefits of this addition are as follows:
>=20
> =C2=A01.=C2=A0Support for C-style arrays in generic implementations; t=
his also makes
> the std::xxx_n series more compatible with C-style arrays
> =C2=A02.=C2=A0Allowance of user-provided fully specialized versions of=
std::size for
> custom types
>=20
> An example of 2 being:
> [2]http://coliru.stacked-crooked.com/a/12c71f9970e37463
>=20
> Regards,
> Jeaye
>=20
> --
>=20
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> [3]https://groups.google.com/a/isocpp.org/d/topic/std-proposals/KyWbsV=
meGgY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [4]std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to [5]std-proposals@isocpp.org.
> Visit this group at
> [6]http://groups.google.com/a/isocpp.org/group/std-proposals/.
>=20
> References
>=20
> Visible links
> 1. http://coliru.stacked-crooked.com/a/a321818e19f0efae
> 2. http://coliru.stacked-crooked.com/a/12c71f9970e37463
> 3. https://groups.google.com/a/isocpp.org/d/topic/std-proposals/KyWbsV=
meGgY/unsubscribe
> 4. mailto:std-proposals+unsubscribe@isocpp.org
> 5. mailto:std-proposals@isocpp.org
> 6. 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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 4 Oct 2014 17:52:28 +0800
Raw View
--Apple-Mail=_61C8EF7C-43D2-47E3-A835-336D8EC30242
Content-Type: text/plain; charset=ISO-8859-1
On 2014-10-04, at 8:44 AM, Jeaye <contact@jeaye.com> wrote:
> I should note, the current alternative is
>
> std::distance(std::begin(arr), std::end(arr))
>
> which is
>
> 1. Not constexpr
Only because of distance. It might be reasonable to allow constexpr distance for RAIs because the complexity is O(1).
> 2. Terribly verbose
Yes, this is a good reason.
>> 2. Allowance of user-provided fully specialized versions of std::size for
>> custom types
I suppose you could make an enumeration look simultaneously like a non-class container and an OutputIterator by defining begin, end, and (free function) operator*, but that's a bit of a hack. I can't think of another use.
--
---
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=_61C8EF7C-43D2-47E3-A835-336D8EC30242
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;10–04, at 8:44 AM, Jeaye <<a href=3D"mailto:contact@jeaye.co=
m">contact@jeaye.com</a>> wrote:</div><br class=3D"Apple-interchange-new=
line"><blockquote type=3D"cite">I should note, the current alternative is<b=
r><br>std::distance(std::begin(arr), std::end(arr))<br><br>which is<br><br>=
1. Not constexpr<br></blockquote><div><br></div><div>Only because of=
<font face=3D"Courier">distance</font>. It might be reasonable to allow co=
nstexpr <font face=3D"Courier">distance</font> for RAIs because the complex=
ity is O(1).</div><br><blockquote type=3D"cite"> 2. Terribly verbose<=
br></blockquote><div><br></div><div>Yes, this is a good reason.</div><br><b=
lockquote type=3D"cite"><blockquote type=3D"cite"> 2. Allo=
wance of user-provided fully specialized versions of std::size for<br> &nbs=
p; custom types<br></blockquote></blockquote><=
/div><br><div>I suppose you could make an enumeration look simultaneously l=
ike a non-class container and an OutputIterator by defining begin, end, and=
(free function) operator*, but that’s a bit of a hack. I can’t=
think of another use.</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=_61C8EF7C-43D2-47E3-A835-336D8EC30242--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Sat, 4 Oct 2014 14:21:15 +0200
Raw View
2014-10-01 10:00 GMT+02:00 Jeaye Wilkerson <contact@jeaye.com>:
> Folks,
>
> The stdlib could use a few new function templates to aid in creating generic
> interfaces. With C++11, we were given std::begin to account for the fact
> that C-style arrays are valid containers. I propose we add a very similar
> set of functions of accessing the size of containers, including C-style
> arrays. The interface is as follows:
>
> template <typename T>
>
> auto size(T &c);
> template <typename T>
> auto size(T const &c);
> template <typename T, std::size_t N>
> std::size_t constexpr size(T (&arr)[N]);
>
> A working implementation and some example code is included here:
> http://coliru.stacked-crooked.com/a/a321818e19f0efae
>
> The two main benefits of this addition are as follows:
>
> Support for C-style arrays in generic implementations; this also makes the
> std::xxx_n series more compatible with C-style arrays
> Allowance of user-provided fully specialized versions of std::size for
> custom types
>
> An example of 2 being: http://coliru.stacked-crooked.com/a/12c71f9970e37463
Have you looked at the existing proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4017.htm
and if so what is the difference of your proposal?
I should add that for the upcoming mailing deadline a revision of this
proposal has already been submitted, so this is ongoing work.
- 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: Myriachan <myriachan@gmail.com>
Date: Sat, 4 Oct 2014 12:35:46 -0700 (PDT)
Raw View
------=_Part_850_1334767148.1412451346301
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, October 4, 2014 5:21:17 AM UTC-7, Daniel Kr=C3=BCgler wrote:
>
> 2014-10-01 10:00 GMT+02:00 Jeaye Wilkerson <con...@jeaye.com <javascript:=
>>:=20
>
> > Folks,=20
> >=20
> > The stdlib could use a few new function templates to aid in creating=20
> generic=20
> > interfaces. With C++11, we were given std::begin to account for the fac=
t=20
> > that C-style arrays are valid containers. I propose we add a very=20
> similar=20
> > set of functions of accessing the size of containers, including C-style=
=20
> > arrays. The interface is as follows:=20
> >=20
> > template <typename T>=20
> >=20
> > auto size(T &c);=20
> > template <typename T>=20
> > auto size(T const &c);=20
> > template <typename T, std::size_t N>=20
> > std::size_t constexpr size(T (&arr)[N]);=20
> >=20
> > A working implementation and some example code is included here:=20
> > http://coliru.stacked-crooked.com/a/a321818e19f0efae=20
> >=20
> > The two main benefits of this addition are as follows:=20
> >=20
> > Support for C-style arrays in generic implementations; this also makes=
=20
> the=20
> > std::xxx_n series more compatible with C-style arrays=20
> > Allowance of user-provided fully specialized versions of std::size for=
=20
> > custom types=20
> >=20
> > An example of 2 being:=20
> http://coliru.stacked-crooked.com/a/12c71f9970e37463=20
>
> Have you looked at the existing proposal:=20
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4017.htm=20
>
> and if so what is the difference of your proposal?=20
>
> I should add that for the upcoming mailing deadline a revision of this=20
> proposal has already been submitted, so this is ongoing work.=20
>
> - Daniel=20
>
Naming that std::size seems awkward given that the built-in operator sizeof=
=20
would do something very different, but I understand wanting the orthogonal=
=20
functionality of the global functions. (I wish STL had named the member=20
functions count() instead of size()... grr.)
I wish it were possible to make some function, template, or macro that=20
could take either a type or an expression, so that you could define your=20
own operators along the lines of sizeof and typeid. Then you'd be able to=
=20
make your own countof() that semantically worked just like sizeof (except=
=20
that parentheses would be mandatory).
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_850_1334767148.1412451346301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, October 4, 2014 5:21:17 AM UTC-7, Daniel Kr=
=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2014-10-01 10=
:00 GMT+02:00 Jeaye Wilkerson <<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"QGTwjebyZqcJ" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">con.=
...@jeaye.com</a>>:
<br>> Folks,
<br>>
<br>> The stdlib could use a few new function templates to aid in creati=
ng generic
<br>> interfaces. With C++11, we were given std::begin to account for th=
e fact
<br>> that C-style arrays are valid containers. I propose we add a very =
similar
<br>> set of functions of accessing the size of containers, including C-=
style
<br>> arrays. The interface is as follows:
<br>>
<br>> template <typename T>
<br>>
<br>> auto size(T &c);
<br>> template <typename T>
<br>> auto size(T const &c);
<br>> template <typename T, std::size_t N>
<br>> std::size_t constexpr size(T (&arr)[N]);
<br>>
<br>> A working implementation and some example code is included here:
<br>> <a href=3D"http://coliru.stacked-crooked.com/a/a321818e19f0efae" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75=
http%3A%2F%2Fcoliru.stacked-crooked.com%2Fa%2Fa321818e19f0efae\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNEffBkUhww6wxt6EvkeHKadlgqteA';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fcoliru.stacked-=
crooked.com%2Fa%2Fa321818e19f0efae\46sa\75D\46sntz\0751\46usg\75AFQjCNEffBk=
Uhww6wxt6EvkeHKadlgqteA';return true;">http://coliru.stacked-crooked.<wbr>c=
om/a/a321818e19f0efae</a>
<br>>
<br>> The two main benefits of this addition are as follows:
<br>>
<br>> Support for C-style arrays in generic implementations; this also m=
akes the
<br>> std::xxx_n series more compatible with C-style arrays
<br>> Allowance of user-provided fully specialized versions of std::size=
for
<br>> custom types
<br>>
<br>> An example of 2 being: <a href=3D"http://coliru.stacked-crooked.co=
m/a/12c71f9970e37463" target=3D"_blank" onmousedown=3D"this.href=3D'http://=
www.google.com/url?q\75http%3A%2F%2Fcoliru.stacked-crooked.com%2Fa%2F12c71f=
9970e37463\46sa\75D\46sntz\0751\46usg\75AFQjCNGHn-mDU8s35OHCBIKsY8lojDiKnA'=
;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3=
A%2F%2Fcoliru.stacked-crooked.com%2Fa%2F12c71f9970e37463\46sa\75D\46sntz\07=
51\46usg\75AFQjCNGHn-mDU8s35OHCBIKsY8lojDiKnA';return true;">http://coliru.=
stacked-crooked.<wbr>com/a/12c71f9970e37463</a>
<br>
<br>Have you looked at the existing proposal:
<br>
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n401=
7.htm" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%=
2F2014%2Fn4017.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNGhRz6gs9in-SuxCzn-_wC=
8OB3V9w';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\=
75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014=
%2Fn4017.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNGhRz6gs9in-SuxCzn-_wC8OB3V9=
w';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/20=
14/<wbr>n4017.htm</a>
<br>
<br>and if so what is the difference of your proposal?
<br>
<br>I should add that for the upcoming mailing deadline a revision of this
<br>proposal has already been submitted, so this is ongoing work.
<br>
<br>- Daniel
<br></blockquote><div><br>Naming that <span style=3D"font-family: courier n=
ew,monospace;">std::size</span> seems awkward given that the built-in opera=
tor <span style=3D"font-family: courier new,monospace;">sizeof</span> would=
do something very different, but I understand wanting the orthogonal funct=
ionality of the global functions. (I wish STL had named the member fu=
nctions <span style=3D"font-family: courier new,monospace;">count()</span> =
instead of <span style=3D"font-family: courier new,monospace;">size()</span=
>... grr.)<br><br>I wish it were possible to make some function, template, =
or macro that could take either a type or an expression, so that you could =
define your own operators along the lines of <span style=3D"font-family: co=
urier new,monospace;">sizeof</span> and <span style=3D"font-family: courier=
new,monospace;">typeid</span>. Then you'd be able to make your own <=
span style=3D"font-family: courier new,monospace;">countof()</span> that se=
mantically worked just like <span style=3D"font-family: courier new,monospa=
ce;">sizeof</span> (except that parentheses would be mandatory).<br><br>Mel=
issa<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_850_1334767148.1412451346301--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Sat, 4 Oct 2014 17:53:06 -0700 (PDT)
Raw View
------=_Part_8784_1977189553.1412470386281
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, October 4, 2014 2:53:05 AM UTC-7, David Krauss wrote:
>
> On 2014=E2=80=9310=E2=80=9304, at 8:44 AM, Jeaye <con...@jeaye.com <javas=
cript:>> wrote:
>
> 2. Terribly verbose
>
>
> Yes, this is a good reason.
>
Concepts or a range-ified library could make `std::distance(container)`=20
legal.
=20
> 2. Allowance of user-provided fully specialized versions of std::size=
=20
> for
> custom types
>
>
> I suppose you could make an enumeration look simultaneously like a=20
> non-class container and an OutputIterator by defining begin, end, and (fr=
ee=20
> function) operator*, but that=E2=80=99s a bit of a hack. I can=E2=80=99t =
think of another=20
> use.
>
I could see it being used for POD types or platform-specific types like=20
SIMD-style vectors (_mm128 and so on), though the uses I've seen for such=
=20
things are limited more to template meta-programming.
--=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_8784_1977189553.1412470386281
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, October 4, 2014 2:53:05 AM UTC-7, David Kraus=
s 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-wra=
p:break-word"><div><div>On 2014=E2=80=9310=E2=80=9304, at 8:44 AM, Jeaye &l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"uHaftK=
IHWhMJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"t=
his.href=3D'javascript:';return true;">con...@jeaye.com</a>> wrote:</div=
><blockquote type=3D"cite"> 2. Terribly verbose<br></blockquote><div><=
br></div><div>Yes, this is a good reason.</div></div></div></blockquote><di=
v><br></div><div>Concepts or a range-ified library could make `std::distanc=
e(container)` legal.</div><div> </div><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-wrap:break-word"><div><blockquote type=3D"c=
ite"><blockquote type=3D"cite"> 2. Allowance of user-provi=
ded fully specialized versions of std::size for<br>  =
; custom types<br></blockquote></blockquote></div><br><div>I sup=
pose you could make an enumeration look simultaneously like a non-class con=
tainer and an OutputIterator by defining begin, end, and (free function) op=
erator*, but that=E2=80=99s a bit of a hack. I can=E2=80=99t think of anoth=
er use.</div></div></blockquote><div><br></div><div>I could see it being us=
ed for POD types or platform-specific types like SIMD-style vectors (_mm128=
and so on), though the uses I've seen for such things are limited more to =
template meta-programming.</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_8784_1977189553.1412470386281--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 6 Oct 2014 10:32:42 -0400
Raw View
--047d7b3a83aea063ec0504c1f4d7
Content-Type: text/plain; charset=UTF-8
On Fri, Oct 3, 2014 at 8:44 PM, Jeaye <contact@jeaye.com> wrote:
> I should note, the current alternative is
>
> std::distance(std::begin(arr), std::end(arr))
>
> which is
>
> 1. Not constexpr
> 2. Terribly verbose
>
3. Possibly O(N) instead of O(1)
Tony
--
---
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/.
--047d7b3a83aea063ec0504c1f4d7
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, Oct 3, 2014 at 8:44 PM, Jeaye <span dir=3D"ltr"><<a href=3D"=
mailto:contact@jeaye.com" target=3D"_blank">contact@jeaye.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">I should note, the current alter=
native is<br>
<br>
std::distance(std::begin(arr), std::end(arr))<br>
<br>
which is<br>
<br>
=C2=A0 1. Not constexpr<br>
=C2=A0 2. Terribly verbose<br></blockquote><div><br></div><div>=C2=A03. Pos=
sibly O(N) instead of O(1)<br><br></div><div>Tony<br></div></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 />
--047d7b3a83aea063ec0504c1f4d7--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 6 Oct 2014 10:40:27 -0400
Raw View
--001a11c372da504caf0504c2108d
Content-Type: text/plain; charset=UTF-8
On Wed, Oct 1, 2014 at 4:00 AM, Jeaye Wilkerson <contact@jeaye.com> wrote:
> Folks,
>
> The stdlib could use a few new function templates to aid in creating
> generic interfaces. With C++11, we were given std::begin to account for the
> fact that C-style arrays are valid containers. I propose we add a very
> similar set of functions of accessing the size of containers, including
> C-style arrays. The interface is as follows:
>
> template <typename T>
>
> auto size(T &c);
> template <typename T>
> auto size(T const &c);
> template <typename T, std::size_t N>
> std::size_t constexpr size(T (&arr)[N]);
>
>
> A working implementation and some example code is included here:
> http://coliru.stacked-crooked.com/a/a321818e19f0efae
>
> The two main benefits of this addition are as follows:
>
> 1. Support for C-style arrays in generic implementations; this also
> makes the std::xxx_n series more compatible with C-style arrays
> 2. Allowance of user-provided fully specialized versions of std::size
> for custom types
>
> An example of 2 being:
> http://coliru.stacked-crooked.com/a/12c71f9970e37463
>
> Regards,
> Jeaye
>
> --
>
>
>
I would like something like this, and have written it myself a number of
times. It would be nice to have a consistent name for it.
One concern I have, however, is how we do library extension points, in
general. ie it is hard to call swap(x,y) correctly:
{
using std::swap;
swap(x, y);
}
Will users need to do the same for std::size?
In general, I'd prefer the customization/extension point be separate from
the caller's API. ie customize std_size(), but call std::size().
To me (at least) this is similar to Herb's "Non-Virtual Interface" idiom (
http://www.gotw.ca/publications/mill18.htm). IN this case, there is no
virtual functions, but the separation of caller-interface vs
customizer-interface is the same.
Tony
--
---
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/.
--001a11c372da504caf0504c2108d
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 Wed, Oct 1, 2014 at 4:00 AM, Jeaye Wilkerson <span dir=3D"ltr"><<=
a href=3D"mailto:contact@jeaye.com" target=3D"_blank">contact@jeaye.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr">Folks,<br><br>The stdlib could use a few new function templat=
es to aid in creating generic interfaces. With C++11, we were given std::be=
gin to account for the fact that C-style arrays are valid containers. I pro=
pose we add a very similar set of functions of accessing the size of contai=
ners, including C-style arrays. The interface is as follows:<br><br><div st=
yle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bord=
er-style:solid;border-width:1px;word-wrap:break-word"><code><div><span styl=
e=3D"color:rgb(0,0,136)">template</span><span style=3D"color:rgb(0,0,0)"> <=
/span><span style=3D"color:rgb(102,102,0)"><</span><span style=3D"color:=
rgb(0,0,136)">typename</span><span style=3D"color:rgb(0,0,0)"> T</span><spa=
n style=3D"color:rgb(102,102,0)">></span><span style=3D"color:rgb(0,0,0)=
"><br></span><pre><a name=3D"148d9ffbb904d893_line-2"></a><span style=3D"co=
lor:rgb(0,0,136)">auto</span><span style=3D"color:rgb(0,0,0)"> size</span><=
span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)=
">T </span><span style=3D"color:rgb(102,102,0)">&</span><span style=3D"=
color:rgb(0,0,0)">c</span><span style=3D"color:rgb(102,102,0)">);</span><sp=
an style=3D"color:rgb(0,0,0)"><br></span><a name=3D"148d9ffbb904d893_line-3=
"></a><span style=3D"color:rgb(0,0,136)">template</span><span style=3D"colo=
r:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)"><</span><span=
style=3D"color:rgb(0,0,136)">typename</span><span style=3D"color:rgb(0,0,0=
)"> T</span><span style=3D"color:rgb(102,102,0)">></span><span style=3D"=
color:rgb(0,0,0)"><br></span><a name=3D"148d9ffbb904d893_line-4"></a><span =
style=3D"color:rgb(0,0,136)">auto</span><span style=3D"color:rgb(0,0,0)"> s=
ize</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color=
:rgb(0,0,0)">T </span><span style=3D"color:rgb(0,0,136)">const</span><span =
style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">&am=
p;</span><span style=3D"color:rgb(0,0,0)">c</span><span style=3D"color:rgb(=
102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br></span><a name=3D=
"148d9ffbb904d893_line-5"></a><span style=3D"color:rgb(0,0,136)">template</=
span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,=
102,0)"><</span><span style=3D"color:rgb(0,0,136)">typename</span><span =
style=3D"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,102,0)">,<=
/span><span style=3D"color:rgb(0,0,0)"> std</span><span style=3D"color:rgb(=
102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">size_t N</span><span =
style=3D"color:rgb(102,102,0)">></span><span style=3D"color:rgb(0,0,0)">=
<br></span><a name=3D"148d9ffbb904d893_line-6"></a><span style=3D"color:rgb=
(0,0,0)">std</span><span style=3D"color:rgb(102,102,0)">::</span><span styl=
e=3D"color:rgb(0,0,0)">size_t </span><span style=3D"color:rgb(0,0,136)">con=
stexpr</span><span style=3D"color:rgb(0,0,0)"> size</span><span style=3D"co=
lor:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">T </span><span=
style=3D"color:rgb(102,102,0)">(&</span><span style=3D"color:rgb(0,0,0=
)">arr</span><span style=3D"color:rgb(102,102,0)">)[</span><span style=3D"c=
olor:rgb(0,0,0)">N</span><span style=3D"color:rgb(102,102,0)">]);</span></p=
re></div></code></div><br>A working implementation and some example code is=
included here: <a href=3D"http://coliru.stacked-crooked.com/a/a321818e19f0=
efae" target=3D"_blank">http://coliru.stacked-crooked.com/a/a321818e19f0efa=
e</a><br><br>The two main benefits of this addition are as follows:<br><ol>=
<li>Support for C-style arrays in generic implementations; this also makes =
the std::xxx_n series more compatible with C-style arrays</li><li>Allowance=
of user-provided fully specialized versions of std::size for custom types<=
/li></ol><p>An example of 2 being: <a href=3D"http://coliru.stacked-crooked=
..com/a/12c71f9970e37463" target=3D"_blank">http://coliru.stacked-crooked.co=
m/a/12c71f9970e37463</a></p><p>Regards,<br>Jeaye<span class=3D""><font colo=
r=3D"#888888"><br></font></span></p></div><span class=3D""><font color=3D"#=
888888">
<p></p>
-- <br>
<br><br></font></span></blockquote><div><br><br></div><div>I would like som=
ething like this, and have written it myself a number of times.=C2=A0 It wo=
uld be nice to have a consistent name for it.<br><br></div><div>One concern=
I have, however, is how we do library extension points, in general.=C2=A0 =
ie it is hard to call swap(x,y) correctly:<br><br>{<br></div><div>=C2=A0=C2=
=A0 using std::swap;<br></div><div>=C2=A0=C2=A0 swap(x, y);<br>}<br><br></d=
iv><div>Will users need to do the same for std::size?<br><br></div><div>In =
general, I'd prefer the customization/extension point be separate from =
the caller's API.=C2=A0 ie customize std_size(), but call std::size().<=
br><br></div><div>To me (at least) this is similar to Herb's "Non-=
Virtual Interface" idiom (<a href=3D"http://www.gotw.ca/publications/m=
ill18.htm">http://www.gotw.ca/publications/mill18.htm</a>).=C2=A0 IN this c=
ase, there is no virtual functions, but the separation of caller-interface =
vs customizer-interface is the same.<br><br></div><div>Tony<br><br></div></=
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 />
--001a11c372da504caf0504c2108d--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 6 Oct 2014 09:51:56 -0500
Raw View
--bcaec53d5ee1c979c70504c23b7b
Content-Type: text/plain; charset=UTF-8
On 6 October 2014 09:40, Tony V E <tvaneerd@gmail.com> wrote:
>
> One concern I have, however, is how we do library extension points, in
> general. ie it is hard to call swap(x,y) correctly:
>
> {
> using std::swap;
> swap(x, y);
> }
>
> Will users need to do the same for std::size?
>
> In general, I'd prefer the customization/extension point be separate from
> the caller's API. ie customize std_size(), but call std::size().
>
Someone is going to have to write a paper so we can discuss it in LEWG (no,
it won't be me, as bike shedding issues bore me to tears). It would be
nice if users knew not to use the names we are hijacking from their
namespaces.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--bcaec53d5ee1c979c70504c23b7b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 6 October 2014 09:40, Tony V E <span dir=3D"ltr"><<a=
href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a=
>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><div>One concern I have, however, is how w=
e do library extension points, in general.=C2=A0 ie it is hard to call swap=
(x,y) correctly:<br><br>{<br></div><div>=C2=A0=C2=A0 using std::swap;<br></=
div><div>=C2=A0=C2=A0 swap(x, y);<br>}<br><br></div><div>Will users need to=
do the same for std::size?<br><br></div><div>In general, I'd prefer th=
e customization/extension point be separate from the caller's API.=C2=
=A0 ie customize std_size(), but call std::size().<br></div></div></div></d=
iv></blockquote><div><br></div><div>Someone is going to have to write a pap=
er so we can discuss it in LEWG (no, it won't be me, as bike shedding i=
ssues bore me to tears).=C2=A0 It would be nice if users knew not to use th=
e names we are hijacking from their namespaces.</div></div>-- <br>=C2=A0Nev=
in ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverl=
ord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1=
404
</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 />
--bcaec53d5ee1c979c70504c23b7b--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 06 Oct 2014 12:59:01 -0400
Raw View
On 2014-10-04 20:53, Sean Middleditch wrote:
> On Saturday, October 4, 2014 2:53:05 AM UTC-7, David Krauss wrote:
>> On 2014=E2=80=9310=E2=80=9304, at 8:44 AM, Jeaye <con...@jeaye.com <java=
script:>> wrote:
>>
>> 2. Terribly verbose
>>
>> Yes, this is a good reason.
>=20
> Concepts or a range-ified library could make `std::distance(container)`=
=20
> legal.
Ugh, 'std::distance' is still a terrible spelling for 'how many items in
this container?'. :-)
I was leaning toward 'std::count', and in fact I'm going to recommend
that instead; 'size' looks too much like 'sizeof', i.e. is more readily
confused with the number of bytes needed to store something, whereas
'count' is much more unambiguously the number of items in a container.
That said, I am strongly in favor of a generic (and short!) method to
determine the number of items in a container / range / etc..
This does seem to duplicate N4017, though...
--=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: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Mon, 6 Oct 2014 10:19:28 -0700 (PDT)
Raw View
------=_Part_4884_1203805145.1412615968136
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Name size is much better. We have member functions begin and end for=20
containers and general functions begin and end that can be applied also to=
=20
arrays. By analogy we could have member function size for containers and=20
general function size that can be also applied to arrays,
There is nothing bad that size resembles the sizeof operator. There is=20
ofthen used a construction as size_t size =3D sizeof( a ) / sizeof( *a ) in=
=20
programs.
Name count is simply awful.
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=
=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 20:59:21 UTC+4 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthew =
Woehlke=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> On 2014-10-04 20:53, Sean Middleditch wrote:=20
> > On Saturday, October 4, 2014 2:53:05 AM UTC-7, David Krauss wrote:=20
> >> On 2014=E2=80=9310=E2=80=9304, at 8:44 AM, Jeaye <con...@jeaye.com <ja=
vascript:>>=20
> wrote:=20
> >>=20
> >> 2. Terribly verbose=20
> >>=20
> >> Yes, this is a good reason.=20
> >=20
> > Concepts or a range-ified library could make `std::distance(container)`=
=20
> > legal.=20
>
> Ugh, 'std::distance' is still a terrible spelling for 'how many items in=
=20
> this container?'. :-)=20
>
> I was leaning toward 'std::count', and in fact I'm going to recommend=20
> that instead; 'size' looks too much like 'sizeof', i.e. is more readily=
=20
> confused with the number of bytes needed to store something, whereas=20
> 'count' is much more unambiguously the number of items in a container.=20
>
> That said, I am strongly in favor of a generic (and short!) method to=20
> determine the number of items in a container / range / etc..=20
>
> This does seem to duplicate N4017, though...=20
>
> --=20
> Matthew=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_4884_1203805145.1412615968136
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Name size is much better. We have member functions be=
gin and end for containers and general functions begin and end that c=
an be applied also to arrays. By analogy we could have member function size=
for containers and general function size that can be also applied to array=
s,</div><div>There is nothing bad that size resembles the sizeof operator. =
There is ofthen used a construction as size_t size =3D sizeof( a ) / sizeof=
( *a ) in programs.</div><div>Name count is simply awful.<br><br>=D0=
=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=BE=
=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 20:59:21 UTC+4 =D0=
=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matth=
ew Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; b=
order-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-s=
tyle: solid;">On 2014-10-04 20:53, Sean Middleditch wrote:
<br>> On Saturday, October 4, 2014 2:53:05 AM UTC-7, David Krauss wrote:
<br>>> On 2014=E2=80=9310=E2=80=9304, at 8:44 AM, Jeaye <<a>con...=
@jeaye.com</a> <javascript:>> wrote:
<br>>>
<br>>> 2. Terribly verbose
<br>>>
<br>>> Yes, this is a good reason.
<br>>=20
<br>> Concepts or a range-ified library could make `std::distance(contai=
ner)`=20
<br>> legal.
<br>
<br>Ugh, 'std::distance' is still a terrible spelling for 'how many items i=
n
<br>this container?'. :-)
<br>
<br>I was leaning toward 'std::count', and in fact I'm going to recommend
<br>that instead; 'size' looks too much like 'sizeof', i.e. is more readily
<br>confused with the number of bytes needed to store something, whereas
<br>'count' is much more unambiguously the number of items in a container.
<br>
<br>That said, I am strongly in favor of a generic (and short!) method to
<br>determine the number of items in a container / range / etc..
<br>
<br>This does seem to duplicate N4017, though...
<br>
<br>--=20
<br>Matthew
<br>
<br></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_4884_1203805145.1412615968136--
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Mon, 6 Oct 2014 10:31:42 -0700 (PDT)
Raw View
------=_Part_670_1120333363.1412616702128
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Take into account that name count is already reserved in the namespace std=
=20
for standard algorithm std::count.
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=
=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 21:19:28 UTC+4 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Vlad fro=
m=20
Moscow =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> Name size is much better. We have member functions begin and end for=20
> containers and general functions begin and end that can be applied also =
to=20
> arrays. By analogy we could have member function size for containers and=
=20
> general function size that can be also applied to arrays,
> There is nothing bad that size resembles the sizeof operator. There is=20
> ofthen used a construction as size_t size =3D sizeof( a ) / sizeof( *a ) =
in=20
> programs.
> Name count is simply awful.
>
> =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=
=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 20:59:21 UTC+4 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthew=
=20
> Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>> On 2014-10-04 20:53, Sean Middleditch wrote:=20
>> > On Saturday, October 4, 2014 2:53:05 AM UTC-7, David Krauss wrote:=20
>> >> On 2014=E2=80=9310=E2=80=9304, at 8:44 AM, Jeaye <con...@jeaye.com <j=
avascript:>>=20
>> wrote:=20
>> >>=20
>> >> 2. Terribly verbose=20
>> >>=20
>> >> Yes, this is a good reason.=20
>> >=20
>> > Concepts or a range-ified library could make `std::distance(container)=
`=20
>> > legal.=20
>>
>> Ugh, 'std::distance' is still a terrible spelling for 'how many items in=
=20
>> this container?'. :-)=20
>>
>> I was leaning toward 'std::count', and in fact I'm going to recommend=20
>> that instead; 'size' looks too much like 'sizeof', i.e. is more readily=
=20
>> confused with the number of bytes needed to store something, whereas=20
>> 'count' is much more unambiguously the number of items in a container.=
=20
>>
>> That said, I am strongly in favor of a generic (and short!) method to=20
>> determine the number of items in a container / range / etc..=20
>>
>> This does seem to duplicate N4017, though...=20
>>
>> --=20
>> Matthew=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_670_1120333363.1412616702128
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Take into account that name count is already reserved in t=
he namespace std for standard algorithm std::count.<br><br>=D0=BF=D0=BE=D0=
=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=BE=D0=BA=D1=82=
=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 21:19:28 UTC+4 =D0=BF=D0=BE=D0=
=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Vlad from Moscow =
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><di=
v dir=3D"ltr"><div>Name size is much better. We have member functions begin=
and end for containers and general functions begin and end that can =
be applied also to arrays. By analogy we could have member function size fo=
r containers and general function size that can be also applied to arrays,<=
/div><div>There is nothing bad that size resembles the sizeof operator. The=
re is ofthen used a construction as size_t size =3D sizeof( a ) / sizeof( *=
a ) in programs.</div><div>Name count is simply awful.<br><br>=D0=BF=
=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=BE=D0=
=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 20:59:21 UTC+4 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthew =
Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">On 2014-10-04 20:53, Sean Middleditch wrote:
<br>> On Saturday, October 4, 2014 2:53:05 AM UTC-7, David Krauss wrote:
<br>>> On 2014=E2=80=9310=E2=80=9304, at 8:44 AM, Jeaye <<a>con...=
@jeaye.com</a> <javascript:>> wrote:
<br>>>
<br>>> 2. Terribly verbose
<br>>>
<br>>> Yes, this is a good reason.
<br>>=20
<br>> Concepts or a range-ified library could make `std::distance(contai=
ner)`=20
<br>> legal.
<br>
<br>Ugh, 'std::distance' is still a terrible spelling for 'how many items i=
n
<br>this container?'. :-)
<br>
<br>I was leaning toward 'std::count', and in fact I'm going to recommend
<br>that instead; 'size' looks too much like 'sizeof', i.e. is more readily
<br>confused with the number of bytes needed to store something, whereas
<br>'count' is much more unambiguously the number of items in a container.
<br>
<br>That said, I am strongly in favor of a generic (and short!) method to
<br>determine the number of items in a container / range / etc..
<br>
<br>This does seem to duplicate N4017, though...
<br>
<br>--=20
<br>Matthew
<br>
<br></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_670_1120333363.1412616702128--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 06 Oct 2014 13:32:30 -0400
Raw View
On 2014-10-06 13:19, Vlad from Moscow wrote:
> Name size is much better.
I disagree.
> we could have member function size for containers and
> general function size that can be also applied to arrays,
....or we could have member functions *'count'*, as Myriachan mentioned
:-). Qt got this right.
int foo[5];
sizeof(foo); // 20, of course
size(foo); // er... 20? right? why would the "of" change it?
size(*foo); // this is legal, yes? and == 4?
count(foo); // unambiguously it is 5, *not* 20
--
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/.
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Mon, 6 Oct 2014 10:42:54 -0700 (PDT)
Raw View
------=_Part_19_1777964364.1412617374514
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I do not see any ambiguity between size and sizeof. I see an ambiguity=20
between member function size and count and betwwen member functions begin=
=20
and end and general functions begin and end on the one hand and member=20
function size and general function count on the other hand.
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=
=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 21:32:48 UTC+4 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthew =
Woehlke=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On 2014-10-06 13:19, Vlad from Moscow wrote:=20
> > Name size is much better.=20
>
> I disagree.=20
>
> > we could have member function size for containers and=20
> > general function size that can be also applied to arrays,=20
>
> ...or we could have member functions *'count'*, as Myriachan mentioned=20
> :-). Qt got this right.=20
>
> int foo[5];=20
> sizeof(foo); // 20, of course=20
> size(foo); // er... 20? right? why would the "of" change it?=20
> size(*foo); // this is legal, yes? and =3D=3D 4?=20
> count(foo); // unambiguously it is 5, *not* 20=20
>
> --=20
> Matthew=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_19_1777964364.1412617374514
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I do not see any ambiguity between size and sizeof. I see =
an ambiguity between member function size and count and betwwen member func=
tions begin and end and general functions begin and end on the one hand and=
member function size and general function count on the other hand.<br><br>=
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=
=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 21:32:48 UTC+4 =
=D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Ma=
tthew Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">On 2014-10-06 13:19, Vlad from Moscow wrote:
<br>> Name size is much better.
<br>
<br>I disagree.
<br>
<br>> we could have member function size for containers and=20
<br>> general function size that can be also applied to arrays,
<br>
<br>...or we could have member functions *'count'*, as Myriachan mentioned
<br>:-). Qt got this right.
<br>
<br> int foo[5];
<br> sizeof(foo); // 20, of course
<br> size(foo); // er... 20? right? why would the "of" change it?
<br> size(*foo); // this is legal, yes? and =3D=3D 4?
<br> count(foo); // unambiguously it is 5, *not* 20
<br>
<br>--=20
<br>Matthew
<br>
<br></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_19_1777964364.1412617374514--
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Mon, 6 Oct 2014 11:16:26 -0700 (PDT)
Raw View
------=_Part_424_626440836.1412619386743
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Also some containers as for example associative containers have member=20
function count. So using general function with the same name will only=20
confuse users.
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=
=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 21:42:54 UTC+4 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Vlad fro=
m=20
Moscow =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> I do not see any ambiguity between size and sizeof. I see an ambiguity=20
> between member function size and count and betwwen member functions begin=
=20
> and end and general functions begin and end on the one hand and member=20
> function size and general function count on the other hand.
>
> =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=
=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 21:32:48 UTC+4 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthew=
=20
> Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>
>> On 2014-10-06 13:19, Vlad from Moscow wrote:=20
>> > Name size is much better.=20
>>
>> I disagree.=20
>>
>> > we could have member function size for containers and=20
>> > general function size that can be also applied to arrays,=20
>>
>> ...or we could have member functions *'count'*, as Myriachan mentioned=
=20
>> :-). Qt got this right.=20
>>
>> int foo[5];=20
>> sizeof(foo); // 20, of course=20
>> size(foo); // er... 20? right? why would the "of" change it?=20
>> size(*foo); // this is legal, yes? and =3D=3D 4?=20
>> count(foo); // unambiguously it is 5, *not* 20=20
>>
>> --=20
>> Matthew=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_424_626440836.1412619386743
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Also some containers as for example associative conta=
iners have member function count. So using general function with the same n=
ame will only confuse users.</div><div><br><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=
=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=
=D1=80=D1=8F 2014 =D0=B3., 21:42:54 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=
=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Vlad from Moscow =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(2=
04, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr">I do not see any ambiguity between size and sizeof. I see an ambig=
uity between member function size and count and betwwen member functions be=
gin and end and general functions begin and end on the one hand and member =
function size and general function count on the other hand.<br><br>=D0=BF=
=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=BE=D0=
=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 21:32:48 UTC+4 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthew =
Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-lef=
t-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: sol=
id;">On 2014-10-06 13:19, Vlad from Moscow wrote:
<br>> Name size is much better.
<br>
<br>I disagree.
<br>
<br>> we could have member function size for containers and=20
<br>> general function size that can be also applied to arrays,
<br>
<br>...or we could have member functions *'count'*, as Myriachan mentioned
<br>:-). Qt got this right.
<br>
<br> int foo[5];
<br> sizeof(foo); // 20, of course
<br> size(foo); // er... 20? right? why would the "of" change it?
<br> size(*foo); // this is legal, yes? and =3D=3D 4?
<br> count(foo); // unambiguously it is 5, *not* 20
<br>
<br>--=20
<br>Matthew
<br>
<br></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_424_626440836.1412619386743--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 06 Oct 2014 13:55:33 -0400
Raw View
On 2014-10-06 13:31, Vlad from Moscow wrote:
> Take into account that name count is already reserved in the namespace std
> for standard algorithm std::count.
....and what exactly prevents adding a single-argument overload? The
existing std::count to me is another reason in *favor* of using the name
'count'; we have already established that std::count returns a "number
of elements".
Right now we *already have*:
- sizeof, which returns memory size (in bytes)
- count, which returns the number of elements
Now you want to add "size" that *also* returns the number of elements
despite that a) we currently have "count" for that, and b) we currently
use "size[of]" to return something totally different (memory size in
bytes). If you really can't understand why I am concerned about using
the same verb for *two very different things*, determined by the
presence or absence of "of", then I'm sorry, but I am at a loss how else
to explain it.
Use of "size" rather than "count" in STL containers was IMHO a mistake
in the first place. Let's please not propagate that mistake further.
--
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/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 06 Oct 2014 14:38:13 -0400
Raw View
On 2014-10-06 14:16, Vlad from Moscow wrote:
> Also some containers as for example associative containers have member
> function count. So using general function with the same name will only
> confuse users.
Why do you think that? As I already stated, I consider this a *feature*.
"count" returns a number of elements.
There are / would be several possible ways to invoke "count":
- std::count(container)
...counts items in <container>
- std::count(container, predicate)
...counts items in <container> that match <predicate>
- std::count(begin, end)
...counts items in [<begin>, <end>)
- std::count(begin, end, predicate)
...counts items in [<begin>, <end>) that match <predicate>
- container::count()
...counts items in *this
- container::count(key)
...counts items in *this that match <key>
All we're doing is making the predicate optional (with an omitted
predicate meaning "always"). I fail to see how this is in any way
whatsoever confusing. (Compare to using "size" to sometimes mean memory
size in bytes and sometimes mean number of elements...)
--
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/.
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Mon, 6 Oct 2014 11:50:43 -0700 (PDT)
Raw View
------=_Part_460_1032749801.1412621443699
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Names size and max_size are very logically consistent. But names count and=
=20
max_count can comfuse users. I do not see any problem with using std::size.=
=20
It is much better than for example std::extent that makes code awful.
It is using name count for such a purpose will be a mistake.. We do not say=
=20
"the count of an array" We say "the size of an array".
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=
=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 22:19:50 UTC+4 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthew =
Woehlke=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> On 2014-10-06 13:31, Vlad from Moscow wrote:=20
> > Take into account that name count is already reserved in the namespace=
=20
> std=20
> > for standard algorithm std::count.=20
>
> ...and what exactly prevents adding a single-argument overload? The=20
> existing std::count to me is another reason in *favor* of using the name=
=20
> 'count'; we have already established that std::count returns a "number=20
> of elements".=20
>
> Right now we *already have*:=20
>
> - sizeof, which returns memory size (in bytes)=20
> - count, which returns the number of elements=20
>
> Now you want to add "size" that *also* returns the number of elements=20
> despite that a) we currently have "count" for that, and b) we currently=
=20
> use "size[of]" to return something totally different (memory size in=20
> bytes). If you really can't understand why I am concerned about using=20
> the same verb for *two very different things*, determined by the=20
> presence or absence of "of", then I'm sorry, but I am at a loss how else=
=20
> to explain it.=20
>
> Use of "size" rather than "count" in STL containers was IMHO a mistake=20
> in the first place. Let's please not propagate that mistake further.=20
>
> --=20
> Matthew=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_460_1032749801.1412621443699
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Names size and max_size are very logically consistent=
.. But names count and max_count can comfuse users. I do not see any problem=
with using std::size. It is much better than for example std::extent that =
makes code awful.</div><div>It is using name count for such a purpose will =
be a mistake.. We do not say "the count of an array" We say "the size of an=
array".<br><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=
=B8=D0=BA, 6 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., =
22:19:50 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=
=D0=BB=D1=8C Matthew Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;">On 2014-10-06 13:31, Vlad from Moscow wrote=
:
<br>> Take into account that name count is already reserved in the names=
pace std=20
<br>> for standard algorithm std::count.
<br>
<br>...and what exactly prevents adding a single-argument overload? The
<br>existing std::count to me is another reason in *favor* of using the nam=
e
<br>'count'; we have already established that std::count returns a "number
<br>of elements".
<br>
<br>Right now we *already have*:
<br>
<br>- sizeof, which returns memory size (in bytes)
<br>- count, which returns the number of elements
<br>
<br>Now you want to add "size" that *also* returns the number of elements
<br>despite that a) we currently have "count" for that, and b) we currently
<br>use "size[of]" to return something totally different (memory size in
<br>bytes). If you really can't understand why I am concerned about using
<br>the same verb for *two very different things*, determined by the
<br>presence or absence of "of", then I'm sorry, but I am at a loss how els=
e
<br>to explain it.
<br>
<br>Use of "size" rather than "count" in STL containers was IMHO a mistake
<br>in the first place. Let's please not propagate that mistake further.
<br>
<br>--=20
<br>Matthew
<br>
<br></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_460_1032749801.1412621443699--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 6 Oct 2014 14:01:04 -0500
Raw View
--f46d043be1b8be57dd0504c5b6b3
Content-Type: text/plain; charset=UTF-8
On 6 October 2014 13:38, Matthew Woehlke <mw_triad@users.sourceforge.net>
wrote:
> All we're doing is making the predicate optional (with an omitted
> predicate meaning "always"). I fail to see how this is in any way
> whatsoever confusing. (Compare to using "size" to sometimes mean memory
> size in bytes and sometimes mean number of elements...)
>
Where in the standard library does size() mean memory size in bytes??
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--f46d043be1b8be57dd0504c5b6b3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 6 October 2014 13:38, Matthew Woehlke <span dir=3D"ltr"=
><<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw=
_triad@users.sourceforge.net</a>></span> wrote:<br><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All we'=
re doing is making the predicate optional (with an omitted<br>
predicate meaning "always"). I fail to see how this is in any way=
<br>
whatsoever confusing. (Compare to using "size" to sometimes mean =
memory<br>
size in bytes and sometimes mean number of elements...)<br></blockquote><di=
v><br></div><div>Where in the standard library does size() mean memory size=
in bytes??</div></div>-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <m=
ailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evi=
loverlord.com</a>>=C2=A0 (847) 691-1404
</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 />
--f46d043be1b8be57dd0504c5b6b3--
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Mon, 6 Oct 2014 12:13:07 -0700 (PDT)
Raw View
------=_Part_798_1427210776.1412622787674
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
size is a property of a container, count is an algorithm that counts=20
something as for example member function count of associative containers.=
=20
They are different notions. I would like to see std::size that corresponds=
=20
to member function size of containers the same way as begin corresponds to=
=20
member functopn begin. It is very clear and ;logically consistent. I do not=
=20
want to see confusing count that will corresponds to size. In my opinion it=
=20
is a bad style of programming to introduce such a confusion in code.
=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 6 =D0=
=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014 =D0=B3., 22:38:34 UTC+4 =D0=BF=
=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Matthew =
Woehlke=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On 2014-10-06 14:16, Vlad from Moscow wrote:=20
> > Also some containers as for example associative containers have member=
=20
> > function count. So using general function with the same name will only=
=20
> > confuse users.=20
>
> Why do you think that? As I already stated, I consider this a *feature*.=
=20
> "count" returns a number of elements.=20
>
> There are / would be several possible ways to invoke "count":=20
>
> - std::count(container)=20
> ...counts items in <container>=20
> - std::count(container, predicate)=20
> ...counts items in <container> that match <predicate>=20
> - std::count(begin, end)=20
> ...counts items in [<begin>, <end>)=20
> - std::count(begin, end, predicate)=20
> ...counts items in [<begin>, <end>) that match <predicate>=20
> - container::count()=20
> ...counts items in *this=20
> - container::count(key)=20
> ...counts items in *this that match <key>=20
>
> All we're doing is making the predicate optional (with an omitted=20
> predicate meaning "always"). I fail to see how this is in any way=20
> whatsoever confusing. (Compare to using "size" to sometimes mean memory=
=20
> size in bytes and sometimes mean number of elements...)=20
>
> --=20
> Matthew=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_798_1427210776.1412622787674
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">size is a property of a container, count is an algorithm t=
hat counts something as for example member function count of associative co=
ntainers. They are different notions. I would like to see std::size that co=
rresponds to member function size of containers the same way as begin corre=
sponds to member functopn begin. It is very clear and ;logically consistent=
.. I do not want to see confusing count that will corresponds to size. In my=
opinion it is a bad style of programming to introduce such =
a confusion in code.<br><br>=D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=
=8C=D0=BD=D0=B8=D0=BA, 6 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2014&nb=
sp;=D0=B3., 22:38:34 UTC+4 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=
=D1=82=D0=B5=D0=BB=D1=8C Matthew Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;">On 2014-10-06 14:16, Vlad from Mosco=
w wrote:
<br>> Also some containers as for example associative containers have me=
mber=20
<br>> function count. So using general function with the same name will =
only=20
<br>> confuse users.
<br>
<br>Why do you think that? As I already stated, I consider this a *feature*=
..
<br>"count" returns a number of elements.
<br>
<br>There are / would be several possible ways to invoke "count":
<br>
<br>- std::count(container)
<br> ...counts items in <container>
<br>- std::count(container, predicate)
<br> ...counts items in <container> that match <predicate>=
;
<br>- std::count(begin, end)
<br> ...counts items in [<begin>, <end>)
<br>- std::count(begin, end, predicate)
<br> ...counts items in [<begin>, <end>) that match <p=
redicate>
<br>- container::count()
<br> ...counts items in *this
<br>- container::count(key)
<br> ...counts items in *this that match <key>
<br>
<br>All we're doing is making the predicate optional (with an omitted
<br>predicate meaning "always"). I fail to see how this is in any way
<br>whatsoever confusing. (Compare to using "size" to sometimes mean memory
<br>size in bytes and sometimes mean number of elements...)
<br>
<br>--=20
<br>Matthew
<br>
<br></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_798_1427210776.1412622787674--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 06 Oct 2014 15:14:39 -0400
Raw View
On 2014-10-06 15:01, Nevin Liber wrote:
> On 6 October 2014 13:38, Matthew Woehlke wrote:
>> (Compare to using "size" to sometimes mean memory size in bytes
>> and sometimes mean number of elements...)
>
> Where in the standard library does size() mean memory size in bytes??
I was referring a) to "size" as a generic verb (i.e. "sizeof"), and b)
to the suggestion of supporting e.g. std::size(T) for some POD type T.
(Okay, I *think* I get that std::size(_mm128) is the number of vector
elements in a "_mm128" which is actually a fixed-size vector stored in a
POD type, but *geez* is that confusing. Which is sort of the point I'm
trying to make... at least std::count can't be mistaken for being
sizeof()-like.)
--
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/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 6 Oct 2014 15:28:37 -0400
Raw View
--001a11341542e1f6b50504c61648
Content-Type: text/plain; charset=UTF-8
On Mon, Oct 6, 2014 at 3:01 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 6 October 2014 13:38, Matthew Woehlke <mw_triad@users.sourceforge.net>
> wrote:
>
>> All we're doing is making the predicate optional (with an omitted
>> predicate meaning "always"). I fail to see how this is in any way
>> whatsoever confusing. (Compare to using "size" to sometimes mean memory
>> size in bytes and sometimes mean number of elements...)
>>
>
> Where in the standard library does size() mean memory size in bytes??
>
Well, if you search the standard (not just library) , you find things like
"object of non-zero size" etc, and of course sizeof, which is similar.
Closer to library is allocation and allocators - where the word size is
used to mean bytes.
Since I like bike-sheds as much as the next person (OK, much more than the
next person):
'size'
- container::size(), matching begin/end
- container::size_type
- sizeof???
Alternatives
'count'
- std::count() does count things.
- it is hard (easier with Concepts?) to overload std::count() for both
count(begin, end) and count(container, value) (ie both 2 params),
particularly if you have a strange container that is both a container and
an iterator. But not completely impossible.
'length'
- some containers (ie string) also have length. And char_traits
- the standard talks about the length of NTBS (ie 17.5.2.1.4.1)
- the standard talks about length of arrays (not size of arrays)
- std::bad_array_new_length
- std::length_error
- 20.8.1.3 "unique_ptr for array objects with a runtime length"
- etc
Given all the above, the obvious answer is...
'countof'
- this is what I called it whenever I did it for arrays (because it was
compile-time like sizeof(), but a count of items, not bytes). Thus it must
be the right name :-)
Tony
--
---
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/.
--001a11341542e1f6b50504c61648
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><br><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Mon, Oct 6, 2014 at 3:01 PM, Nevin Liber <span d=
ir=3D"ltr"><<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">=
nevin@eviloverlord.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On 6 October 2014 =
13:38, Matthew Woehlke <span dir=3D"ltr"><<a href=3D"mailto:mw_triad@use=
rs.sourceforge.net" target=3D"_blank">mw_triad@users.sourceforge.net</a>>=
;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All=
we're doing is making the predicate optional (with an omitted<br>
predicate meaning "always"). I fail to see how this is in any way=
<br>
whatsoever confusing. (Compare to using "size" to sometimes mean =
memory<br>
size in bytes and sometimes mean number of elements...)<br></blockquote><di=
v><br></div></span><div>Where in the standard library does size() mean memo=
ry size in bytes??</div></div></div></div></blockquote><div><br><br></div><=
/div>Well, if you search the standard (not just library) , you find things =
like "object of non-zero size" etc, and of course sizeof, which i=
s similar.<br><br></div><div class=3D"gmail_extra">Closer to library is all=
ocation and allocators - where the word size is used to mean bytes.<br><br>=
</div><div class=3D"gmail_extra">Since I like bike-sheds as much as the nex=
t person (OK, much more than the next person):<br><br></div><div class=3D"g=
mail_extra">'size'<br></div><div class=3D"gmail_extra">- container:=
:size(), matching begin/end<br></div><div class=3D"gmail_extra">- container=
::size_type<br></div><div class=3D"gmail_extra">- sizeof???<br></div><div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Alternatives<br><=
br></div><div class=3D"gmail_extra">'count'<br></div><div class=3D"=
gmail_extra">- std::count() does count things.<br></div><div class=3D"gmail=
_extra">- it is hard (easier with Concepts?) to overload std::count() for b=
oth count(begin, end) and count(container, value) (ie both 2 params), parti=
cularly if you have a strange container that is both a container and an ite=
rator.=C2=A0 But not completely impossible.<br><br></div><div class=3D"gmai=
l_extra">'length'<br></div><div class=3D"gmail_extra">- some contai=
ners (ie string) also have length. And char_traits<br></div><div class=3D"g=
mail_extra"><div class=3D"gmail_extra">- the standard talks about the lengt=
h of NTBS (ie 17.5.2.1.4.1)<br></div><div class=3D"gmail_extra"></div>- the=
standard talks about length of arrays (not size of arrays)<br></div><div c=
lass=3D"gmail_extra">- std::bad_array_new_length<br></div>- std::length_err=
or<br>- 20.8.1.3 "unique_ptr for array objects with a runtime length&q=
uot;<br></div><div>- etc<br><br></div>Given all the above, the obvious answ=
er is...<br><br><br><br><br></div>'countof'<br></div>- this is what=
I called it whenever I did it for arrays (because it was compile-time like=
sizeof(), but a count of items, not bytes).=C2=A0 Thus it must be the righ=
t name :-)<br><br></div>Tony<br><br></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 />
--001a11341542e1f6b50504c61648--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 6 Oct 2014 12:40:16 -0700 (PDT)
Raw View
------=_Part_1482_1250440724.1412624416448
Content-Type: text/plain; charset=UTF-8
On Monday, October 6, 2014 11:50:43 AM UTC-7, Vlad from Moscow wrote:
>
> Names size and max_size are very logically consistent. But names count and
> max_count can comfuse users. I do not see any problem with using std::size.
> It is much better than for example std::extent that makes code awful.
> It is using name count for such a purpose will be a mistake.. We do not
> say "the count of an array" We say "the size of an array".
>
>
That's only because it is decades too late to change STL to rename the
member functions count and max_count. The conflict with the sizeof
operator is strong.
Some implementations already have a _countof macro.
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_1482_1250440724.1412624416448
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, October 6, 2014 11:50:43 AM UTC-7, Vlad from Mo=
scow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv>Names size and max_size are very logically consistent. But names count a=
nd max_count can comfuse users. I do not see any problem with using std::si=
ze. It is much better than for example std::extent that makes code awful.</=
div><div>It is using name count for such a purpose will be a mistake.. We d=
o not say "the count of an array" We say "the size of an array".<br></div><=
br></div></blockquote><div><br>That's only because it is decades too late t=
o change STL to rename the member functions <span style=3D"font-family: cou=
rier new,monospace;">count</span> and <span style=3D"font-family: courier n=
ew,monospace;">max_count</span>. The conflict with the <span style=3D=
"font-family: courier new,monospace;">sizeof</span> operator is strong.<br>=
<br>Some implementations already have a <span style=3D"font-family: courier=
new,monospace;">_countof</span> macro.<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_1482_1250440724.1412624416448--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 6 Oct 2014 14:42:09 -0500
Raw View
--047d7ba97e9aa92d950504c649a8
Content-Type: text/plain; charset=UTF-8
On 6 October 2014 14:40, Myriachan <myriachan@gmail.com> wrote:
> That's only because it is decades too late to change STL to rename the
> member functions count and max_count.
>
So instead you propose to confuse users even more. That ship has sailed;
why should we now be deliberately inconsistent with it?
> The conflict with the sizeof operator is strong.
>
How is it any stronger than size() inside STL containers?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--047d7ba97e9aa92d950504c649a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 6 October 2014 14:40, Myriachan <span dir=3D"ltr"><<=
a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com=
</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>That's only b=
ecause it is decades too late to change STL to rename the member functions =
<span style=3D"font-family:courier new,monospace">count</span> and <span st=
yle=3D"font-family:courier new,monospace">max_count</span>.=C2=A0 </div></d=
iv></blockquote><div><br></div><div>So instead you propose to confuse users=
even more.=C2=A0 That ship has sailed; why should we now be deliberately i=
nconsistent with it?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>The conflict with the <span style=3D"font-family:couri=
er new,monospace">sizeof</span> operator is strong.<br></div></div></blockq=
uote><div><br></div><div>How is it any stronger than size() inside STL cont=
ainers?</div></div>-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailt=
o:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilove=
rlord.com</a>>=C2=A0 (847) 691-1404
</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 />
--047d7ba97e9aa92d950504c649a8--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 6 Oct 2014 15:47:08 -0400
Raw View
--047d7b3a90442124f00504c65984
Content-Type: text/plain; charset=UTF-8
On Mon, Oct 6, 2014 at 3:42 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 6 October 2014 14:40, Myriachan <myriachan@gmail.com> wrote:
>
>> That's only because it is decades too late to change STL to rename the
>> member functions count and max_count.
>>
>
> So instead you propose to confuse users even more. That ship has sailed;
> why should we now be deliberately inconsistent with it?
>
>
>> The conflict with the sizeof operator is strong.
>>
>
> How is it any stronger than size() inside STL containers?
>
container::size() is called as a member function:
foo.size().
both sizeof() and std::size() would are called like free functions:
size(foo);
sizeof(foo);
It could be argued that this is thus "stronger".
Tony
--
---
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/.
--047d7b3a90442124f00504c65984
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 Mon, Oct 6, 2014 at 3:42 PM, Nevin Liber <span dir=3D"ltr"><<a hr=
ef=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.c=
om</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"><div dir=3D"ltr"=
><span class=3D"">On 6 October 2014 14:40, Myriachan <span dir=3D"ltr"><=
<a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.co=
m</a>></span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>That's only because it is decades too late to change STL to ren=
ame the member functions <span style=3D"font-family:courier new,monospace">=
count</span> and <span style=3D"font-family:courier new,monospace">max_coun=
t</span>.=C2=A0 </div></div></blockquote><div><br></div></span><div>So inst=
ead you propose to confuse users even more.=C2=A0 That ship has sailed; why=
should we now be deliberately inconsistent with it?</div><span class=3D"">=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The c=
onflict with the <span style=3D"font-family:courier new,monospace">sizeof</=
span> operator is strong.<br></div></div></blockquote><div><br></div></span=
><div>How is it any stronger than size() inside STL containers?</div></div>=
</div></div></blockquote><div><br></div><div>container::size() is called as=
a member function:<br><br>=C2=A0=C2=A0=C2=A0 foo.size().<br><br></div><div=
>both sizeof() and std::size() would are called like free functions:<br><br=
></div><div>=C2=A0=C2=A0=C2=A0 size(foo);<br></div><div>=C2=A0=C2=A0=C2=A0 =
sizeof(foo);<br><br></div><div>It could be argued that this is thus "s=
tronger".<br></div></div><br></div><div class=3D"gmail_extra">Tony<br>=
<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 />
--047d7b3a90442124f00504c65984--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 06 Oct 2014 16:57:04 -0400
Raw View
On 2014-10-06 15:42, Nevin Liber wrote:
> On 6 October 2014 14:40, Myriachan wrote:
>> That's only because it is decades too late to change STL to rename the
>> member functions count and max_count.
>
> So instead you propose to confuse users even more. That ship has sailed;
> why should we now be deliberately inconsistent with it?
The key word there is "change". I don't see what's to stop us fixing
things by *adding* a count() method and deprecating size(). :-)
--
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/.
.
Author: Jeaye <contact@jeaye.com>
Date: Tue, 7 Oct 2014 02:38:15 +0800
Raw View
On Sat, Oct 04, 2014 at 02:21:15PM +0200, Daniel Kr=C3=BCgler wrote:
> Have you looked at the existing proposal:
>=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4017.htm
>=20
> and if so what is the difference of your proposal?
>=20
Thanks, Daniel. I hadn't seen N4017, but it's certainly tackling the
same issues. I'll piggy back that instead of duplicating efforts.
Regards,
J
--=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: Myriachan <myriachan@gmail.com>
Date: Mon, 6 Oct 2014 19:58:41 -0700 (PDT)
Raw View
------=_Part_10868_787745629.1412650722126
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, October 6, 2014 6:41:55 PM UTC-7, Jeaye Wilkerson wrote:
>
> On Sat, Oct 04, 2014 at 02:21:15PM +0200, Daniel Kr=C3=BCgler wrote:=20
> > Have you looked at the existing proposal:=20
> >=20
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4017.htm=20
> >=20
> > and if so what is the difference of your proposal?=20
> >=20
>
> Thanks, Daniel. I hadn't seen N4017, but it's certainly tackling the=20
> same issues. I'll piggy back that instead of duplicating efforts.=20
>
>
Hmm, I just noticed something. With that proposal to fix the Standard to=
=20
allow references to unknown-sized arrays as a function parameter type,=20
should this spec be updated to add these, conditional upon whether=20
unknown-sized arrays as function parameters are approved for the Standard?
// [Note: The implementation of these overloads will require the use of
// enable_if_t or a similar mechanism in order to work properly in concert
// with the other definitions. --end note]
// capacity:
template <class T> constexpr bool empty(const T(&)[]) noexcept;
// returns: false
// element access:
template <class T> constexpr T &front(T (&array)[]) noexcept;
// returns: array[0]
// data access:
template <class T> constexpr T *data(T (&array)[]) noexcept;
// returns: array
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_10868_787745629.1412650722126
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, October 6, 2014 6:41:55 PM UTC-7, Jeaye Wilkers=
on wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sat, Oct 04, 2014 =
at 02:21:15PM +0200, Daniel Kr=C3=BCgler wrote:
<br>> Have you looked at the existing proposal:
<br>>=20
<br>> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014=
/n4017.htm" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpa=
pers%2F2014%2Fn4017.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNGhRz6gs9in-SuxCz=
n-_wC8OB3V9w';return true;" onclick=3D"this.href=3D'http://www.google.com/u=
rl?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2=
F2014%2Fn4017.htm\46sa\75D\46sntz\0751\46usg\75AFQjCNGhRz6gs9in-SuxCzn-_wC8=
OB3V9w';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/pape=
rs/2014/<wbr>n4017.htm</a>
<br>>=20
<br>> and if so what is the difference of your proposal?
<br>>=20
<br>
<br>Thanks, Daniel. I hadn't seen N4017, but it's certainly tackling the
<br>same issues. I'll piggy back that instead of duplicating efforts.
<br>
<br></blockquote><div><br>Hmm, I just noticed something. With that pr=
oposal to fix the Standard to allow references to unknown-sized arrays as a=
function parameter type, should this spec be updated to add these, conditi=
onal upon whether unknown-sized arrays as function parameters are approved =
for the Standard?<br><br><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-=
by-prettify">// [Note: The implementation of these overloads will require t=
he use of</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// enab=
le_if_t or a similar mechanism in order to work properly in concert</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #800;" class=3D"styled-by-prettify">// with the other defini=
tions. --end note]</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br><br></span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">// capacity:</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #008;" 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"><</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> empty</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(&)[=
])</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> noexcep=
t</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: #800;" class=3D"styled-by-prettify">// returns=
: false</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #800;" class=3D"styled-by-prettify">// elemen=
t access:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">templat=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">front</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(&</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">array</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)[])</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> noexcept</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// returns: array[0]</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #800;" class=3D"styled-by-prettify">// data access:</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">template</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> T </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">data</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">T </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(&</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify">array</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)[])</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> noexcept</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// returns: array</span></div></code></div><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_10868_787745629.1412650722126--
.