Topic: ::std::array class template member function "data
Author: Daniel Schemmel <a@gha.st>
Date: Thu, 1 Aug 2013 13:01:59 -0700 (PDT)
Raw View
------=_Part_7_107939.1375387319439
Content-Type: text/plain; charset=ISO-8859-1
Currently the member function "data" of the class template ::std::array<T,
N> is defined to return a T* or T const* respectively.
Since the array class template is clearly intended to be a wrapper for C
style arrays, it would make sense to at least allow implementations like
T (&data() noexcept)[N] { return elems; }
T const (&data() const noexcept)[N] { return elems; } // could even be
constexpr
When changing the wording so that the result of the data function must be assignable to a variable of type T* or T const* respectively, the current implementations would not even have to be changed.
--
---
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_7_107939.1375387319439
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Currently the member function "data" of the class template ::std::array<=
T, N> is defined to return a T* or T const* respectively.<div><br></div>=
<div>Since the array class template is clearly intended to be a wrapper for=
C style arrays, it would make sense to at least allow implementations like=
</div><div><br></div><div><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><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">data</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> noexcept</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)[</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">N</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">]</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> elems</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </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>T </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">data</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> noexcept</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">)[</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">N</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: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> elems</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// could even be constexpr</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span></div></code></div><pre styl=
e=3D"font-family: Consolas;"><span style=3D"color: black;"><br></span></pre=
><pre style=3D"font-family: Consolas;"><span style=3D"color: black;">When c=
hanging the wording so that the result of the data function must be assigna=
ble to a variable of type T* or T const* respectively, the current implemen=
tations would not even have to be changed.</span></pre></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_7_107939.1375387319439--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 01 Aug 2013 13:48:34 -0700
Raw View
--nextPart2777472.x7pCDUoXLV
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
On quinta-feira, 1 de agosto de 2013 13:01:59, Daniel Schemmel wrote:
> Currently the member function "data" of the class template ::std::array<T,
> N> is defined to return a T* or T const* respectively.
>
> Since the array class template is clearly intended to be a wrapper for C
> style arrays, it would make sense to at least allow implementations like
>
> T (&data() noexcept)[N] { return elems; }
> T const (&data() const noexcept)[N] { return elems; } // could even be
> constexpr
What's the advantage in doing this? What are do you want to accomplish?
Are you trying to use decltype or other type detections to create a similarly-
sized array? Are you trying to match a template function that takes array
references?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--nextPart2777472.x7pCDUoXLV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQBR+smjM/XwBW70U1gRAn9cAJ9KegS1Um0Zz/luKHWB3VbfvyZOTACfVkl+
z7MDR7kLS+Frrn7q35oencw=
=DHY7
-----END PGP SIGNATURE-----
--nextPart2777472.x7pCDUoXLV--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 1 Aug 2013 15:49:19 -0500
Raw View
--001a11c3e0e4480f8504e2e8fc6c
Content-Type: text/plain; charset=ISO-8859-1
On 1 August 2013 15:01, Daniel Schemmel <a@gha.st> wrote:
> Currently the member function "data" of the class template ::std::array<T,
> N> is defined to return a T* or T const* respectively.
>
> Since the array class template is clearly intended to be a wrapper for C
> style arrays, it would make sense to at least allow implementations like
>
> T (&data() noexcept)[N] { return elems; }
> T const (&data() const noexcept)[N] { return elems; } // could even be
> constexpr
>
>
> When changing the wording so that the result of the data function must be assignable to a variable of type T* or T const* respectively, the current implementations would not even have to be changed.
>
> While there are certainly pathological cases it can break (since such a
change is detectable), the idea is interesting. I'm generally a fan of not
throwing away information until you have to.
Even if we don't change data(), we could add another member function (such
as array()) which does the above.
I assume you'd want the member for an array<T, 0> to still return a pointer.
--
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/.
--001a11c3e0e4480f8504e2e8fc6c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 1 August 2013 15:01, Daniel Schemmel <span dir=3D"ltr"><<a href=3D"ma=
ilto:a@gha.st" target=3D"_blank">a@gha.st</a>></span> wrote:<br><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">
Currently the member function "data" of the class template ::std:=
:array<T, N> is defined to return a T* or T const* respectively.<div>=
<br></div><div>Since the array class template is clearly intended to be a w=
rapper for C style arrays, it would make sense to at least allow implementa=
tions like</div>
<div><br></div><div><div style=3D"background-color:rgb(250,250,250);border:=
1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span>T </span>=
<span style=3D"color:#660">(&</span><span>data</span><span style=3D"col=
or:#660">()</span><span> noexcept</span><span style=3D"color:#660">)[</span=
><span>N</span><span style=3D"color:#660">]</span><span> </span><span style=
=3D"color:#660">{</span><span> </span><span style=3D"color:#008">return</sp=
an><span> elems</span><span style=3D"color:#660">;</span><span> </span><spa=
n style=3D"color:#660">}</span><span><br>
T </span><span style=3D"color:#008">const</span><span> </span><span style=
=3D"color:#660">(&</span><span>data</span><span style=3D"color:#660">()=
</span><span> </span><span style=3D"color:#008">const</span><span> noexcept=
</span><span style=3D"color:#660">)[</span><span>N</span><span style=3D"col=
or:#660">]</span><span> </span><span style=3D"color:#660">{</span><span> </=
span><span style=3D"color:#008">return</span><span> elems</span><span style=
=3D"color:#660">;</span><span> </span><span style=3D"color:#660">}</span><s=
pan> </span><span style=3D"color:#800">// could even be constexpr</span><sp=
an><br>
</span></div></code></div><pre style=3D"font-family:Consolas"><span><br></s=
pan></pre><pre style=3D"font-family:Consolas"><span>When changing the wordi=
ng so that the result of the data function must be assignable to a variable=
of type T* or T const* respectively, the current implementations would not=
even have to be changed.</span><br>
</pre></div></blockquote></div>While there are certainly pathological cases=
it can break (since such a change is detectable), the idea is interesting.=
=A0 I'm generally a fan of not throwing away information until you have=
to.<br>
<br>Even if we don't change data(), we could add another member functio=
n (such as array()) which does the above.<br><br>I assume you'd want th=
e member for an array<T, 0> to still return a pointer.<br>-- <br>
=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 <a href=3D"=
tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(847) 69=
1-1404</a>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c3e0e4480f8504e2e8fc6c--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Thu, 1 Aug 2013 17:14:52 -0400
Raw View
On Thu, Aug 1, 2013 at 4:49 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> Even if we don't change data(), we could add another member function (such
> as array()) which does the above.
Unfortunately the name is token by the constructor... Maybe you
can call it `c_arr()` LOL
I like this idea.
Just a thought:
using TN = T[N];
operator TN&() noexcept { return elems; }
Since array reference does not implicitly convert to pointer,
this approach is actually safe. Just, I don't know why
the following does not work:
template <typename T, size_t N>
void f(T (&arr)[N]) {}
f(a); // implicit convert to array reference does not help...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
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: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 1 Aug 2013 23:18:30 +0200
Raw View
2013/8/1 Daniel Schemmel <a@gha.st>:
> Currently the member function "data" of the class template ::std::array<T,
> N> is defined to return a T* or T const* respectively.
>
> Since the array class template is clearly intended to be a wrapper for C
> style arrays, it would make sense to at least allow implementations like
>
> T (&data() noexcept)[N] { return elems; }
> T const (&data() const noexcept)[N] { return elems; } // could even be
> constexpr
Btw. something similar was already discussed as part of a library issue, see
http://cplusplus.github.io/LWG/lwg-closed.html#930
Personally I do appreciate the proposal but clearly would prefer a new
function, e.g. c_array or similar.
> When changing the wording so that the result of the data function must be
> assignable to a variable of type T* or T const* respectively, the current
> implementations would not even have to be changed.
I'm not sure what you mean here. Clearly existing implementations need
to be changed and I think it would be better to make that clear by a
separate function overload set instead of modifying existing data
functions.
This was rejected as library issue, but it would perfectly make sense
to write up a short proposal for it. IMO this addition is both useful
and does not have critical side-effects.
- 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: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Thu, 1 Aug 2013 14:25:51 -0700 (PDT)
Raw View
------=_Part_148_11826637.1375392351444
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
=D0=D1=D4=CE=C9=C3=C1, 2 =C1=D7=C7=D5=D3=D4=C1 2013 =C7., 0:48:34 UTC+4 =D0=
=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Thiago Macieira=20
=CE=C1=D0=C9=D3=C1=CC:
>
> On quinta-feira, 1 de agosto de 2013 13:01:59, Daniel Schemmel wrote:=20
> > Currently the member function "data" of the class template=20
> ::std::array<T,=20
> > N> is defined to return a T* or T const* respectively.=20
> >=20
> > Since the array class template is clearly intended to be a wrapper for =
C=20
> > style arrays, it would make sense to at least allow implementations lik=
e=20
> >=20
> > T (&data() noexcept)[N] { return elems; }=20
> > T const (&data() const noexcept)[N] { return elems; } // could even be=
=20
> > constexpr=20
>
> What's the advantage in doing this? What are do you want to accomplish?=
=20
>
> Are you trying to use decltype or other type detections to create a=20
> similarly-=20
> sized array? Are you trying to match a template function that takes array=
=20
> references?=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
> Software Architect - Intel Open Source Technology Center=20
> PGP/GPG: 0x6EF45358; fingerprint:=20
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358=20
>
=20
The first that has came in the head is std::swap used with regular=20
arrays. For example
=20
std::array<int, 3> a1 =3D { 1, 2, 3 };
int a2[] =3D { 4, 5, 6 };
=20
std::swap( a1.data(), a2 );=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_148_11826637.1375392351444
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
<br>=D0=D1=D4=CE=C9=C3=C1, 2 =C1=D7=C7=D5=D3=D4=C1 2013 =C7., 0:48:34 =
UTC+4 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Thiago Macieira =CE=C1=D0=C9=D3=
=C1=CC:<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-wid=
th: 1px; border-left-style: solid;">On quinta-feira, 1 de agosto de 2013 13=
:01:59, Daniel Schemmel wrote:
<br>> Currently the member function "data" of the class template ::std::=
array<T,
<br>> N> is defined to return a T* or T const* respectively.
<br>>=20
<br>> Since the array class template is clearly intended to be a wrapper=
for C
<br>> style arrays, it would make sense to at least allow implementation=
s like
<br>>=20
<br>> T (&data() noexcept)[N] { return elems; }
<br>> T const (&data() const noexcept)[N] { return elems; } // could=
even be
<br>> constexpr
<br>
<br>What's the advantage in doing this? What are do you want to accomplish?
<br>
<br>Are you trying to use decltype or other type detections to create a sim=
ilarly-
<br>sized array? Are you trying to match a template function that takes arr=
ay=20
<br>references?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br></blockquote><div> </div><div>The first that has came in the head =
is std::swap used with regular arrays. For example</div><div> </d=
iv><div>std::array<int, 3> a1 =3D { 1, 2, 3 };</div><div>int a2[] =3D=
{ 4, 5, 6 };</div><div> </div><div>std::swap( a1.data(), a2 ); <=
/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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_148_11826637.1375392351444--
.
Author: Daniel Schemmel <a@gha.st>
Date: Thu, 1 Aug 2013 15:45:57 -0700 (PDT)
Raw View
------=_Part_200_27013191.1375397157367
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, August 1, 2013 11:18:30 PM UTC+2, Daniel Kr=FCgler wrote:
> 2013/8/1 Daniel Schemmel <a...@gha.st <javascript:>>:=20
> > Currently the member function "data" of the class template=20
> ::std::array<T,=20
> > N> is defined to return a T* or T const* respectively.=20
> >=20
> > Since the array class template is clearly intended to be a wrapper for =
C=20
> > style arrays, it would make sense to at least allow implementations lik=
e=20
> >=20
> > T (&data() noexcept)[N] { return elems; }=20
> > T const (&data() const noexcept)[N] { return elems; } // could even be=
=20
> > constexpr=20
>
> Btw. something similar was already discussed as part of a library issue,=
=20
> see=20
>
> http://cplusplus.github.io/LWG/lwg-closed.html#930=20
>
> Personally I do appreciate the proposal but clearly would prefer a new=20
> function, e.g. c_array or similar.=20
>
> > When changing the wording so that the result of the data function must=
=20
> be=20
> > assignable to a variable of type T* or T const* respectively, the=20
> current=20
> > implementations would not even have to be changed.=20
>
> I'm not sure what you mean here. Clearly existing implementations need=20
> to be changed and I think it would be better to make that clear by a=20
> separate function overload set instead of modifying existing data=20
> functions.=20
>
> This was rejected as library issue, but it would perfectly make sense=20
> to write up a short proposal for it. IMO this addition is both useful=20
> and does not have critical side-effects.=20
>
> - Daniel=20
>
Thanks for digging up the previous proposal, I had been unable to find this=
=20
discussion when searching for something like it. I think it is interesting=
=20
to note that the major reason against making this change seems to have been=
=20
missing usefulness.
When considering the usefulness of this feature, be aware that array is=20
defined to be an aggregate in [array.overview].
Since array is an aggregate, I am only aware of two possible methods to=20
implement it (although they can be mixed):
* A single public member of T[N]
* N consecutive public members of T
(Note that I am unaware of any way to implement "alternate representations=
=20
to allocate the array data dynamically" that were noted as a hurdle in the=
=20
previous proposal. This would at best allow for an initialization like=20
array<int, 2> =3D {{ 1, 2 }}; as far as I am aware.)
While the second option exists, I am not aware of an implementation that=20
actually uses it (nor what benefit it would give).
Therefore, it should not cause any constraints to require that data return=
=20
a reference to that array, or that it be named elems (which is equivalent=
=20
to removing the exposition only comment in the standard), or even adding a=
=20
whole new function.
> Clearly existing implementations need to be changed
When changing the return type of data to be a implementation defined type=
=20
that is assignable to T* or T const*, the existing implementations would=20
not have to be changed - their return type clearly passes this test. The=20
proposed return type passes the same test.
Of course I consider this a significantly inferior solution, since it=20
replaces one implementation defined problem (the name of the array member)=
=20
with another (does it have a T* or T(&)[N] data)....
It does however serve to illustrate that in most cases the result is the=20
same.
The only observable differences that come to mind are:
sizeof yields different results (for naive me, the proposed data() yields=
=20
the expected result)
Variables declared as decltype(auto) should have an array type (variables=
=20
declared as simply auto should not)
The result can _also_ be assigned to references of the proper array type=20
(this may cause overload resolution problems when functions exist with=20
overloads for both - which is esoteric, since they would always cause=20
problems when passed an array reference).
Type inspection (decltype, template specialization or other tricks) will of=
=20
course reveal the return type.
There is no question that the low impact of this change hinges on the fact=
=20
that Array-to-pointer conversion is an implicit standard conversion on the=
=20
same order as lvalue-to-rvalue conversion and function-to-pointer=20
conversion.
--=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_200_27013191.1375397157367
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, August 1, 2013 11:18:30 PM UTC+2, Daniel Kr=FCgler wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">2013/8/1 Daniel Schemmel <<a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"7bfA-W3BnC=
wJ">a...@gha.st</a>>:
<br>> Currently the member function "data" of the class template ::std::=
array<T,
<br>> N> is defined to return a T* or T const* respectively.
<br>>
<br>> Since the array class template is clearly intended to be a wrapper=
for C
<br>> style arrays, it would make sense to at least allow implementation=
s like
<br>>
<br>> T (&data() noexcept)[N] { return elems; }
<br>> T const (&data() const noexcept)[N] { return elems; } // could=
even be
<br>> constexpr
<br>
<br>Btw. something similar was already discussed as part of a library issue=
, see
<br>
<br><a href=3D"http://cplusplus.github.io/LWG/lwg-closed.html#930" target=
=3D"_blank">http://cplusplus.github.io/<wbr>LWG/lwg-closed.html#930</a>
<br>
<br>Personally I do appreciate the proposal but clearly would prefer a new
<br>function, e.g. c_array or similar.
<br>
<br>> When changing the wording so that the result of the data function =
must be
<br>> assignable to a variable of type T* or T const* respectively, the =
current
<br>> implementations would not even have to be changed.
<br>
<br>I'm not sure what you mean here. Clearly existing implementations need
<br>to be changed and I think it would be better to make that clear by a
<br>separate function overload set instead of modifying existing data
<br>functions.
<br>
<br>This was rejected as library issue, but it would perfectly make sense
<br>to write up a short proposal for it. IMO this addition is both useful
<br>and does not have critical side-effects.
<br>
<br>- Daniel
<br></blockquote><div><br></div><div><br></div><div>Thanks for digging up t=
he previous proposal, I had been unable to find this discussion when search=
ing for something like it. I think it is interesting to note that the major=
reason against making this change seems to have been missing usefulness.</=
div><div><br></div><div>When considering the usefulness of this feature, be=
aware that array is defined to be an aggregate in [array.overview].</div><=
div>Since array is an aggregate, I am only aware of two possible methods to=
implement it (although they can be mixed):</div><div>* A single public mem=
ber of T[N]</div><div>* N consecutive public members of T</div><div><br></d=
iv><div>(Note that I am unaware of any way to implement "alternate represen=
tations to allocate the array data dynamically" that were noted as a hurdle=
in the previous proposal. This would at best allow for an initialization l=
ike array<int, 2> =3D {{ 1, 2 }}; as far as I am aware.)</div><div>Wh=
ile the second option exists, I am not aware of an implementation that actu=
ally uses it (nor what benefit it would give).</div><div><br></div><div>The=
refore, it should not cause any constraints to require that data return a r=
eference to that array, or that it be named elems (which is equivalent to r=
emoving the exposition only comment in the standard), or even adding a whol=
e new function.</div><div><br></div><div>> Clearly existing implementati=
ons need to be changed</div><div>When changing the return type of data to b=
e a implementation defined type that is assignable to T* or T const*, the e=
xisting implementations would not have to be changed - their return type cl=
early passes this test. The proposed return type passes the same test.</div=
><div>Of course I consider this a significantly inferior solution, since it=
replaces one implementation defined problem (the name of the array member)=
with another (does it have a T* or T(&)[N] data)....</div><div>It does=
however serve to illustrate that in most cases the result is the same.</di=
v><div><br></div><div>The only observable differences that come to mind are=
:</div><div>sizeof yields different results (for naive me, the proposed dat=
a() yields the expected result)</div><div>Variables declared as decltype(au=
to) should have an array type (variables declared as simply auto should not=
)</div><div>The result can _also_ be assigned to references of the proper a=
rray type (this may cause overload resolution problems when functions exist=
with overloads for both - which is esoteric, since they would always cause=
problems when passed an array reference).</div><div>Type inspection (declt=
ype, template specialization or other tricks) will of course reveal the ret=
urn type.</div><div><br></div><div>There is no question that the low impact=
of this change hinges on the fact that Array-to-pointer conversion is an i=
mplicit standard conversion on the same order as lvalue-to-rvalue conversio=
n and function-to-pointer conversion.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_200_27013191.1375397157367--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Fri, 2 Aug 2013 07:49:08 +0200
Raw View
2013/8/2 Daniel Schemmel <a@gha.st>:
> On Thursday, August 1, 2013 11:18:30 PM UTC+2, Daniel Kr=FCgler wrote:
>>
>> 2013/8/1 Daniel Schemmel <a...@gha.st>:
>> > Currently the member function "data" of the class template
>> > ::std::array<T,
>> > N> is defined to return a T* or T const* respectively.
>> >
>> > Since the array class template is clearly intended to be a wrapper for=
C
>> > style arrays, it would make sense to at least allow implementations li=
ke
>> >
>> > T (&data() noexcept)[N] { return elems; }
>> > T const (&data() const noexcept)[N] { return elems; } // could even be
>> > constexpr
>>
>> Btw. something similar was already discussed as part of a library issue,
>> see
>>
>> http://cplusplus.github.io/LWG/lwg-closed.html#930
>>
>> Personally I do appreciate the proposal but clearly would prefer a new
>> function, e.g. c_array or similar.
>>
>> > When changing the wording so that the result of the data function must
>> > be
>> > assignable to a variable of type T* or T const* respectively, the
>> > current
>> > implementations would not even have to be changed.
>>
>> I'm not sure what you mean here. Clearly existing implementations need
>> to be changed and I think it would be better to make that clear by a
>> separate function overload set instead of modifying existing data
>> functions.
>>
>> This was rejected as library issue, but it would perfectly make sense
>> to write up a short proposal for it. IMO this addition is both useful
>> and does not have critical side-effects.
>>
>> - Daniel
>
> Thanks for digging up the previous proposal, I had been unable to find th=
is
> discussion when searching for something like it. I think it is interestin=
g
> to note that the major reason against making this change seems to have be=
en
> missing usefulness.
I agree.
> When considering the usefulness of this feature, be aware that array is
> defined to be an aggregate in [array.overview].
I'm aware of that.
> Since array is an aggregate, I am only aware of two possible methods to
> implement it (although they can be mixed):
> * A single public member of T[N]
> * N consecutive public members of T
An aggregate can have normal member functions and this should suffice
to realize the job. I don't see any usefulness in suggesting x times N
members (The x possibly reflecting variants of cv-qualifications and
or ref-qualifications). But it is fine to present these choices as
part of the paper discussion section.
> Therefore, it should not cause any constraints to require that data retur=
n a
> reference to that array, or that it be named elems (which is equivalent t=
o
> removing the exposition only comment in the standard), or even adding a
> whole new function.
std::array has "implanted" element type and array size, so there can
be member functions that returns a reference to array of N
const/non-const T.
>> Clearly existing implementations need to be changed
> When changing the return type of data to be a implementation defined type
> that is assignable to T* or T const*, the existing implementations would =
not
> have to be changed - their return type clearly passes this test.
When I'm speaking of "changing existing implementations" this includes
adding member functions or changing the return type of existing member
functions. I'm not talking about tests. And keep in mind that changing
the return type *is* even user-observable given simple ways to test
that via decltype or overloaded function templates.
I can assure you that you make your proposal unnecessary complicated
and more controversial if you really suggest to change the data()
function. Better add a new one with a clear new meaning.
Again, it is fine and recommended, though, to present such choices
part of the discussion of the proposal.
- Daniel
--=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: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sun, 4 Aug 2013 03:25:16 -0700 (PDT)
Raw View
------=_Part_1_23619469.1375611916572
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, August 1, 2013 10:01:59 PM UTC+2, Daniel Schemmel wrote:
>
> T (&data() noexcept)[N] { return elems; }
> T const (&data() const noexcept)[N] { return elems; } // could even be
> constexpr
>
>
>
> Is this a typo or is this valid syntax?
Why is the [N] after the function name and after noexcept?
--
---
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_1_23619469.1375611916572
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, August 1, 2013 10:01:59 PM UTC+2, Daniel Schemmel wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div><br></div><div><div style=
=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);wor=
d-wrap:break-word"><code><div><span style=3D"color:#000">T </span><span sty=
le=3D"color:#660">(&</span><span style=3D"color:#000">data</span><span =
style=3D"color:#660">()</span><span style=3D"color:#000"> noexcept</span><s=
pan style=3D"color:#660">)[</span><span style=3D"color:#000">N</span><span =
style=3D"color:#660">]</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">return</span><span style=3D"color:#000"> elems</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">}</span><span style=3D"color:#000"><br>T </span><span style=3D"c=
olor:#008">const</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">(&</span><span style=3D"color:#000">data</span><span style=3D=
"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#008">const</span><span style=3D"color:#000"> noexcept</span><span style=
=3D"color:#660">)[</span><span style=3D"color:#000">N</span><span style=3D"=
color:#660">]</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:#008=
">return</span><span style=3D"color:#000"> elems</span><span style=3D"color=
:#660">;</span><span style=3D"color:#000"> </span><span style=3D"color:#660=
">}</span><span style=3D"color:#000"> </span><span style=3D"color:#800">// =
could even be constexpr</span><span style=3D"color:#000"><br></span></div><=
/code></div><pre style=3D"font-family:Consolas"><span style=3D"color:black"=
><br></span></pre><pre style=3D"font-family:Consolas"><br></pre></div></blo=
ckquote><div>Is this a typo or is this valid syntax?</div><div>Why is the [=
N] after the function name and after noexcept?</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_1_23619469.1375611916572--
.
Author: Daniel Schemmel <a@gha.st>
Date: Sun, 4 Aug 2013 04:00:24 -0700 (PDT)
Raw View
------=_Part_60_4405412.1375614025003
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, August 4, 2013 12:25:16 PM UTC+2, Olaf van der Spek wrote:
>
> On Thursday, August 1, 2013 10:01:59 PM UTC+2, Daniel Schemmel wrote:
>
>>
>> T (&data() noexcept)[N] { return elems; }
>> T const (&data() const noexcept)[N] { return elems; } // could even be
>> constexpr
>>
>>
>>
>> Is this a typo or is this valid syntax?
> Why is the [N] after the function name and after noexcept?
>
It is indeed valid syntax.
In "plain" english this reads: Declare data to be a (const and noexcept)
function that returns a reference to an array of N (const) elements of type
T.
If you prefer, you can write it with typedefs:
typedef T arr[N];
typedef arr& arr_ref;
arr_ref data() noexcept { return elems; }
constexpr arr_ref data() const noexcept { return elems; }
--
---
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_60_4405412.1375614025003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, August 4, 2013 12:25:16 PM UTC+2, Olaf van der Spek wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On Thursday, August 1, 2013 =
10:01:59 PM UTC+2, Daniel Schemmel wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div><br></div><div><div style=3D"background-color:rgb(250,250,25=
0);border:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span=
style=3D"color:#000">T </span><span style=3D"color:#660">(&</span><spa=
n style=3D"color:#000">data</span><span style=3D"color:#660">()</span><span=
style=3D"color:#000"> noexcept</span><span style=3D"color:#660">)[</span><=
span style=3D"color:#000">N</span><span style=3D"color:#660">]</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">return</span><span style=
=3D"color:#000"> elems</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">}</span><span style=3D"c=
olor:#000"><br>T </span><span style=3D"color:#008">const</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">(&</span><span style=
=3D"color:#000">data</span><span style=3D"color:#660">()</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">const</span><span style=
=3D"color:#000"> noexcept</span><span style=3D"color:#660">)[</span><span s=
tyle=3D"color:#000">N</span><span style=3D"color:#660">]</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">return</span><span style=3D"c=
olor:#000"> elems</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">}</span><span style=3D"color:=
#000"> </span><span style=3D"color:#800">// could even be constexpr</span><=
span style=3D"color:#000"><br></span></div></code></div><pre style=3D"font-=
family:Consolas"><span style=3D"color:black"><br></span></pre><pre style=3D=
"font-family:Consolas"><br></pre></div></blockquote><div>Is this a typo or =
is this valid syntax?</div><div>Why is the [N] after the function name and =
after noexcept?</div></blockquote><div><br></div><div>It is indeed valid sy=
ntax.</div><div><br></div><div>In "plain" english this reads: Declare data =
to be a (const and noexcept) function that returns a reference to an array =
of N (const) elements of type T.</div><div><br></div><div>If you prefer, yo=
u can write it with typedefs:</div><div><div class=3D"prettyprint" style=3D=
"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187)=
; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><font color=3D"#660066"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">typedef</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> T arr</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
N</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: #008;" class=3D"styled-by-prettify">typedef</span><span sty=
le=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-prettify"> arr_ref</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>arr_ref data</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" clas=
s=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"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> elems</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></font><pre style=
=3D"font-family:Consolas;font-size:14;color:black;background:white;"><span =
style=3D"color: #008;" class=3D"styled-by-prettify">constexpr</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> arr_ref data</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
:blue;"><span style=3D"color: #008;" class=3D"styled-by-prettify">const</sp=
an></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> noexce=
pt </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color:blue;"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span></span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> elems</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></pre></div></=
code></div><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_60_4405412.1375614025003--
.