Topic: Merging raw and std:array
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Fri, 11 Jan 2013 05:32:30 -0800 (PST)
Raw View
------=_Part_763_13482348.1357911150351
Content-Type: text/plain; charset=ISO-8859-1
int a[] = { 1, 2, 3 };
Wouldn't it be possible to have a.data(), a.size(), a.begin(), a.end() etc
just work?
The idea is for a to behave like an ordinary array except when a member is
requested.
--
------=_Part_763_13482348.1357911150351
Content-Type: text/html; charset=ISO-8859-1
int a[] = { 1, 2, 3 };<div><br></div><div>Wouldn't it be possible to have a.data(), a.size(), a.begin(), a.end() etc just work?</div><div>The idea is for a to behave like an ordinary array except when a member is requested.</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_763_13482348.1357911150351--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Fri, 11 Jan 2013 14:42:12 +0100
Raw View
2013/1/11 Olaf van der Spek <olafvdspek@gmail.com>:
> int a[] = { 1, 2, 3 };
>
> Wouldn't it be possible to have a.data(), a.size(), a.begin(), a.end() etc
> just work?
> The idea is for a to behave like an ordinary array except when a member is
> requested.
A rule of thumb is that if there exists a reasonable way for a library
solution, a core language change is less preferred. Now given the fact
that C++11 provides std::array with exactly these features my guess is
that a corresponding core language change is rather unlikely.
Furthermore, C arrays do have several very "irregular" features (among
them that they are not copy-constructible), so there is generally not
too much interest in providing very much efforts to extend these types
(Smaller extensions had been considered in the past, though).
So, if you have strong interest in that feature I suggest to provide a
bit more rationale for that extension request.
- Daniel
--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Fri, 11 Jan 2013 13:33:15 -0800 (PST)
Raw View
------=_Part_818_33458608.1357939995841
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Well. It already has, just in the new way that is preferred:
int a[] =3D { 1,2,3 };
for(auto it =3D std::begin(a); it !=3D std::end(a); ++it)
{
std::cout << a << std::endl;
}
std::vector<int> a =3D { 1,2,3 };
for(auto it =3D std::begin(a); it !=3D std::end(a); ++it)
{
std::cout << a << std::endl;
}
Apart from the type, 100% same. Ranged-based for ( for( auto&& i : a) )=20
also works.
Regards, Robert
2013. janu=C3=A1r 11., p=C3=A9ntek 14:32:30 UTC+1 id=C5=91pontban Olaf van =
der Spek a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> int a[] =3D { 1, 2, 3 };
>
> Wouldn't it be possible to have a.data(), a.size(), a.begin(), a.end() et=
c=20
> just work?
> The idea is for a to behave like an ordinary array except when a member i=
s=20
> requested.
>
--=20
------=_Part_818_33458608.1357939995841
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
Well. It already has, just in the new way that is preferred:<br><br><div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">[]</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #066;" =
class=3D"styled-by-prettify">3</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-prettif=
y"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">for=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> it </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> std::</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">begin</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">a</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> it </span><span style=3D"color: #660;" class=3D"styled-by-prettify">!=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify"><code class=3D"pret=
typrint"><span style=3D"color: #000;" class=3D"styled-by-prettify">std::</s=
pan></code>end</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</sp=
an><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">it</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> std</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><<</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
a </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">endl</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br>std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::vector</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify"><int></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><code class=3D"prettyprint"><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: #066;" class=3D"styled-by-prettify=
">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">2</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">3</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"styl=
ed-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">for</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> it </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span></code><code clas=
s=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">std::</span></code></span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">begin</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> it </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">!=3D</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span></code><code c=
lass=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"style=
d-by-prettify">std::</span></code></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">end</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">a</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 sty=
le=3D"color: #000;" class=3D"styled-by-prettify">it</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br> std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">cout </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> a </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">endl</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><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span></code></div></code></div><br=
>Apart from the type, 100% same. Ranged-based for ( <span style=3D"font-fam=
ily: courier new,monospace;">for( auto&& i : a)</span> ) also works=
..<br><br>Regards, Robert<br><br>2013. janu=E1r 11., p=E9ntek 14:32:30 UTC+1=
id=F5pontban Olaf van der Spek a k=F6vetkez=F5t =EDrta:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">int a[] =3D { 1, 2, 3 };<div><br></div><div>Wou=
ldn't it be possible to have a.data(), a.size(), a.begin(), a.end() etc jus=
t work?</div><div>The idea is for a to behave like an ordinary array except=
when a member is requested.</div></blockquote>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_818_33458608.1357939995841--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 11 Jan 2013 16:02:53 -0600
Raw View
--0015174c12ce85709204d30a7726
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 11 January 2013 07:42, Daniel Kr=FCgler <daniel.kruegler@gmail.com> wrot=
e:
> 2013/1/11 Olaf van der Spek <olafvdspek@gmail.com>:
> > int a[] =3D { 1, 2, 3 };
> >
> > Wouldn't it be possible to have a.data(), a.size(), a.begin(), a.end()
> etc
> > just work?
> > The idea is for a to behave like an ordinary array except when a member
> is
> > requested.
>
> A rule of thumb is that if there exists a reasonable way for a library
> solution, a core language change is less preferred.
That being said, there has been mention on more than one occasion that the
calling syntax x.foo() and foo(x) in general be synonyms. But the devil is
in the details, and I have not seen a concrete proposal for that.
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=20
--0015174c12ce85709204d30a7726
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 11 January 2013 07:42, Daniel Kr=FCgler <span dir=3D"ltr"><<a href=3D=
"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gmail.=
com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
2013/1/11 Olaf van der Spek <<a href=3D"mailto:olafvdspek@gmail.com">ola=
fvdspek@gmail.com</a>>:<br>
<div><div class=3D"h5">> int a[] =3D { 1, 2, 3 };<br>
><br>
> Wouldn't it be possible to have a.data(), a.size(), a.begin(), a.e=
nd() etc<br>
> just work?<br>
> The idea is for a to behave like an ordinary array except when a membe=
r is<br>
> requested.<br>
<br>
</div></div>A rule of thumb is that if there exists a reasonable way for a =
library<br>
solution, a core language change is less preferred.</blockquote><div><br>Th=
at being said, there has been mention on more than one occasion that the ca=
lling syntax x.foo() and foo(x) in general be synonyms.=A0 But the devil is=
in the details, and I have not seen a concrete proposal for that.<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
<br />
<br />
--0015174c12ce85709204d30a7726--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sat, 12 Jan 2013 17:32:57 +0100
Raw View
On Fri, Jan 11, 2013 at 2:42 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
> 2013/1/11 Olaf van der Spek <olafvdspek@gmail.com>:
>> int a[] =3D { 1, 2, 3 };
>>
>> Wouldn't it be possible to have a.data(), a.size(), a.begin(), a.end() e=
tc
>> just work?
>> The idea is for a to behave like an ordinary array except when a member =
is
>> requested.
>
> A rule of thumb is that if there exists a reasonable way for a library
> solution, a core language change is less preferred. Now given the fact
> that C++11 provides std::array with exactly these features my guess is
> that a corresponding core language change is rather unlikely.
>
> Furthermore, C arrays do have several very "irregular" features (among
> them that they are not copy-constructible), so there is generally not
> too much interest in providing very much efforts to extend these types
> (Smaller extensions had been considered in the past, though).
>
> So, if you have strong interest in that feature I suggest to provide a
> bit more rationale for that extension request.
It's more of a just-curious than a high-priority thing at the moment.
Raw arrays support size-deduction and syntax is shorter.
It's also general curiosity of whether native types could have some
class-like features.
--=20
Olaf
--=20
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Sat, 12 Jan 2013 09:52:34 -0800 (PST)
Raw View
------=_Part_106_15012472.1358013154415
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, January 11, 2013 5:42:12 PM UTC+4, Daniel Kr=FCgler wrote:
>
>
> Furthermore, C arrays do have several very "irregular" features (among=20
> them that they are not copy-constructible), so there is generally not=20
> too much interest in providing very much efforts to extend these types=20
> (Smaller extensions had been considered in the past, though).=20
>
It would be interesting to find out why arrays are still always=20
non-copyable and non-movable.
// implemented in a library written on C
extern "C" void play_stereo_sound(
double (*pulse_seq)[2],
uint32_t pulse_seq_size);
void play_sound(std::vector<double[2]> const &pulse_seq)
{
play_stereo_sound(pulse_seq.data(), pulse_seq.size());
}
// composes a music from notes
std::vector<double[2]> gen_music(notes_t notes);
void play_music(notes_t notes)
{
play_sound(gen_music(notes));
}
=20
What code would the committee suggest to use instead of this one and why?
--=20
------=_Part_106_15012472.1358013154415
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, January 11, 2013 5:42:12 PM UTC+4, Daniel Kr=FCgler wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">
<br>Furthermore, C arrays do have several very "irregular" features (among
<br>them that they are not copy-constructible), so there is generally not
<br>too much interest in providing very much efforts to extend these types
<br>(Smaller extensions had been considered in the past, though).
<br></blockquote><div><br>It would be interesting to find out why arrays ar=
e still always non-copyable and non-movable.<br><br> // i=
mplemented in a library written on C<br> extern "C" void =
play_stereo_sound(<br> double (*p=
ulse_seq)[2],<br> uint32_t pulse_=
seq_size);<br><br> void play_sound(std::vector<double[=
2]> const &pulse_seq)<br> {<br> &=
nbsp; play_stereo_sound(pulse_seq.data(), pulse_seq.size(=
));<br> }<br><br> // composes a music f=
rom notes<br> std::vector<double[2]> gen_music(note=
s_t notes);<br><br> void play_music(notes_t notes)<br>&nb=
sp; {<br> play_sound(=
gen_music(notes));<br> }<br> <br>What code would the=
committee suggest to use instead of this one and why?<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_106_15012472.1358013154415--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 12 Jan 2013 10:24:12 -0800 (PST)
Raw View
------=_Part_177_27868993.1358015052901
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, January 12, 2013 9:52:34 AM UTC-8, Nikolay Ivchenkov wrote:
>
> On Friday, January 11, 2013 5:42:12 PM UTC+4, Daniel Kr=FCgler wrote:
>>
>>
>> Furthermore, C arrays do have several very "irregular" features (among=
=20
>> them that they are not copy-constructible), so there is generally not=20
>> too much interest in providing very much efforts to extend these types=
=20
>> (Smaller extensions had been considered in the past, though).=20
>>
>
> It would be interesting to find out why arrays are still always=20
> non-copyable and non-movable.
>
> // implemented in a library written on C
> extern "C" void play_stereo_sound(
> double (*pulse_seq)[2],
> uint32_t pulse_seq_size);
>
> void play_sound(std::vector<double[2]> const &pulse_seq)
> {
> play_stereo_sound(pulse_seq.data(), pulse_seq.size());
> }
>
> // composes a music from notes
> std::vector<double[2]> gen_music(notes_t notes);
>
> void play_music(notes_t notes)
> {
> play_sound(gen_music(notes));
> }
> =20
> What code would the committee suggest to use instead of this one and why?
>
`std::array`. That's what you should be using if you want a working array=
=20
type. That's why it exists: so that you can have the reasonable properties=
=20
of arrays (aggregates, standard-layout, etc) without the downsides.
--=20
------=_Part_177_27868993.1358015052901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, January 12, 2013 9:52:34 AM UTC-8, Nikolay Ivchenkov wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Friday, January 11, 2013 5:42:=
12 PM UTC+4, Daniel Kr=FCgler wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<br>Furthermore, C arrays do have several very "irregular" features (among
<br>them that they are not copy-constructible), so there is generally not
<br>too much interest in providing very much efforts to extend these types
<br>(Smaller extensions had been considered in the past, though).
<br></blockquote><div><br>It would be interesting to find out why arrays ar=
e still always non-copyable and non-movable.<br><br> // i=
mplemented in a library written on C<br> extern "C" void =
play_stereo_sound(<br> double (*p=
ulse_seq)[2],<br> uint32_t pulse_=
seq_size);<br><br> void play_sound(std::vector<double[=
<wbr>2]> const &pulse_seq)<br> {<br> &n=
bsp; play_stereo_sound(pulse_seq.<wbr>data(), pulse=
_seq.size());<br> }<br><br> // composes=
a music from notes<br> std::vector<double[2]> gen_=
music(notes_t notes);<br><br> void play_music(notes_t not=
es)<br> {<br> p=
lay_sound(gen_music(notes));<br> }<br> <br>What code=
would the committee suggest to use instead of this one and why?<br></div><=
/blockquote><div><br>`std::array`. That's what you should be using if you w=
ant a working array type. That's why it exists: so that you can have the re=
asonable properties of arrays (aggregates, standard-layout, etc) without th=
e downsides.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_177_27868993.1358015052901--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Sat, 12 Jan 2013 10:31:22 -0800 (PST)
Raw View
------=_Part_1755_29066661.1358015482339
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, January 12, 2013 10:24:12 PM UTC+4, Nicol Bolas wrote:
>
> On Saturday, January 12, 2013 9:52:34 AM UTC-8, Nikolay Ivchenkov wrote:
>>
>> On Friday, January 11, 2013 5:42:12 PM UTC+4, Daniel Kr=FCgler wrote:
>>>
>>>
>>> Furthermore, C arrays do have several very "irregular" features (among=
=20
>>> them that they are not copy-constructible), so there is generally not=
=20
>>> too much interest in providing very much efforts to extend these types=
=20
>>> (Smaller extensions had been considered in the past, though).=20
>>>
>>
>> It would be interesting to find out why arrays are still always=20
>> non-copyable and non-movable.
>>
>> // implemented in a library written on C
>> extern "C" void play_stereo_sound(
>> double (*pulse_seq)[2],
>> uint32_t pulse_seq_size);
>>
>> void play_sound(std::vector<double[2]> const &pulse_seq)
>> {
>> play_stereo_sound(pulse_seq.data(), pulse_seq.size());
>> }
>>
>> // composes a music from notes
>> std::vector<double[2]> gen_music(notes_t notes);
>>
>> void play_music(notes_t notes)
>> {
>> play_sound(gen_music(notes));
>> }
>> =20
>> What code would the committee suggest to use instead of this one and why=
?
>>
>
> `std::array`.
>
That's not a code. How exactly would you apply std::array here?
--=20
------=_Part_1755_29066661.1358015482339
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, January 12, 2013 10:24:12 PM UTC+4, Nicol Bolas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On Saturday, January 12, 2013 9:52:34 =
AM UTC-8, Nikolay Ivchenkov wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On Friday, January 11, 2013 5:42:12 PM UTC+4, Daniel Kr=FCgler wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<br>Furthermore, C arrays do have several very "irregular" features (among
<br>them that they are not copy-constructible), so there is generally not
<br>too much interest in providing very much efforts to extend these types
<br>(Smaller extensions had been considered in the past, though).
<br></blockquote><div><br>It would be interesting to find out why arrays ar=
e still always non-copyable and non-movable.<br><br> // i=
mplemented in a library written on C<br> extern "C" void =
play_stereo_sound(<br> double (*p=
ulse_seq)[2],<br> uint32_t pulse_=
seq_size);<br><br> void play_sound(std::vector<double[=
<wbr>2]> const &pulse_seq)<br> {<br> &n=
bsp; play_stereo_sound(pulse_seq.<wbr>data(), pulse=
_seq.size());<br> }<br><br> // composes=
a music from notes<br> std::vector<double[2]> gen_=
music(notes_t notes);<br><br> void play_music(notes_t not=
es)<br> {<br> p=
lay_sound(gen_music(notes));<br> }<br> <br>What code=
would the committee suggest to use instead of this one and why?<br></div><=
/blockquote><div><br>`std::array`.<br></div></blockquote><div><br>That's no=
t a code. How exactly would you apply std::array here?<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1755_29066661.1358015482339--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 12 Jan 2013 14:43:48 -0800 (PST)
Raw View
------=_Part_21_3769886.1358030628563
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, January 12, 2013 10:31:22 AM UTC-8, Nikolay Ivchenkov wrote:
>
> On Saturday, January 12, 2013 10:24:12 PM UTC+4, Nicol Bolas wrote:
>>
>> On Saturday, January 12, 2013 9:52:34 AM UTC-8, Nikolay Ivchenkov wrote:
>>>
>>> On Friday, January 11, 2013 5:42:12 PM UTC+4, Daniel Kr=FCgler wrote:
>>>>
>>>>
>>>> Furthermore, C arrays do have several very "irregular" features (among=
=20
>>>> them that they are not copy-constructible), so there is generally not=
=20
>>>> too much interest in providing very much efforts to extend these types=
=20
>>>> (Smaller extensions had been considered in the past, though).=20
>>>>
>>>
>>> It would be interesting to find out why arrays are still always=20
>>> non-copyable and non-movable.
>>>
>>> // implemented in a library written on C
>>> extern "C" void play_stereo_sound(
>>> double (*pulse_seq)[2],
>>> uint32_t pulse_seq_size);
>>>
>>> void play_sound(std::vector<double[2]> const &pulse_seq)
>>> {
>>> play_stereo_sound(pulse_seq.data(), pulse_seq.size());
>>> }
>>>
>>> // composes a music from notes
>>> std::vector<double[2]> gen_music(notes_t notes);
>>>
>>> void play_music(notes_t notes)
>>> {
>>> play_sound(gen_music(notes));
>>> }
>>> =20
>>> What code would the committee suggest to use instead of this one and wh=
y?
>>>
>>
>> `std::array`.
>>
>
> That's not a code. How exactly would you apply std::array here?
>
Hmm. I was going to post the obvious solution, with a 1:1 substitution:
typedef double (*PulseSequenceType)[2];
void play_sound(std::vector<std::array<double,2>> const &pulse_seq)
{
play_stereo_sound((PulseSequenceType)(pulse_seq.data()),
pulse_seq.size());
}
// composes a music from notes
std::vector<std::array<double,2>> gen_music(notes_t notes);
void play_music(notes_t notes)
{
play_sound(gen_music(notes));
}
Then I was going to explain how C++11's new standard-layout and=20
layout-compatibility rules require the cast in `play_sound` to work. Then I=
=20
went to find the section in the standard that says that `std::array<Type,=
=20
N>` and `Type[N]` are layout-compatible.
The problem is... there's no such section.
The standard explains when two classes are layout-compatible. It explains=
=20
when two unions are layout-compatible. But it doesn't require=20
layout-compatibility between an array and a standard-layout class that=20
contains a single array. And therefore, it doesn't require an array of=20
classes that contain an array to be layout-compatible with an array of=20
arrays of the same type and size.
This sounds like an oversight to me. There should probably be some language=
=20
somewhere in the standard that says that a standard-layout struct that has=
=20
as a member exactly one array of some length is layout-compatible with an=
=20
array of the same type.
That being said, I defy you to show me a compiler on which the above code=
=20
won't run...
--=20
------=_Part_21_3769886.1358030628563
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Saturday, January 12, 2013 10:31:22 AM UTC-8, Nikolay Ivchenkov =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, January 12,=
2013 10:24:12 PM UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">On Saturday, January 12, 2013 9:52:34 AM UTC-8, Nikolay Ivchenkov w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">On Friday, January 11, 2013 5:=
42:12 PM UTC+4, Daniel Kr=FCgler wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex">
<br>Furthermore, C arrays do have several very "irregular" features (among
<br>them that they are not copy-constructible), so there is generally not
<br>too much interest in providing very much efforts to extend these types
<br>(Smaller extensions had been considered in the past, though).
<br></blockquote><div><br>It would be interesting to find out why arrays ar=
e still always non-copyable and non-movable.<br><br> // i=
mplemented in a library written on C<br> extern "C" void =
play_stereo_sound(<br> double (*p=
ulse_seq)[2],<br> uint32_t pulse_=
seq_size);<br><br> void play_sound(std::vector<double[=
<wbr>2]> const &pulse_seq)<br> {<br> &n=
bsp; play_stereo_sound(pulse_seq.<wbr>data(), pulse=
_seq.size());<br> }<br><br> // composes=
a music from notes<br> std::vector<double[2]> gen_=
music(notes_t notes);<br><br> void play_music(notes_t not=
es)<br> {<br> p=
lay_sound(gen_music(notes));<br> }<br> <br>What code=
would the committee suggest to use instead of this one and why?<br></div><=
/blockquote><div><br>`std::array`.<br></div></blockquote><div><br>That's no=
t a code. How exactly would you apply std::array here?<br></div></blockquot=
e><div><br>Hmm. I was going to post the obvious solution, with a 1:1 substi=
tution:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">typedef</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">double</s=
pan><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: #606;" class=3D"styled-by-prettify">PulseSequenceType</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)[</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">2</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">];</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> play_sound</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>vector</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">array</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">double</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #066;" c=
lass=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">>></span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">pulse_seq</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> play_stereo_sound<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">((</span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">PulseSequenceType</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">pulse_seq</span><spa=
n 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"co=
lor: #660;" class=3D"styled-by-prettify">()),</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> pulse_se=
q</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">size</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><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #800;"=
class=3D"styled-by-prettify">// composes a music from notes</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">vector</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">array</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">double</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #066;" class=3D"styled-by-prettify">2</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">>></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> gen_music</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">notes_t notes</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> play_music</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">notes_t notes</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br> play_sound</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">gen_music</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">notes</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
));</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></cod=
e></div><br>Then I was going to explain how C++11's new standard-layout and=
layout-compatibility rules require the cast in `play_sound` to work. Then =
I went to find the section in the standard that says that `std::array<Ty=
pe, N>` and `Type[N]` are layout-compatible.<br><br>The problem is... th=
ere's no such section.<br><br>The standard explains when two classes are la=
yout-compatible. It explains when two unions are layout-compatible. But it =
doesn't require layout-compatibility between an array and a standard-layout=
class that contains a single array. And therefore, it doesn't require an a=
rray of classes that contain an array to be layout-compatible with an array=
of arrays of the same type and size.<br><br>This sounds like an oversight =
to me. There should probably be some language somewhere in the standard tha=
t says that a standard-layout struct that has as a member exactly one array=
of some length is layout-compatible with an array of the same type.<br><br=
>That being said, I defy you to show me a compiler on which the above code =
won't run...<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_21_3769886.1358030628563--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Sun, 13 Jan 2013 01:45:11 -0800 (PST)
Raw View
------=_Part_1_22462987.1358070311467
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, January 13, 2013 2:43:48 AM UTC+4, Nicol Bolas wrote:
>
> On Saturday, January 12, 2013 10:31:22 AM UTC-8, Nikolay Ivchenkov wrote:
>>
>>
>> How exactly would you apply std::array here?
>>
>
> Hmm. I was going to post the obvious solution, with a 1:1 substitution:
>
You may be sure that I already considered such a solution.
Then I was going to explain how C++11's new standard-layout and
> layout-compatibility rules require the cast in `play_sound` to work. Then I
> went to find the section in the standard that says that `std::array<Type,
> N>` and `Type[N]` are layout-compatible.
>
> The problem is... there's no such section.
>
Aha, the devil is in the details.
That being said, I defy you to show me a compiler on which the above code
> won't run...
>
Why should I use such opaque hacks in order to solve a trivial problem? If
we don't have a hammer, we could hammer in nails with an electric iron, but
I don't like such workarounds much.
--
------=_Part_1_22462987.1358070311467
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, January 13, 2013 2:43:48 AM UTC+4, Nicol Bolas wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On Saturday, January 12, 2013 10:31:22 AM=
UTC-8, Nikolay Ivchenkov wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v><br>How exactly would you apply std::array here?<br></div></blockquote><d=
iv><br>Hmm. I was going to post the obvious solution, with a 1:1 substituti=
on:<br></div></blockquote><div><br>You may be sure that I already considere=
d such a solution.<br><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div>Then I was going to explain how C++11's new standard-layout and layo=
ut-compatibility rules require the cast in `play_sound` to work. Then I wen=
t to find the section in the standard that says that `std::array<Type, N=
>` and `Type[N]` are layout-compatible.<br><br>The problem is... there's=
no such section.<br></div></blockquote><div><br>Aha, the devil is in the d=
etails.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>That=
being said, I defy you to show me a compiler on which the above code won't=
run...<br></div></blockquote><div><br>Why should I use such opaque hacks i=
n order to solve a trivial problem? If we don't have a hammer, we could ham=
mer in nails with an electric iron, but I don't like such workarounds much.=
<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1_22462987.1358070311467--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 13 Jan 2013 10:44:08 -0800 (PST)
Raw View
------=_Part_587_5514596.1358102648038
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, January 13, 2013 1:45:11 AM UTC-8, Nikolay Ivchenkov wrote:
>
> On Sunday, January 13, 2013 2:43:48 AM UTC+4, Nicol Bolas wrote:
>>
>> On Saturday, January 12, 2013 10:31:22 AM UTC-8, Nikolay Ivchenkov wrote:
>>>
>>>
>>> How exactly would you apply std::array here?
>>>
>>
>> Hmm. I was going to post the obvious solution, with a 1:1 substitution:
>>
>
> You may be sure that I already considered such a solution.
>
> Then I was going to explain how C++11's new standard-layout and
>> layout-compatibility rules require the cast in `play_sound` to work. Then I
>> went to find the section in the standard that says that `std::array<Type,
>> N>` and `Type[N]` are layout-compatible.
>>
>> The problem is... there's no such section.
>>
>
> Aha, the devil is in the details.
>
> That being said, I defy you to show me a compiler on which the above code
>> won't run...
>>
>
> Why should I use such opaque hacks in order to solve a trivial problem? If
> we don't have a hammer, we could hammer in nails with an electric iron, but
> I don't like such workarounds much.
>
It's not a hack or workaround. std::array is intended to be a replacement
for C arrays. One that doesn't implicitly decay to pointers, that can be
copied/moved, and so forth.
The only problem presently is that there is no language-level guarantee
that std::array has the same size and layout as the equivalent C array. But
this is a guarantee the language could provide, which is far less
disruptive to the language than trying to make C arrays behave like
std::array. And it's also more useful, as it would affect other things too.
--
------=_Part_587_5514596.1358102648038
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, January 13, 2013 1:45:11 AM UTC-8, Nikolay Ivchenkov wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Sunday, January 13, 2013=
2:43:48 AM UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
">On Saturday, January 12, 2013 10:31:22 AM UTC-8, Nikolay Ivchenkov wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div><br>How exactly would you appl=
y std::array here?<br></div></blockquote><div><br>Hmm. I was going to post =
the obvious solution, with a 1:1 substitution:<br></div></blockquote><div><=
br>You may be sure that I already considered such a solution.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>Then I was going to explain ho=
w C++11's new standard-layout and layout-compatibility rules require the ca=
st in `play_sound` to work. Then I went to find the section in the standard=
that says that `std::array<Type, N>` and `Type[N]` are layout-compat=
ible.<br><br>The problem is... there's no such section.<br></div></blockquo=
te><div><br>Aha, the devil is in the details.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div>That being said, I defy you to show me a compi=
ler on which the above code won't run...<br></div></blockquote><div><br>Why=
should I use such opaque hacks in order to solve a trivial problem? If we =
don't have a hammer, we could hammer in nails with an electric iron, but I =
don't like such workarounds much.<br></div></blockquote><div><br>It's not a=
hack or workaround. std::array is intended to be a replacement for C array=
s. One that doesn't implicitly decay to pointers, that can be copied/moved,=
and so forth.<br><br>The only problem presently is that there is no langua=
ge-level guarantee that std::array has the same size and layout as the equi=
valent C array. But this is a guarantee the language could provide, which i=
s far less disruptive to the language than trying to make C arrays behave l=
ike std::array. And it's also more useful, as it would affect other things =
too.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_587_5514596.1358102648038--
.
Author: Alberto Ganesh Barbati <albertobarbati@gmail.com>
Date: Sun, 13 Jan 2013 22:45:05 +0100
Raw View
--Apple-Mail=_5DFE6E3B-4248-4238-8CF1-5DAB47D68C5B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Il giorno 13/gen/2013, alle ore 19:44, Nicol Bolas <jmckesson@gmail.com> ha=
scritto:
>=20
>=20
> On Sunday, January 13, 2013 1:45:11 AM UTC-8, Nikolay Ivchenkov wrote:
> On Sunday, January 13, 2013 2:43:48 AM UTC+4, Nicol Bolas wrote:
> On Saturday, January 12, 2013 10:31:22 AM UTC-8, Nikolay Ivchenkov wrote:
>=20
> How exactly would you apply std::array here?
>=20
> Hmm. I was going to post the obvious solution, with a 1:1 substitution:
>=20
> You may be sure that I already considered such a solution.
>=20
> Then I was going to explain how C++11's new standard-layout and layout-co=
mpatibility rules require the cast in `play_sound` to work. Then I went to =
find the section in the standard that says that `std::array<Type, N>` and `=
Type[N]` are layout-compatible.
>=20
> The problem is... there's no such section.
>=20
> Aha, the devil is in the details.
>=20
> That being said, I defy you to show me a compiler on which the above code=
won't run...
>=20
> Why should I use such opaque hacks in order to solve a trivial problem? I=
f we don't have a hammer, we could hammer in nails with an electric iron, b=
ut I don't like such workarounds much.
>=20
> It's not a hack or workaround. std::array is intended to be a replacement=
for C arrays. One that doesn't implicitly decay to pointers, that can be c=
opied/moved, and so forth.
>=20
> The only problem presently is that there is no language-level guarantee t=
hat std::array has the same size and layout as the equivalent C array. But =
this is a guarantee the language could provide, which is far less disruptiv=
e to the language than trying to make C arrays behave like std::array. And =
it's also more useful, as it would affect other things too.
>=20
Let's consider that the standard library does actually provide a similar gu=
arantee for std::complex<> (see 26.4/4). That could be take as a precedent =
for a proposal extending such guarantee to std::array<>.
Ganesh
--=20
--Apple-Mail=_5DFE6E3B-4248-4238-8CF1-5DAB47D68C5B
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=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space; "><br><div><div>Il giorno=
13/gen/2013, alle ore 19:44, Nicol Bolas <<a href=3D"mailto:jmckesson@g=
mail.com">jmckesson@gmail.com</a>> ha scritto:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite"><br><br>On Sunday, January 13=
, 2013 1:45:11 AM UTC-8, Nikolay Ivchenkov wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-=
left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex=
; position: static; z-index: auto; ">On Sunday, January 13, 2013 2:43:48 AM=
UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturd=
ay, January 12, 2013 10:31:22 AM UTC-8, Nikolay Ivchenkov wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><br>How exactly would you apply std::array her=
e?<br></blockquote><div><br>Hmm. I was going to post the obvious solution, =
with a 1:1 substitution:<br></div></blockquote><div><br>You may be sure tha=
t I already considered such a solution.<br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">Then I was going to explain how C++11's new standard-layo=
ut and layout-compatibility rules require the cast in `play_sound` to work.=
Then I went to find the section in the standard that says that `std::array=
<Type, N>` and `Type[N]` are layout-compatible.<br><br>The problem is=
.... there's no such section.<br></blockquote><div><br>Aha, the devil is in =
the details.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">That bein=
g said, I defy you to show me a compiler on which the above code won't run.=
...<br></blockquote><div><br>Why should I use such opaque hacks in order to =
solve a trivial problem? If we don't have a hammer, we could hammer in nail=
s with an electric iron, but I don't like such workarounds much.<br></div><=
/blockquote><div><br>It's not a hack or workaround. std::array is intended =
to be a replacement for C arrays. One that doesn't implicitly decay to poin=
ters, that can be copied/moved, and so forth.<br><br>The only problem prese=
ntly is that there is no language-level guarantee that std::array has the s=
ame size and layout as the equivalent C array. But this is a guarantee the =
language could provide, which is far less disruptive to the language than t=
rying to make C arrays behave like std::array. And it's also more useful, a=
s it would affect other things too.<br></div><div><br class=3D"webkit-block=
-placeholder"></div></blockquote><br></div><div>Let's consider that the sta=
ndard library does actually provide a similar guarantee for std::complex<=
;> (see 26.4/4). That could be take as a precedent for a proposal extend=
ing such guarantee to std::array<>.</div><br><div>Ganesh</div><div><b=
r></div></body></html>
<p></p>
-- <br />
<br />
<br />
<br />
--Apple-Mail=_5DFE6E3B-4248-4238-8CF1-5DAB47D68C5B--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 13 Jan 2013 14:34:23 -0800 (PST)
Raw View
------=_Part_273_22672974.1358116463172
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, January 13, 2013 1:45:05 PM UTC-8, Alberto Ganesh Barbati wrote:
>
>
> Il giorno 13/gen/2013, alle ore 19:44, Nicol Bolas <jmck...@gmail.com<javascript:>>
> ha scritto:
>
>
>
> On Sunday, January 13, 2013 1:45:11 AM UTC-8, Nikolay Ivchenkov wrote:
>>
>> On Sunday, January 13, 2013 2:43:48 AM UTC+4, Nicol Bolas wrote:
>>>
>>> On Saturday, January 12, 2013 10:31:22 AM UTC-8, Nikolay Ivchenkov wrote:
>>>>
>>>>
>>>> How exactly would you apply std::array here?
>>>>
>>>
>>> Hmm. I was going to post the obvious solution, with a 1:1 substitution:
>>>
>>
>> You may be sure that I already considered such a solution.
>>
>> Then I was going to explain how C++11's new standard-layout and
>>> layout-compatibility rules require the cast in `play_sound` to work. Then I
>>> went to find the section in the standard that says that `std::array<Type,
>>> N>` and `Type[N]` are layout-compatible.
>>>
>>> The problem is... there's no such section.
>>>
>>
>> Aha, the devil is in the details.
>>
>> That being said, I defy you to show me a compiler on which the above code
>>> won't run...
>>>
>>
>> Why should I use such opaque hacks in order to solve a trivial problem?
>> If we don't have a hammer, we could hammer in nails with an electric iron,
>> but I don't like such workarounds much.
>>
>
> It's not a hack or workaround. std::array is intended to be a replacement
> for C arrays. One that doesn't implicitly decay to pointers, that can be
> copied/moved, and so forth.
>
> The only problem presently is that there is no language-level guarantee
> that std::array has the same size and layout as the equivalent C array. But
> this is a guarantee the language could provide, which is far less
> disruptive to the language than trying to make C arrays behave like
> std::array. And it's also more useful, as it would affect other things too.
>
>
> Let's consider that the standard library does actually provide a similar
> guarantee for std::complex<> (see 26.4/4). That could be take as a
> precedent for a proposal extending such guarantee to std::array<>.
>
> Ganesh
>
The problem with using that as a basis is that it doesn't consider the
conversion of an *array* of such types. We can get a pointer to the
contents of `std::array` just by calling it's `data` member. The problem is
when we have an array of `std::array`s; we need to guarantee that
`sizeof(std::array<Type, N>) == sizeof(Type[N])` in addition to the layout
compatibility.
In order to ensure this, we need to force C++ compilers to require that *any
* struct that contains only an array be equivalent to just an array in
every way.
--
------=_Part_273_22672974.1358116463172
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, January 13, 2013 1:45:05 PM UTC-8, Alberto Ganesh Barbat=
i 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"><br><div><div>Il giorno 13/gen/2013, alle ore 19:44, Nicol Bo=
las <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
R1gruw3kUggJ">jmck...@gmail.com</a>> ha scritto:</div><br><blockquote ty=
pe=3D"cite"><br><br>On Sunday, January 13, 2013 1:45:11 AM UTC-8, Nikolay I=
vchenkov wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">On Sunday, January 13, 2013 2:43:48 AM UTC+=
4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday, J=
anuary 12, 2013 10:31:22 AM UTC-8, Nikolay Ivchenkov wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><br>How exactly would you apply std::array here?<br=
></blockquote><div><br>Hmm. I was going to post the obvious solution, with =
a 1:1 substitution:<br></div></blockquote><div><br>You may be sure that I a=
lready considered such a solution.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">Then I was going to explain how C++11's new standard-layout an=
d layout-compatibility rules require the cast in `play_sound` to work. Then=
I went to find the section in the standard that says that `std::array<T=
ype, N>` and `Type[N]` are layout-compatible.<br><br>The problem is... t=
here's no such section.<br></blockquote><div><br>Aha, the devil is in the d=
etails.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">That being sai=
d, I defy you to show me a compiler on which the above code won't run...<br=
></blockquote><div><br>Why should I use such opaque hacks in order to solve=
a trivial problem? If we don't have a hammer, we could hammer in nails wit=
h an electric iron, but I don't like such workarounds much.<br></div></bloc=
kquote><div><br>It's not a hack or workaround. std::array is intended to be=
a replacement for C arrays. One that doesn't implicitly decay to pointers,=
that can be copied/moved, and so forth.<br><br>The only problem presently =
is that there is no language-level guarantee that std::array has the same s=
ize and layout as the equivalent C array. But this is a guarantee the langu=
age could provide, which is far less disruptive to the language than trying=
to make C arrays behave like std::array. And it's also more useful, as it =
would affect other things too.<br></div><div><br></div></blockquote><br></d=
iv><div>Let's consider that the standard library does actually provide a si=
milar guarantee for std::complex<> (see 26.4/4). That could be take a=
s a precedent for a proposal extending such guarantee to std::array<>=
..</div><br><div>Ganesh</div></div></blockquote><div><br>The problem with us=
ing that as a basis is that it doesn't consider the conversion of an <i>arr=
ay</i> of such types. We can get a pointer to the contents of `std::array` =
just by calling it's `data` member. The problem is when we have an array of=
`std::array`s; we need to guarantee that `sizeof(std::array<Type, N>=
) =3D=3D sizeof(Type[N])` in addition to the layout compatibility.<br><br>I=
n order to ensure this, we need to force C++ compilers to require that <i>a=
ny</i> struct that contains only an array be equivalent to just an array in=
every way.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_273_22672974.1358116463172--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 13 Jan 2013 18:15:49 -0600
Raw View
On Sun, Jan 13, 2013 at 4:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> The problem is when we have an array of `std::array`s; we need to guarantee
> that `sizeof(std::array<Type, N>) == sizeof(Type[N])` in addition to the
> layout compatibility.
I caught your point. However, I found that the current STL has no
concept about the multi-dimension containers. At least, instead
of to have std::array of std::array, I prefer std::array<Type, N, M...>.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 13 Jan 2013 17:16:11 -0800 (PST)
Raw View
------=_Part_49_29745244.1358126171502
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, January 13, 2013 4:15:49 PM UTC-8, Zhihao Yuan wrote:
>
> On Sun, Jan 13, 2013 at 4:34 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > The problem is when we have an array of `std::array`s; we need to
> guarantee
> > that `sizeof(std::array<Type, N>) == sizeof(Type[N])` in addition to the
> > layout compatibility.
>
> I caught your point. However, I found that the current STL has no
> concept about the multi-dimension containers. At least, instead
> of to have std::array of std::array, I prefer std::array<Type, N, M...>.
>
And what if you want what this example has, a
`std::vector<std::array<double, 2>>`? You need special language to allow
that to be converted into a `double(*)[2]`.
--
------=_Part_49_29745244.1358126171502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, January 13, 2013 4:15:49 PM UTC-8, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Jan 13, 2013 at 4:34 PM, =
Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"5f2SpGtleYsJ">jmck...@gmail.com</a>> wrote:
<br>> The problem is when we have an array of `std::array`s; we need to =
guarantee
<br>> that `sizeof(std::array<Type, N>) =3D=3D sizeof(Type[N])` in=
addition to the
<br>> layout compatibility.
<br>
<br>I caught your point. However, I found that the current STL has no
<br>concept about the multi-dimension containers. At least, instead
<br>of to have std::array of std::array, I prefer std::array<Type, N, M.=
...>.
<br></blockquote><div><br>And what if you want what this example has, a `st=
d::vector<std::array<double, 2>>`? You need special language to=
allow that to be converted into a `double(*)[2]`.</div><br>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_49_29745244.1358126171502--
.
Author: Michael Price - Dev <michael.b.price.dev@gmail.com>
Date: Sun, 13 Jan 2013 18:10:43 -0800 (PST)
Raw View
------=_Part_440_26492352.1358129443800
Content-Type: text/plain; charset=ISO-8859-1
> I caught your point. However, I found that the current STL has no
> concept about the multi-dimension containers. At least, instead
> of to have std::array of std::array, I prefer std::array<Type, N, M...>.
>
>
I've got a proposal in the works to do just that, however there is a quirk
in aggregate initialization that caused a snag. I've got a paper that I'm
going to officially submit sometime in the next 24 hours that will rectify
that and will begin working on the text of the multidimensional array
proposal soon thereafter.
The paper that addresses the aforementioned quirk might be relevant to the
layout aspect of this conversation. I'll post a link to the paper once it
gets submitted.
--
------=_Part_440_26492352.1358129443800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">I caught your point.  =
;However, I found that the current STL has no
<br>concept about the multi-dimension containers. At least, instead
<br>of to have std::array of std::array, I prefer std::array<Type, N, M.=
...>.
<br><br></blockquote><div><br></div><div>I've got a proposal in the works t=
o do just that, however there is a quirk in aggregate initialization that c=
aused a snag. I've got a paper that I'm going to officially submit so=
metime in the next 24 hours that will rectify that and will begin working o=
n the text of the multidimensional array proposal soon thereafter.</div><di=
v><br></div><div>The paper that addresses the aforementioned quirk might be=
relevant to the layout aspect of this conversation. I'll post a link=
to the paper once it gets submitted.</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_440_26492352.1358129443800--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 13 Jan 2013 21:32:35 -0500
Raw View
On Sun, Jan 13, 2013 at 5:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> The problem with using that as a basis is that it doesn't consider the
> conversion of an array of such types. We can get a pointer to the contents
> of `std::array` just by calling it's `data` member. The problem is when we
> have an array of `std::array`s; we need to guarantee that
> `sizeof(std::array<Type, N>) == sizeof(Type[N])` in addition to the layout
> compatibility.
>
> In order to ensure this, we need to force C++ compilers to require that any
> struct that contains only an array be equivalent to just an array in every
> way.
>
So we can't have debug std::arrays with extra info in them?
I can't think of what that info would be, typically it is in the
iterator, not the container, but who knows?
Tony
--
.
Author: Fabio Fracassi <f.fracassi@gmx.net>
Date: Mon, 14 Jan 2013 08:52:49 +0100
Raw View
On 1/14/13 3:32 AM, Tony V E wrote:
> On Sun, Jan 13, 2013 at 5:34 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> The problem with using that as a basis is that it doesn't consider the
>> conversion of an array of such types. We can get a pointer to the contents
>> of `std::array` just by calling it's `data` member. The problem is when we
>> have an array of `std::array`s; we need to guarantee that
>> `sizeof(std::array<Type, N>) == sizeof(Type[N])` in addition to the layout
>> compatibility.
>>
>> In order to ensure this, we need to force C++ compilers to require that any
>> struct that contains only an array be equivalent to just an array in every
>> way.
>>
> So we can't have debug std::arrays with extra info in them?
> I can't think of what that info would be, typically it is in the
> iterator, not the container, but who knows?
>
> Tony
>
Generally it is a better idea to put the debug data
(or any other related-but-not-core-concern data IMO)
into a separate struct and have a map to match the two.
That way you can guarantee binary compatibility and have
debug data. (IIUC clangs libc++ uses such a technique)
best regards
Fabio
--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Mon, 14 Jan 2013 04:02:12 -0800 (PST)
Raw View
------=_Part_340_27903870.1358164932839
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 14, 2013 1:15:49 AM UTC+1, Zhihao Yuan wrote:
>
> On Sun, Jan 13, 2013 at 4:34 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > The problem is when we have an array of `std::array`s; we need to
> guarantee
> > that `sizeof(std::array<Type, N>) == sizeof(Type[N])` in addition to the
> > layout compatibility.
>
> I caught your point. However, I found that the current STL has no
> concept about the multi-dimension containers. At least, instead
> of to have std::array of std::array, I prefer std::array<Type, N, M...>.
>
I would prefer std::array<T[N][M]>. I also prefer std::array<T[N]> over
std::array<T, N> by the way, it just seems more natural to me. But then you
wouldn't be able to create a zero-sized array. Which makes an interesting
point btw, std::array<T, 0> could never be layout compatible.
- Sylvester
--
------=_Part_340_27903870.1358164932839
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 14, 2013 1:15:49 AM UTC+1, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Jan 13, 2013 at 4:34 PM, =
Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"5f2SpGtleYsJ">jmck...@gmail.com</a>> wrote:
<br>> The problem is when we have an array of `std::array`s; we need to =
guarantee
<br>> that `sizeof(std::array<Type, N>) =3D=3D sizeof(Type[N])` in=
addition to the
<br>> layout compatibility.
<br>
<br>I caught your point. However, I found that the current STL has no
<br>concept about the multi-dimension containers. At least, instead
<br>of to have std::array of std::array, I prefer std::array<Type, N, M.=
...>.
<br></blockquote><div><br></div><div>I would prefer std::array<T[N][M]&g=
t;. I also prefer std::array<T[N]> over std::array<T, N> by the=
way, it just seems more natural to me. But then you wouldn't be able to cr=
eate a zero-sized array. Which makes an interesting point btw, std::array&l=
t;T, 0> could never be layout compatible.</div><div><br></div><div>- Syl=
vester</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_340_27903870.1358164932839--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Mon, 14 Jan 2013 04:15:36 -0800 (PST)
Raw View
------=_Part_239_30646322.1358165736842
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 14, 2013 2:16:11 AM UTC+1, Nicol Bolas wrote:
>
>
> On Sunday, January 13, 2013 4:15:49 PM UTC-8, Zhihao Yuan wrote:
>>
>> I caught your point. However, I found that the current STL has no
>> concept about the multi-dimension containers. At least, instead
>> of to have std::array of std::array, I prefer std::array<Type, N, M...>.
>>
>
> And what if you want what this example has, a
> `std::vector<std::array<double, 2>>`? You need special language to allow
> that to be converted into a `double(*)[2]`.
>
>
Do we really need it to be implicitely convertible? A library function
would be acceptable as well in my opinion.
std::vector<std::array<double, 2>> v;
double (*ptr)[2] = to_c_array(v);
I don't really like the name "to_c_array" but I can't think of a better one
at this point.
- Sylvester
--
------=_Part_239_30646322.1358165736842
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, January 14, 2013 2:16:11 AM UTC+1, Nicol Bolas wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-=
width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid=
; padding-left: 1ex;"><br><br>On Sunday, January 13, 2013 4:15:49 PM UTC-8,=
Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204)=
; border-left-style: solid; padding-left: 1ex;">I caught your point. =
However, I found that the current STL has no <br>concept about the mul=
ti-dimension containers. At least, instead <br>of to have std::a=
rray of std::array, I prefer std::array<Type, N, M...>. <br></bl=
ockquote><div><br>And what if you want what this example has, a `std::vecto=
r<std::array<<wbr>double, 2>>`? You need special language to al=
low that to be converted into a `double(*)[2]`.</div><br></blockquote><div>=
<br></div><div> Do we really need it to be implicitely convertible? A =
library function would be acceptable as well in my opinion.</div><div><br><=
/div><div style=3D"background-color: rgb(250, 250, 250); border: 1px solid =
rgb(187, 187, 187); word-wrap: break-word;" class=3D"prettyprint"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">vector</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">array</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">double</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: #0=
66;" class=3D"styled-by-prettify">2</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">>></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>double</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(*</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">ptr</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">)[</span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">2</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"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> to_c_array</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div>=
</code></div><div><br></div><div>I don't really like the name "to_c_array" =
but I can't think of a better one at this point.<br><br></div><div><br></di=
v><div>- Sylvester</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_239_30646322.1358165736842--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Mon, 14 Jan 2013 13:27:52 +0100
Raw View
2013/1/14 Sylvester Hesp <s.hesp@oisyn.nl>:
> On Monday, January 14, 2013 2:16:11 AM UTC+1, Nicol Bolas wrote:
>>
>>
>>
>> On Sunday, January 13, 2013 4:15:49 PM UTC-8, Zhihao Yuan wrote:
>>>
>>> I caught your point. However, I found that the current STL has no
>>> concept about the multi-dimension containers. At least, instead
>>> of to have std::array of std::array, I prefer std::array<Type, N, M...>.
>>
>>
>> And what if you want what this example has, a
>> `std::vector<std::array<double, 2>>`? You need special language to allow
>> that to be converted into a `double(*)[2]`.
>>
>
> Do we really need it to be implicitely convertible? A library function
> would be acceptable as well in my opinion.
>
> std::vector<std::array<double, 2>> v;
> double (*ptr)[2] = to_c_array(v);
>
> I don't really like the name "to_c_array" but I can't think of a better one
> at this point.
That was essentially
http://cplusplus.github.com/LWG/lwg-closed.html#930
Unfortunately this was declared NAD. But if someone would bring
forward a proposal paper with a bit more arguments for this usecase
there are quite good changes that it would be reconsidered.
- Daniel
--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Mon, 14 Jan 2013 05:07:33 -0800 (PST)
Raw View
------=_Part_560_24403273.1358168854047
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, January 13, 2013 10:44:08 PM UTC+4, Nicol Bolas wrote:
>
>
> It's not a hack or workaround.
>
reinterpret_cast with undocumented behavior is a hack & workaround.
> std::array is intended to be a replacement for C arrays.
>
I don't think so. But as far as I know, C++ is intended to provide good
interoperability with code written on C.
> One that doesn't implicitly decay to pointers, that can be copied/moved,
> and so forth.
>
Let me continue:
- it has verbose notation: std::array<T, N> instead of T[N] and
std::array<std::array<T, N2>, N1> instead of T[N1][N2];
- it increases compilation time (existing compilers have to parse the
content of the header <array>);
- its size cannot be deduced from a braced-init-list nor from a string
literal:
int a1[] = { 1, 2, 3 }; // OK
char s1[] = "text"; // OK
auto &r = "text"; // OK, r refers to a built-in array
std::array<int, ?> a2 = { 1, 2, 3 };
std::array<char const, ?> s2 = {"text"};
std::array<char const, 5> s = r; // doesn't work
- a type std::array<const NonConstType, N> is not reference-compatible with
std::array<NonConstType, N> and const std::array<NonConstType, N> is not
reference-compatible with std::array<const NonConstType, N>:
void f(int const (&)[2]);
void f(std::array<int, 2> const &);
int main()
{
using T = int;
using CT = T const;
constexpr int N = 2;
using A = T[N];
using AC = CT[N];
using CA = A const;
A a1 = { 1, 2 };
AC a2 = { 1, 2 };
CA const a3 = { 1, 2 };
f(a1); // OK
f(a2); // OK
f(a3); // OK
using B = std::array<T, N>;
using BC = std::array<CT, N>;
using CB = B const;
B b1 = { 1, 2 };
BC b2 = { 1, 2 };
CB const b3 = { 1, 2 };
f(b1); // OK
f(b2); // error <----
f(b3); // OK
}
- finally, we have the interoperability issue desribed above.
Excuse me for my scepticism, but I don't consider std::array as a
full-fledged replacement for built-in arrays. std::array is far from ideal.
--
------=_Part_560_24403273.1358168854047
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, January 13, 2013 10:44:08 PM UTC+4, Nicol Bolas wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><br><div>It's not a hack or workaround.<=
/div></blockquote><div><br>reinterpret_cast with undocumented behavior is a=
hack & workaround.<br> </div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div> std::array is intended to be a replacement for C arrays.</di=
v></blockquote><div><br>I don't think so. But as far as I know, C++ is inte=
nded to provide good interoperability with code written on C.<br> </di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div> One that doesn't impli=
citly decay to pointers, that can be copied/moved, and so forth.<br></div><=
/blockquote><div><br>Let me continue:<br>- it has verbose notation: std::ar=
ray<T, N> instead of T[N] and std::array<std::array<T, N2>, =
N1> instead of T[N1][N2];<br>- it increases compilation time (existing c=
ompilers have to parse the content of the header <array>);<br>- its s=
ize cannot be deduced from a braced-init-list nor from a string literal:<br=
><br> int a1[] =3D { 1, 2, 3 }; // OK<br> &nbs=
p; char s1[] =3D "text"; // OK<br> auto &r =3D "text"=
; // OK, r refers to a built-in array<br><br> std::array&=
lt;int, ?> a2 =3D { 1, 2, 3 };<br> std::array<char =
const, ?> s2 =3D {"text"};<br> std::array<char cons=
t, 5> s =3D r; // doesn't work<br><br>- a type std::array<const NonCo=
nstType, N> is not reference-compatible with std::array<NonConstType,=
N> and const std::array<NonConstType, N> is not reference-compati=
ble with std::array<const NonConstType, N>:<br><br> =
void f(int const (&)[2]);<br> void f(std::array<i=
nt, 2> const &);<br><br> int main()<br>  =
; {<br> using T =3D int;<br=
> using CT =3D T const;<br> =
constexpr int N =3D 2;<br><br> &n=
bsp; using A =3D T[N];<br> &=
nbsp; using AC =3D CT[N];<br> &nbs=
p; using CA =3D A const;<br><br> &=
nbsp; A a1 =3D { 1, 2 };<br>  =
; AC a2 =3D { 1, 2 };<br> CA cons=
t a3 =3D { 1, 2 };<br><br> f(a1);=
// OK<br> f(a2); // OK<br> =
f(a3); // OK<br><br> =
using B =3D std::array<T, N>;<br>  =
; using BC =3D std::array<CT, N>;<br>&n=
bsp; using CB =3D B const;<br><br> =
; B b1 =3D { 1, 2 };<br> &nb=
sp; BC b2 =3D { 1, 2 };<br> =
CB const b3 =3D { 1, 2 };<br><br>  =
; f(b1); // OK<br> &nb=
sp; f(b2); // error <----<br> =
f(b3); // OK<br> }<br><br>- finally, we have the interope=
rability issue desribed above.<br><br>Excuse me for my scepticism, but I do=
n't consider std::array as a full-fledged replacement for built-in arrays. =
std::array is far from ideal.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_560_24403273.1358168854047--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 14 Jan 2013 11:29:37 -0800 (PST)
Raw View
------=_Part_408_16580800.1358191777986
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 14, 2013 4:15:36 AM UTC-8, Sylvester Hesp wrote:
>
> On Monday, January 14, 2013 2:16:11 AM UTC+1, Nicol Bolas wrote:
>
>>
>>
>> On Sunday, January 13, 2013 4:15:49 PM UTC-8, Zhihao Yuan wrote:
>>>
>>> I caught your point. However, I found that the current STL has no
>>> concept about the multi-dimension containers. At least, instead
>>> of to have std::array of std::array, I prefer std::array<Type, N, M...>.
>>>
>>
>> And what if you want what this example has, a
>> `std::vector<std::array<double, 2>>`? You need special language to allow
>> that to be converted into a `double(*)[2]`.
>>
>>
> Do we really need it to be implicitely convertible? A library function
> would be acceptable as well in my opinion.
>
> std::vector<std::array<double, 2>> v;
> double (*ptr)[2] = to_c_array(v);
>
> I don't really like the name "to_c_array" but I can't think of a better
> one at this point.
>
I didn't say anything about *implicitly* convertible. My point is that
performing the apporpriate reinterpret_cast is *not* guaranteed to result
in valid code. So there's no conforming way to write `to_c_array` without
allocating a C array and copying the data. Even though virtually every
compiler actually does implement this.
--
------=_Part_408_16580800.1358191777986
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 14, 2013 4:15:36 AM UTC-8, Sylvester Hesp wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On Monday, January 14, 2013 2:=
16:11 AM UTC+1, Nicol Bolas wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><br><br>On Sunday, J=
anuary 13, 2013 4:15:49 PM UTC-8, Zhihao Yuan wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I caug=
ht your point. However, I found that the current STL has no <br>=
concept about the multi-dimension containers. At least, instead =
<br>of to have std::array of std::array, I prefer std::array<Type, N, M.=
...>. <br></blockquote><div><br>And what if you want what this examp=
le has, a `std::vector<std::array<<wbr>double, 2>>`? You need s=
pecial language to allow that to be converted into a `double(*)[2]`.</div><=
br></blockquote><div><br></div><div> Do we really need it to be implic=
itely convertible? A library function would be acceptable as well in my opi=
nion.</div><div><br></div><div style=3D"background-color:rgb(250,250,250);b=
order:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span sty=
le=3D"color:#000">std</span><span style=3D"color:#660">::</span><span style=
=3D"color:#000">vector</span><span style=3D"color:#660"><</span><span st=
yle=3D"color:#000">std</span><span style=3D"color:#660">::</span><span styl=
e=3D"color:#000">array</span><span style=3D"color:#660"><</span><span st=
yle=3D"color:#008">double</span><span style=3D"color:#660">,</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#066">2</span><span style=
=3D"color:#660">>></span><span style=3D"color:#000"> v</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#008">double</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">(*</span><span style=3D"color:#000">ptr</span><span style=
=3D"color:#660">)[</span><span style=3D"color:#066">2</span><span style=3D"=
color:#660">]</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">=3D</span><span style=3D"color:#000"> to_c_array</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">v</span><span style=3D"c=
olor:#660">);</span><span style=3D"color:#000"><br></span></div></code></di=
v><div><br></div><div>I don't really like the name "to_c_array" but I can't=
think of a better one at this point.</div></blockquote><div><br>I didn't s=
ay anything about <i>implicitly</i> convertible. My point is that performin=
g the apporpriate reinterpret_cast is <i>not</i> guaranteed to result in va=
lid code. So there's no conforming way to write `to_c_array` without alloca=
ting a C array and copying the data. Even though virtually every compiler a=
ctually does implement this.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_408_16580800.1358191777986--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 14 Jan 2013 12:06:30 -0800 (PST)
Raw View
------=_Part_857_17705178.1358193990538
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 14, 2013 5:07:33 AM UTC-8, Nikolay Ivchenkov wrote:
>
> On Sunday, January 13, 2013 10:44:08 PM UTC+4, Nicol Bolas wrote:
>>
>>
>> It's not a hack or workaround.
>>
>
> reinterpret_cast with undocumented behavior is a hack & workaround.
>
Yes. We're talking about exactly that issue and how to go about fixing it.
std::array is intended to be a replacement for C arrays.
>>
>
> I don't think so. But as far as I know, C++ is intended to provide good
> interoperability with code written on C.
>
>
>> One that doesn't implicitly decay to pointers, that can be copied/moved,
>> and so forth.
>>
>
> Let me continue:
> - it has verbose notation: std::array<T, N> instead of T[N] and
> std::array<std::array<T, N2>, N1> instead of T[N1][N2];
>
- it increases compilation time (existing compilers have to parse the
> content of the header <array>);
>
I'm sorry, but those are just not substantive differences. Yes, the syntax
is bigger, and compiling nothing takes longer than compiling something. But
considering the general implementations of <array>, I seriously doubt it
will even show up as a blip next to most standard library headers.
Also, some would argue that while the syntax may be more verbose, it is
also a lot *clearer* to the reader exactly what's going on. And reader
clarity is a good thing. For example, many C++ programmers that haven't
spent much time with arrays wouldn't be able to tell the difference between
`Type (*)[2]` and `Type *[2]` without help. While `std::array<Type, 2>*`
vs. `std::array<Type*, 2>` makes it all clear.
> - a type std::array<const NonConstType, N> is not reference-compatible
> with std::array<NonConstType, N> and const std::array<NonConstType, N> is
> not reference-compatible with std::array<const NonConstType, N>:
>
Well, that first conversion (from a const type to a non-const type)
shouldn't be allowed, due to breaking const-correctness. And the second one
is somewhat dubious to begin with, since a `const array<>` only provides
`const` access to its contents.
In short, there's no reason to ever use `array<const T, N>` over `const
array<T, N>` when you want a constant array. There might be some template
cases where you use a `const T` because someone passed you a `const T` as a
template type. Then again, one should probably be using
`std::remove_cv<T>::type` or even `std::decay<T>::type` in those cases
anyway, to make sure that cv-qualifications don't become a problem.
That being said, the standard does protect such explicit conversions
(assuming you go through all of the `const_casts` and such), since they are
layout-compatible. So perhaps they could add functions to do the (perfectly
safe) conversion for you. But it wouldn't be automatic.
- finally, we have the interoperability issue desribed above.
>
> Excuse me for my scepticism, but I don't consider std::array as a
> full-fledged replacement for built-in arrays. std::array is far from ideal.
>
Nobody ever said that it was "ideal". There is a difference between "X is
intended to do Y" and "X *perfectly* does Y in all cases." If you try to do
something but fail, that doesn't mean you didn't try to do it at all.
std::array should replace most uses of C-style arrays that std::vector
could not cover. If there are deficiencies in that, where there is a
legitimate need to use a C-style array, then let's *fix those*.
--
------=_Part_857_17705178.1358193990538
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 14, 2013 5:07:33 AM UTC-8, Nikolay Ivchenkov wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Sunday, January 13, 2013=
10:44:08 PM UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><br><div>It's not a hack or workaround.</div></blockquote><div><br>reint=
erpret_cast with undocumented behavior is a hack & workaround.<br></div=
></blockquote><div><br>Yes. We're talking about exactly that issue and how =
to go about fixing it.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div> std::array is intended =
to be a replacement for C arrays.</div></blockquote><div><br>I don't think =
so. But as far as I know, C++ is intended to provide good interoperability =
with code written on C.<br> </div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div> One that doesn't implicitly decay to pointers, that can be copied=
/moved, and so forth.<br></div></blockquote><div><br>Let me continue:<br>- =
it has verbose notation: std::array<T, N> instead of T[N] and std::ar=
ray<std::array<T, N2>, N1> instead of T[N1][N2]; </div></b=
lockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>- it increases =
compilation time (existing compilers have to parse the content of the heade=
r <array>);<br></div></blockquote><div><br>I'm sorry, but those are j=
ust not substantive differences. Yes, the syntax is bigger, and compiling n=
othing takes longer than compiling something. But considering the general i=
mplementations of <array>, I seriously doubt it will even show up as =
a blip next to most standard library headers.<br><br>Also, some would argue=
that while the syntax may be more verbose, it is also a lot <i>clearer</i>=
to the reader exactly what's going on. And reader clarity is a good thing.=
For example, many C++ programmers that haven't spent much time with arrays=
wouldn't be able to tell the difference between `Type (*)[2]` and `Type *[=
2]` without help. While `std::array<Type, 2>*` vs. `std::array<Typ=
e*, 2>` makes it all clear.<br> </div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div>- a type std::array<const NonConstType, N> is no=
t reference-compatible with std::array<NonConstType, N> and const std=
::array<NonConstType, N> is not reference-compatible with std::array&=
lt;const NonConstType, N>:<br></div></blockquote><div><br>Well, that fir=
st conversion (from a const type to a non-const type) shouldn't be allowed,=
due to breaking const-correctness. And the second one is somewhat dubious =
to begin with, since a `const array<>` only provides `const` access t=
o its contents.<br><br>In short, there's no reason to ever use `array<co=
nst T, N>` over `const array<T, N>` when you want a constant array=
.. There might be some template cases where you use a `const T` because some=
one passed you a `const T` as a template type. Then again, one should proba=
bly be using `std::remove_cv<T>::type` or even `std::decay<T>::=
type` in those cases anyway, to make sure that cv-qualifications don't beco=
me a problem.<br><br>That being said, the standard does protect such explic=
it conversions (assuming you go through all of the `const_casts` and such),=
since they are layout-compatible. So perhaps they could add functions to d=
o the (perfectly safe) conversion for you. But it wouldn't be automatic.<br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>- finally, we =
have the interoperability issue desribed above.<br><br>Excuse me for my sce=
pticism, but I don't consider std::array as a full-fledged replacement for =
built-in arrays. std::array is far from ideal.<br></div></blockquote><div><=
br>Nobody ever said that it was "ideal". There is a difference between "X i=
s intended to do Y" and "X <i>perfectly</i> does Y in all cases." If you tr=
y to do something but fail, that doesn't mean you didn't try to do it at al=
l.<br><br>std::array should replace most uses of C-style arrays that std::v=
ector could not cover. If there are deficiencies in that, where there is a =
legitimate need to use a C-style array, then let's <i>fix those</i>.<br></d=
iv>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_857_17705178.1358193990538--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Mon, 14 Jan 2013 23:39:48 +0100
Raw View
--Apple-Mail-E0ED0DEE-F48F-4BBA-9CED-6B7416BDD96B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Il giorno 13/gen/2013, alle ore 23:34, Nicol Bolas <jmckesson@gmail.com> ha=
scritto:
>=20
>=20
> On Sunday, January 13, 2013 1:45:05 PM UTC-8, Alberto Ganesh Barbati wrot=
e:
>>=20
>>=20
>> Il giorno 13/gen/2013, alle ore 19:44, Nicol Bolas <jmck...@gmail.com> h=
a scritto:
>>>=20
>>> It's not a hack or workaround. std::array is intended to be a replaceme=
nt for C arrays. One that doesn't implicitly decay to pointers, that can be=
copied/moved, and so forth.
>>>=20
>>> The only problem presently is that there is no language-level guarantee=
that std::array has the same size and layout as the equivalent C array. Bu=
t this is a guarantee the language could provide, which is far less disrupt=
ive to the language than trying to make C arrays behave like std::array. An=
d it's also more useful, as it would affect other things too.
>>=20
>> Let's consider that the standard library does actually provide a similar=
guarantee for std::complex<> (see 26.4/4). That could be take as a precede=
nt for a proposal extending such guarantee to std::array<>.
>>=20
>> Ganesh
>=20
> The problem with using that as a basis is that it doesn't consider the co=
nversion of an array of such types. We can get a pointer to the contents of=
`std::array` just by calling it's `data` member. The problem is when we ha=
ve an array of `std::array`s; we need to guarantee that `sizeof(std::array<=
Type, N>) =3D=3D sizeof(Type[N])` in addition to the layout compatibility.
Although the wording is not plain, the guarantees listed in 26.4/4 for std:=
:complex also take care of that. Please read more carefully the part after =
"Moreover, if a is an expression of type cv std::complex<T>*..."
Ganesh
--=20
--Apple-Mail-E0ED0DEE-F48F-4BBA-9CED-6B7416BDD96B
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div><br><br>Il giorno 13/gen/2013, all=
e ore 23:34, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com">jmckess=
on@gmail.com</a>> ha scritto:<br><br></div><blockquote type=3D"cite"><br=
><br>On Sunday, January 13, 2013 1:45:05 PM UTC-8, Alberto Ganesh Barbati w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:b=
reak-word"><br><div><div>Il giorno 13/gen/2013, alle ore 19:44, Nicol Bolas=
<<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"R1g=
ruw3kUggJ">jmck...@gmail.com</a>> ha scritto:</div><blockquote type=3D"c=
ite"><div><br>It's not a hack or workaround. std::array is intended to be a=
replacement for C arrays. One that doesn't implicitly decay to pointers, t=
hat can be copied/moved, and so forth.<br><br>The only problem presently is=
that there is no language-level guarantee that std::array has the same siz=
e and layout as the equivalent C array. But this is a guarantee the languag=
e could provide, which is far less disruptive to the language than trying t=
o make C arrays behave like std::array. And it's also more useful, as it wo=
uld affect other things too.<br></div><div><br></div></blockquote><br></div=
><div>Let's consider that the standard library does actually provide a simi=
lar guarantee for std::complex<> (see 26.4/4). That could be take as =
a precedent for a proposal extending such guarantee to std::array<>.<=
/div><br><div>Ganesh</div></div></blockquote><div><br>The problem with usin=
g that as a basis is that it doesn't consider the conversion of an <i>array=
</i> of such types. We can get a pointer to the contents of `std::array` ju=
st by calling it's `data` member. The problem is when we have an array of `=
std::array`s; we need to guarantee that `sizeof(std::array<Type, N>) =
=3D=3D sizeof(Type[N])` in addition to the layout compatibility.<br></div><=
/blockquote><div><br></div><div>Although the wording is not plain, the guar=
antees listed in 26.4/4 for std::complex also take care of that. Please rea=
d more carefully the part after "Moreover, if a is an expression of type cv=
std::complex<T>*..."</div><div><br></div><div>Ganesh</div><div><br><=
/div></body></html>
<p></p>
-- <br />
<br />
<br />
<br />
--Apple-Mail-E0ED0DEE-F48F-4BBA-9CED-6B7416BDD96B--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Mon, 14 Jan 2013 15:42:42 -0800 (PST)
Raw View
------=_Part_1298_9876004.1358206962828
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 14, 2013 8:29:37 PM UTC+1, Nicol Bolas wrote:
>
> I didn't say anything about *implicitly* convertible. My point is that
> performing the apporpriate reinterpret_cast is *not* guaranteed to result
> in valid code.
I was under the impression that we were already covering the topic of
layout compatibility between array types and std::array, so there's no need
to visit that yet again. I thought you were talking about that we need a
language feature to be able to do implicit conversions, which also happens
to be true.
--
------=_Part_1298_9876004.1358206962828
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 14, 2013 8:29:37 PM UTC+1, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">I didn't say anything about <i>im=
plicitly</i> convertible. My point is that performing the apporpriate reint=
erpret_cast is <i>not</i> guaranteed to result in valid code.</blockquote><=
div><br></div><div>I was under the impression that we were already covering=
the topic of layout compatibility between array types and std::array, so t=
here's no need to visit that yet again. I thought you were talking about th=
at we need a language feature to be able to do implicit conversions, which =
also happens to be true<font face=3D"arial, sans-serif">.</font></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_1298_9876004.1358206962828--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Tue, 15 Jan 2013 01:34:30 -0800 (PST)
Raw View
------=_Part_62_7077956.1358242470815
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, January 15, 2013 12:06:30 AM UTC+4, Nicol Bolas wrote:
>
>
> On Monday, January 14, 2013 5:07:33 AM UTC-8, Nikolay Ivchenkov wrote:
>>
>> On Sunday, January 13, 2013 10:44:08 PM UTC+4, Nicol Bolas wrote:
>>>
>>>
>>> It's not a hack or workaround.
>>>
>>
>> reinterpret_cast with undocumented behavior is a hack & workaround.
>>
>
> Yes. We're talking about exactly that issue and how to go about fixing it.
>
The best thing we can do with it is to provide something like this
namespace std
{
template <class T, size_t N>
auto underlying_array(array<T, N> &x) -> T (&)[N]
{ return reinterpret_cast<T (&)[N]>(x); }
template <class T, size_t N>
auto underlying_array(array<T, N> *x) -> T (*)[N]
{ return reinterpret_cast<T (*)[N]>(x); }
}
and guarantee that sizeof(std::array<T, N>) ==
sizeof(std::underlying_array(std::array<T, N>)) holds for every N > 0.
However,
play_stereo_sound(pulse_seq.data(), pulse_seq.size());
would still be more simple than
play_stereo_sound(std::underlying_array(pulse_seq.data()),
pulse_seq.size());
> std::array is intended to be a replacement for C arrays.
>>>
>>
>> I don't think so. But as far as I know, C++ is intended to provide good
>> interoperability with code written on C.
>>
>>
>>> One that doesn't implicitly decay to pointers, that can be copied/moved,
>>> and so forth.
>>>
>>
>> Let me continue:
>> - it has verbose notation: std::array<T, N> instead of T[N] and
>> std::array<std::array<T, N2>, N1> instead of T[N1][N2];
>>
> - it increases compilation time (existing compilers have to parse the
>> content of the header <array>);
>>
>
> I'm sorry, but those are just not substantive differences.
>
for _you_
> Also, some would argue that while the syntax may be more verbose, it is
> also a lot *clearer* to the reader exactly what's going on. And reader
> clarity is a good thing. For example, many C++ programmers that haven't
> spent much time with arrays wouldn't be able to tell the difference between
> `Type (*)[2]` and `Type *[2]` without help. While `std::array<Type, 2>*`
> vs. `std::array<Type*, 2>` makes it all clear.
>
We still have built-in arrays, so novices actually have to learn two things
instead of one: how built-in arrays work and how std::array works (and then
think about which one should be preferred in a particular case).
> - a type std::array<const NonConstType, N> is not reference-compatible
>> with std::array<NonConstType, N> and const std::array<NonConstType, N> is
>> not reference-compatible with std::array<const NonConstType, N>:
>>
>
> Well, that first conversion (from a const type to a non-const type)
> shouldn't be allowed, due to breaking const-correctness.
>
I don't see how that is related to my words. The former statement implies
that
std::array<NonConstType, N> a;
std::array<const NonConstType, N> &r = a;
is ill-formed.
> In short, there's no reason to ever use `array<const T, N>` over `const
> array<T, N>` when you want a constant array. There might be some template
> cases where you use a `const T` because someone passed you a `const T` as a
> template type.
>
Alternatively, const element type can be specified by a typedef declaration.
> Then again, one should probably be using `std::remove_cv<T>::type` or even
> `std::decay<T>::type` in those cases anyway, to make sure that
> cv-qualifications don't become a problem.
>
I don't need such complications when I use built-in arrays. So, -1 on
std::array.
Nobody ever said that it was "ideal". There is a difference between "X is
> intended to do Y"
All workarounds are intented to do something, so what? I still don't see
any reason why C++ programmers should use std::array instead of
full-fledged built-in arrays.
> std::array should replace most uses of C-style arrays that std::vector
> could not cover. If there are deficiencies in that, where there is a
> legitimate need to use a C-style array, then let's *fix those*.
>
Core language can be improved so that I would not need std::array at all.
--
------=_Part_62_7077956.1358242470815
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, January 15, 2013 12:06:30 AM UTC+4, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><br>On Monday, January 14, 2013 5:07:33=
AM UTC-8, Nikolay Ivchenkov wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On Sunday, January 13, 2013 10:44:08 PM UTC+4, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div>It's not a hack or workaround.</div=
></blockquote><div><br>reinterpret_cast with undocumented behavior is a hac=
k & workaround.<br></div></blockquote><div><br>Yes. We're talking about=
exactly that issue and how to go about fixing it.<br></div></blockquote><d=
iv><br>The best thing we can do with it is to provide something like this<b=
r><br> namespace std<br> {<br> &nb=
sp; template <class T, size_t N><br>&nb=
sp; auto underl=
ying_array(array<T, N> &x) -> T (&)[N]<br> &nbs=
p; =
{ return reinterpret_cast<T (&)[N]>(x); }<br><br> &nb=
sp; template <class T, size_t N><br> &=
nbsp; auto underlying_array(array<T, N> *x)=
-> T (*)[N]<br> =
{ return reinterpret_cast<T (*)[N]>(x); }<br>&nbs=
p; }<br><br>and guarantee that sizeof(std::array<T, N>) =
=3D=3D sizeof(std::underlying_array(std::array<T, N>)) holds for ever=
y N > 0. However,<br><br> play_stereo_sound(pulse_seq.=
data(), pulse_seq.size());<br><br>would still be more simple than<br><br>&n=
bsp; play_stereo_sound(std::underlying_array(pulse_seq.data()),=
pulse_seq.size());<br> </div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div> std::array is intended to be a replacement for C arrays.</=
div></blockquote><div><br>I don't think so. But as far as I know, C++ is in=
tended to provide good interoperability with code written on C.<br> </=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div> One that doesn't implicit=
ly decay to pointers, that can be copied/moved, and so forth.<br></div></bl=
ockquote><div><br>Let me continue:<br>- it has verbose notation: std::array=
<T, N> instead of T[N] and std::array<std::array<T, N2>, N1&=
gt; instead of T[N1][N2]; </div></blockquote><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div>- it increases compilation time (existing compilers hav=
e to parse the content of the header <array>);<br></div></blockquote>=
<div><br>I'm sorry, but those are just not substantive differences.</div></=
blockquote><div><br>for _you_<br> </div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div> Also, some would argue that while the syntax may be mo=
re verbose, it is also a lot <i>clearer</i> to the reader exactly what's go=
ing on. And reader clarity is a good thing. For example, many C++ programme=
rs that haven't spent much time with arrays wouldn't be able to tell the di=
fference between `Type (*)[2]` and `Type *[2]` without help. While `std::ar=
ray<Type, 2>*` vs. `std::array<Type*, 2>` makes it all clear.<b=
r></div></blockquote><div><br>We still have built-in arrays, so novices act=
ually have to learn two things instead of one: how built-in arrays work and=
how std::array works (and then think about which one should be preferred i=
n a particular case).<br> </div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>- a type std=
::array<const NonConstType, N> is not reference-compatible with std::=
array<NonConstType, N> and const std::array<NonConstType, N> is=
not reference-compatible with std::array<const NonConstType, N>:<br>=
</div></blockquote><div><br>Well, that first conversion (from a const type =
to a non-const type) shouldn't be allowed, due to breaking const-correctnes=
s.</div></blockquote><div><br>I don't see how that is related to my words. =
The former statement implies that<br><br> std::array<N=
onConstType, N> a;<br> std::array<const NonConstTyp=
e, N> &r =3D a;<br><br>is ill-formed.<br> </div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div>In short, there's no reason to ever use =
`array<const T, N>` over `const array<T, N>` when you want a co=
nstant array. There might be some template cases where you use a `const T` =
because someone passed you a `const T` as a template type.</div></blockquot=
e><div><br>Alternatively, const element type can be specified by a typedef =
declaration.<br> </div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv> Then again, one should probably be using `std::remove_cv<T>::type=
` or even `std::decay<T>::type` in those cases anyway, to make sure t=
hat cv-qualifications don't become a problem.<br></div></blockquote><div><b=
r>I don't need such complications when I use built-in arrays. So, -1 on std=
::array.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Nobody e=
ver said that it was "ideal". There is a difference between "X is intended =
to do Y"</blockquote><div><br>All workarounds are intented to do something,=
so what? I still don't see any reason why C++ programmers should use std::=
array instead of full-fledged built-in arrays.<br> </div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div>std::array should replace most uses of=
C-style arrays that std::vector could not cover. If there are deficiencies=
in that, where there is a legitimate need to use a C-style array, then let=
's <i>fix those</i>.<br></div></blockquote><div><br>Core language can be im=
proved so that I would not need std::array at all.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_62_7077956.1358242470815--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 15 Jan 2013 03:52:26 -0800 (PST)
Raw View
------=_Part_297_10177091.1358250746080
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, January 15, 2013 1:34:30 AM UTC-8, Nikolay Ivchenkov wrote:
>
> On Tuesday, January 15, 2013 12:06:30 AM UTC+4, Nicol Bolas wrote:
>>
>>
>> On Monday, January 14, 2013 5:07:33 AM UTC-8, Nikolay Ivchenkov wrote:
>>>
>>> On Sunday, January 13, 2013 10:44:08 PM UTC+4, Nicol Bolas wrote:
>>>>
>>>> One that doesn't implicitly decay to pointers, that can be
>>>> copied/moved, and so forth.
>>>>
>>>
>>> Let me continue:
>>> - it has verbose notation: std::array<T, N> instead of T[N] and
>>> std::array<std::array<T, N2>, N1> instead of T[N1][N2];
>>>
>> - it increases compilation time (existing compilers have to parse the
>>> content of the header <array>);
>>>
>>
>> I'm sorry, but those are just not substantive differences.
>>
>
> for _you_
>
One could say the same for your list.
>
>
>> Also, some would argue that while the syntax may be more verbose, it is
>> also a lot *clearer* to the reader exactly what's going on. And reader
>> clarity is a good thing. For example, many C++ programmers that haven't
>> spent much time with arrays wouldn't be able to tell the difference between
>> `Type (*)[2]` and `Type *[2]` without help. While `std::array<Type, 2>*`
>> vs. `std::array<Type*, 2>` makes it all clear.
>>
>
> We still have built-in arrays, so novices actually have to learn two
> things instead of one: how built-in arrays work and how std::array works
> (and then think about which one should be preferred in a particular case).
>
Do they? How many novices can actually tell you the difference between
`Type *[2]` and `Type (*)[2]`? Compare this to the number that could tell
you the difference between `std::array<Type, 2>*` and `std::array<Type*,
2>`.
As for which should be preferred, again, that's obvious: std::array. It has
value semantics like any other object, not a bunch of funky rules like
"decays to pointer" and some such.
Remember: many intro C++ texts already tell users to use std::vector *
instead* of arrays even today. std::array is only going to be another
alternative that they are told to use instead of arrays. Coupled with
vector and array being able to participate in aggregate/initializer_list
initialization, and 99% of most user's reasons to ever use a C-style array
go away.
The number of C++ programmers who understand the deep issues and complex
syntax of C-style arrays is shrinking, not growing. The knowledge is out
there certainly, but there are many who don't pursue it. They just don't
need to.
- a type std::array<const NonConstType, N> is not reference-compatible with
>>> std::array<NonConstType, N> and const std::array<NonConstType, N> is not
>>> reference-compatible with std::array<const NonConstType, N>:
>>>
>>
>> Well, that first conversion (from a const type to a non-const type)
>> shouldn't be allowed, due to breaking const-correctness.
>>
>
> I don't see how that is related to my words. The former statement implies
> that
>
> std::array<NonConstType, N> a;
> std::array<const NonConstType, N> &r = a;
>
> is ill-formed.
>
>
>> In short, there's no reason to ever use `array<const T, N>` over `const
>> array<T, N>` when you want a constant array. There might be some template
>> cases where you use a `const T` because someone passed you a `const T` as a
>> template type.
>>
>
> Alternatively, const element type can be specified by a typedef
> declaration.
>
>
>> Then again, one should probably be using `std::remove_cv<T>::type` or
>> even `std::decay<T>::type` in those cases anyway, to make sure that
>> cv-qualifications don't become a problem.
>>
>
> I don't need such complications when I use built-in arrays. So, -1 on
> std::array.
>
And I could easily say that I need value semantics far more than I need to
use arrays in template scenarios or with random typedefs. So why suffer the
C-style array grief and odd-ball behavior when I can just use what works?
> Nobody ever said that it was "ideal". There is a difference between "X is
>> intended to do Y"
>
>
> All workarounds are intented to do something, so what? I still don't see
> any reason why C++ programmers should use std::array instead of
> full-fledged built-in arrays.
>
Then you're not paying attention to the *very reason* this thread exists:
to give C-style arrays similar abilities as std::array.
std::array should replace most uses of C-style arrays that std::vector
>> could not cover. If there are deficiencies in that, where there is a
>> legitimate need to use a C-style array, then let's *fix those*.
>>
>
> Core language can be improved so that I would not need std::array at all.
>
Really? Can you give arrays value semantics like regular types? Because I'm
pretty sure that would break all kinds of backwards compatibility. As would
changing how they work as function arguments. Can you give them sizing
member functions? What about not decaying to pointers without an explicit
conversion? I can keep going.
I seriously doubt C-style arrays can be given these properties without
breaking compatibility. You may not want or even like those properties. But
std::array exists because boost::array was a very successful, well-liked
class that many people adopted. Other people like and want these properties.
And to be honest, all it would take for me to *never* use C-style arrays
again (outside of *maybe* for global tables of stuff and possibly not even
that) is for the standard to provide the same layout guarantee that
std::complex has. If I know that an array of std::array will work correctly
in all circumstances, there will never be an interoperability problem that
can't be worked around.
--
------=_Part_297_10177091.1358250746080
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, January 15, 2013 1:34:30 AM UTC-8, Nikolay Ivchenkov wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday, January 15, 20=
13 12:06:30 AM UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><br>On Monday, January 14, 2013 5:07:33 AM UTC-8, Nikolay Ivchenkov wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">On Sunday, January 13, 2013 10:=
44:08 PM UTC+4, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div>One that doesn't implicitly decay to pointers, that can be copied/mov=
ed, and so forth.<br></div></blockquote></blockquote></blockquote></blockqu=
ote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>Let me conti=
nue:<br>- it has verbose notation: std::array<T, N> instead of T[N] a=
nd std::array<std::array<T, N2>, N1> instead of T[N1][N2]; =
;</div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>- it incre=
ases compilation time (existing compilers have to parse the content of the =
header <array>);<br></div></blockquote><div><br>I'm sorry, but those =
are just not substantive differences.</div></blockquote><div><br>for _you_<=
br></div></blockquote><div><br>One could say the same for your list.<br>&nb=
sp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div> </div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div> Also, some would argue that while=
the syntax may be more verbose, it is also a lot <i>clearer</i> to the rea=
der exactly what's going on. And reader clarity is a good thing. For exampl=
e, many C++ programmers that haven't spent much time with arrays wouldn't b=
e able to tell the difference between `Type (*)[2]` and `Type *[2]` without=
help. While `std::array<Type, 2>*` vs. `std::array<Type*, 2>` =
makes it all clear.<br></div></blockquote><div><br>We still have built-in a=
rrays, so novices actually have to learn two things instead of one: how bui=
lt-in arrays work and how std::array works (and then think about which one =
should be preferred in a particular case).<br></div></blockquote><div><br>D=
o they? How many novices can actually tell you the difference between `Type=
*[2]` and `Type (*)[2]`? Compare this to the number that could tell you th=
e difference between `std::array<Type, 2>*` and `std::array<Type*,=
2>`.<br><br>As for which should be preferred, again, that's obvious: st=
d::array. It has value semantics like any other object, not a bunch of funk=
y rules like "decays to pointer" and some such.<br><br>Remember: many intro=
C++ texts already tell users to use std::vector <i>instead</i> of arrays e=
ven today. std::array is only going to be another alternative that they are=
told to use instead of arrays. Coupled with vector and array being able to=
participate in aggregate/initializer_list initialization, and 99% of most =
user's reasons to ever use a C-style array go away.<br><br>The number of C+=
+ programmers who understand the deep issues and complex syntax of C-style =
arrays is shrinking, not growing. The knowledge is out there certainly, but=
there are many who don't pursue it. They just don't need to.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div>- a type std::array<const NonConstType, N> is not reference-com=
patible with std::array<NonConstType, N> and const std::array<NonC=
onstType, N> is not reference-compatible with std::array<const NonCon=
stType, N>:<br></div></blockquote><div><br>Well, that first conversion (=
from a const type to a non-const type) shouldn't be allowed, due to breakin=
g const-correctness.</div></blockquote><div><br>I don't see how that is rel=
ated to my words. The former statement implies that<br><br> &nbs=
p; std::array<NonConstType, N> a;<br> std::array<=
;const NonConstType, N> &r =3D a;<br><br>is ill-formed.<br> </d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div>In short, there's no reason=
to ever use `array<const T, N>` over `const array<T, N>` when =
you want a constant array. There might be some template cases where you use=
a `const T` because someone passed you a `const T` as a template type.</di=
v></blockquote><div><br>Alternatively, const element type can be specified =
by a typedef declaration.<br> </div><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div> Then again, one should probably be using `std::remove_cv<T&g=
t;::type` or even `std::decay<T>::type` in those cases anyway, to mak=
e sure that cv-qualifications don't become a problem.<br></div></blockquote=
><div><br>I don't need such complications when I use built-in arrays. So, -=
1 on std::array.<br></div></blockquote><div><br>And I could easily say that=
I need value semantics far more than I need to use arrays in template scen=
arios or with random typedefs. So why suffer the C-style array grief and od=
d-ball behavior when I can just use what works?<br> </div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">Nobody ever said that it was "ideal". There is a difference betwee=
n "X is intended to do Y"</blockquote><div><br>All workarounds are intented=
to do something, so what? I still don't see any reason why C++ programmers=
should use std::array instead of full-fledged built-in arrays.<br></div></=
blockquote><div><br>Then you're not paying attention to the <i>very reason<=
/i> this thread exists: to give C-style arrays similar abilities as std::ar=
ray.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div>std::array should replace most uses of C-s=
tyle arrays that std::vector could not cover. If there are deficiencies in =
that, where there is a legitimate need to use a C-style array, then let's <=
i>fix those</i>.<br></div></blockquote><div><br>Core language can be improv=
ed so that I would not need std::array at all.<br></div></blockquote><div><=
br>Really? Can you give arrays value semantics like regular types? Because =
I'm pretty sure that would break all kinds of backwards compatibility. As w=
ould changing how they work as function arguments. Can you give them sizing=
member functions? What about not decaying to pointers without an explicit =
conversion? I can keep going.<br><br>I seriously doubt C-style arrays can b=
e given these properties without breaking compatibility. You may not want o=
r even like those properties. But std::array exists because boost::array wa=
s a very successful, well-liked class that many people adopted. Other peopl=
e like and want these properties.<br><br>And to be honest, all it would tak=
e for me to <i>never</i> use C-style arrays again (outside of <i>maybe</i> =
for global tables of stuff and possibly not even that) is for the standard =
to provide the same layout guarantee that std::complex has. If I know that =
an array of std::array will work correctly in all circumstances, there will=
never be an interoperability problem that can't be worked around.<br></div=
>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_297_10177091.1358250746080--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Tue, 15 Jan 2013 15:40:35 -0800 (PST)
Raw View
------=_Part_727_22090425.1358293235326
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, January 15, 2013 10:34:30 AM UTC+1, Nikolay Ivchenkov wrote:
> The best thing we can do with it is to provide something like this
>
> namespace std
> {
> template <class T, size_t N>
> auto underlying_array(array<T, N> &x) -> T (&)[N]
> { return reinterpret_cast<T (&)[N]>(x); }
>
> template <class T, size_t N>
> auto underlying_array(array<T, N> *x) -> T (*)[N]
> { return reinterpret_cast<T (*)[N]>(x); }
> }
>
> and guarantee that sizeof(std::array<T, N>) ==
> sizeof(std::underlying_array(std::array<T, N>)) holds for every N > 0.
>
Yes, I'd like that, but the implementation needs to be somewhat extended to
be able to "decay" a std::array<std::array<int, 2>, 3> into a int(&)[3][2].
Somewhere along the lines of
template<class T>
struct underying_array_helper
{ typedef T type; }
template<class T>
using helper = typename underlying_array_helper<T>::type;
template<class T, size_t N>
struct underlying_array_helper<array<T,N>>
{ typedef helper<T> type[N]; }
template <class T, size_t N>
auto underlying_array(array<T, N> &x) -> helper<T>(&)[N]
{ return reinterpret_cast<helper<T>(&)[N]>(x); }
--
------=_Part_727_22090425.1358293235326
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, January 15, 2013 10:34:30 AM UTC+1, Nikolay Ivchenkov wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div>The best thing we can do=
with it is to provide something like this<br><br> namesp=
ace std<br> {<br> &nbs=
p; template <class T, size_t N><br> &nbs=
p; auto underlying_array(array<T, N> &a=
mp;x) -> T (&)[N]<br>  =
; { return reinterpret_cast<T =
(&)[N]>(x); }<br><br> template <c=
lass T, size_t N><br> =
auto underlying_array(array<T, N> *x) -> T (*)[N]<br> =
{ return re=
interpret_cast<T (*)[N]>(x); }<br> }<br><br>and gua=
rantee that sizeof(std::array<T, N>) =3D=3D sizeof(std::underlying_ar=
ray(<wbr>std::array<T, N>)) holds for every N > 0.</div></blockquo=
te><div><br></div><div>Yes, I'd like that, but the implementation needs to =
be somewhat extended to be able to "decay" a std::array<std::array<in=
t, 2>, 3> into a int(&)[3][2]. Somewhere along the lines of</div>=
<div><br></div><div><div>template<class T></div><div> st=
ruct underying_array_helper</div><div> { typedef=
T type; }</div><div><br></div><div>template<class T></div><div> =
; using helper =3D typename underlying_array_helper<T>::type;<=
/div><div><br></div><div>template<class T, size_t N></div><div> =
struct underlying_array_helper<array<T,N>></div><div>&n=
bsp; { typedef helper<T> type[N]; }</div><div><b=
r></div><div>template <class T, size_t N></div><div> aut=
o underlying_array(array<T, N> &x) -> helper<T>(&)[N=
]</div><div> { return reinterpret_cast<helper=
<T>(&)[N]>(x); }</div></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_727_22090425.1358293235326--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 16 Jan 2013 02:01:52 -0600
Raw View
On Tue, Jan 15, 2013 at 5:40 PM, Sylvester Hesp <s.hesp@oisyn.nl> wrote:
> Yes, I'd like that, but the implementation needs to be somewhat extended to
> be able to "decay" a std::array<std::array<int, 2>, 3> into a int(&)[3][2].
I think my idea of extending std::array to multidimensional is more
clear. The implementation will be trivial:
template <typename T, size_t...>
struct array;
// original std::array
template <typename T, size_t N>
struct array<T, N> {
typedef T type[N];
};
// just repeat std::array once, here
template <typename T, size_t N, size_t... M>
struct array<T, N, M...> {
typedef typename array<T, M...>::type type[N];
};
int main() {
array<int, 1, 2, 3>::type a = { {{0, 2, 3}, {0, 2, 3}} };
}
And the index order becomes more intuitive.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Wed, 16 Jan 2013 00:35:07 -0800 (PST)
Raw View
------=_Part_2371_19032838.1358325307329
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, January 15, 2013 3:52:26 PM UTC+4, Nicol Bolas wrote:
>
>> We still have built-in arrays, so novices actually have to learn two
>> things instead of one: how built-in arrays work and how std::array works
>> (and then think about which one should be preferred in a particular case).
>>
>
> Do they?
>
Yes. The presence of std::array doesn't imply that programmers won't have
to deal with built-in arrays anymore.
> How many novices can actually tell you the difference between `Type *[2]`
> and `Type (*)[2]`?
>
They still have to learn that difference.
> As for which should be preferred, again, that's obvious: std::array. It
> has value semantics like any other object, not a bunch of funky rules like
> "decays to pointer" and some such.
>
That's not obvious and your reasoning is not convincing.
> Remember: many intro C++ texts already tell users to use std::vector *
> instead* of arrays even today.
>
How horrible. It seems that I'm already dealing with consequences of such
wise advices :-(
All workarounds are intented to do something, so what? I still don't see
>> any reason why C++ programmers should use std::array instead of
>> full-fledged built-in arrays.
>>
>
> Then you're not paying attention to the *very reason* this thread exists:
> to give C-style arrays similar abilities as std::array.
>
I don't see point in your conclusion.
Can you give arrays value semantics like regular types?
>
If we want array types such that std::decay<array_type>::type would be the
same as std::remove_cv<array_type>::type, then we would need alternative
kind of built-in arrays, which could have much better flexibility and
interoperability with regular arrays than std::array:
int *i = new <int>; // OK
char (*ac1)[2] = new <char[2]>; // OK
char (*ac2)[2] = new char[/2]; // OK
char (*ac3)[/2] = new char[/2]; // OK
char (*ac4)[/2] = new <char[2]>; // OK
char s1[] = "text"; // s1 has type char[5]
char s2[/] = "text"; // s2 has type char[/5]
auto s3 = +s1; // +s1 has type char[/5], s3 has type char[/5]
auto s4 = s2; // s4 has type char[/5]
char s5[] = s1; // s5 has type char[5]
char s6[] = s2; // s6 has type char[5]
static_assert(
std::is_same<std::decay<char[/2]>::type, char[/2]>{}, ""); // OK
auto f(char x[/2]) -> char[2] // OK, x has type char[/2]
{ return x; } // OK
Because I'm pretty sure that would break all kinds of backwards
> compatibility.
>
No breaking changes.
> Can you give them sizing member functions?
>
We could use begin(array), end(array) and size(array) instead of
array.begin(), array.end() and array.size().
What about not decaying to pointers without an explicit conversion?
>
I doubt that that would be useful, but we could have
char a[/2];
int *p1(a); // well-formed
int *p2 = a; // ill-formed
> But std::array exists because boost::array was a very successful,
> well-liked class that many people adopted. Other people like and want these
> properties.
>
boost::enable_if and boost::bind are also very useful, because there are no
suitable alternatives. Proper core language constructs might completely
replace such crutches and be much more useful.
--
------=_Part_2371_19032838.1358325307329
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, January 15, 2013 3:52:26 PM UTC+4, Nicol Bolas wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><br><div>We still have built-in arrays, so novices actually have to lea=
rn two things instead of one: how built-in arrays work and how std::array w=
orks (and then think about which one should be preferred in a particular ca=
se).<br></div></blockquote><div><br>Do they?</div></blockquote><div><br>Yes=
.. The presence of std::array doesn't imply that programmers won't have to d=
eal with built-in arrays anymore.<br> </div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div> How many novices can actually tell you the differe=
nce between `Type *[2]` and `Type (*)[2]`?</div></blockquote><div><br>They =
still have to learn that difference.<br> </div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div>As for which should be preferred, again, that's =
obvious: std::array. It has value semantics like any other object, not a bu=
nch of funky rules like "decays to pointer" and some such.<br></div></block=
quote><div><br>That's not obvious and your reasoning is not convincing.<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Remember: man=
y intro C++ texts already tell users to use std::vector <i>instead</i> of a=
rrays even today.</div></blockquote><div><br>How horrible. It seems that I'=
m already dealing with consequences of such wise advices :-(<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div>All workarounds are intented to do something, so what? I stil=
l don't see any reason why C++ programmers should use std::array instead of=
full-fledged built-in arrays.<br></div></blockquote><div><br>Then you're n=
ot paying attention to the <i>very reason</i> this thread exists: to give C=
-style arrays similar abilities as std::array.<br></div></blockquote><div><=
br>I don't see point in your conclusion.<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"></blockquote><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div> Can you give arrays value semantics like regular types?</div><=
/blockquote><div><br>If we want array types such that std::decay<array_t=
ype>::type would be the same as std::remove_cv<array_type>::type, =
then we would need alternative kind of built-in arrays, which could have mu=
ch better flexibility and interoperability with regular arrays than std::ar=
ray:<br><br> int *i =3D new <int>; // OK<br> &=
nbsp; char (*ac1)[2] =3D new <char[2]>; // OK<br> &n=
bsp; char (*ac2)[2] =3D new char[/2]; // OK<br> char (*ac=
3)[/2] =3D new char[/2]; // OK<br> char (*ac4)[/2] =3D ne=
w <char[2]>; // OK<br><br> char s1[] =3D "text"; //=
s1 has type char[5]<br> char s2[/] =3D "text"; // s2 has=
type char[/5]<br> auto s3 =3D +s1; // +s1 has type char[=
/5], s3 has type char[/5]<br> auto s4 =3D s2; // s4 has t=
ype char[/5]<br> char s5[] =3D s1; // s5 has type char[5]=
<br> char s6[] =3D s2; // s6 has type char[5]<br><br>&nbs=
p; static_assert(<br> =
std::is_same<std::decay<char[/2]>::type, char[/2]>{}, ""); // =
OK<br> <br> auto f(char x[/2]) -> char[2] // OK, =
x has type char[/2]<br> { return =
x; } // OK<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div> =
Because I'm pretty sure that would break all kinds of backwards compatibili=
ty.</div></blockquote><div><br>No breaking changes.<br> <br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div> Can you give them sizing mem=
ber functions?</div></blockquote><div><br>We could use begin(array), end(ar=
ray) and size(array) instead of array.begin(), array.end() and array.size()=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div> What abou=
t not decaying to pointers without an explicit conversion?</div></blockquot=
e><div><br>I doubt that that would be useful, but we could have<br><br>&nbs=
p; char a[/2];<br> int *p1(a); // well-formed=
<br> int *p2 =3D a; // ill-formed<br> </div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div>But std::array exists because boo=
st::array was a very successful, well-liked class that many people adopted.=
Other people like and want these properties.<br></div></blockquote><div><b=
r>boost::enable_if and boost::bind are also very useful, because there are =
no suitable alternatives. Proper core language constructs might completely =
replace such crutches and be much more useful.</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_2371_19032838.1358325307329--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Wed, 16 Jan 2013 00:56:18 -0800 (PST)
Raw View
------=_Part_181_6478855.1358326578701
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, January 15, 2013 3:52:26 PM UTC+4, Nicol Bolas wrote:
>
> We still have built-in arrays, so novices actually have to learn two
>> things instead of one: how built-in arrays work and how std::array works
>> (and then think about which one should be preferred in a particular case).
>>
>
> Do they?
>
Yes. The presence of std::array doesn't imply that programmers won't have
to deal with built-in arrays anymore.
> How many novices can actually tell you the difference between `Type *[2]`
> and `Type (*)[2]`? Compare this to the number that could tell you the
> difference between `std::array<Type, 2>*` and `std::array<Type*, 2>`.
>
They still have to learn that difference.
> As for which should be preferred, again, that's obvious: std::array. It
> has value semantics like any other object, not a bunch of funky rules like
> "decays to pointer" and some such.
>
That's not obvious and your reasoning is not convincing.
> Remember: many intro C++ texts already tell users to use std::vector *
> instead* of arrays even today.
>
How horrible. It seems that I'm already dealing with consequences of such
wise advices :-(
> All workarounds are intented to do something, so what? I still don't see
>> any reason why C++ programmers should use std::array instead of
>> full-fledged built-in arrays.
>>
>
> Then you're not paying attention to the *very reason* this thread exists:
> to give C-style arrays similar abilities as std::array.
>
I don't see point in your conclusion.
> Can you give arrays value semantics like regular types?
If we want array types such that std::decay<array_type>::type would be the
same as std::remove_cv<array_type>::
type, then we would need alternative kind of built-in arrays, which could
have much better flexibility and interoperability with regular arrays than
std::array:
int *i = new <int>; // OK
char (*ac1)[2] = new <char[2]>; // OK
char (*ac2)[2] = new char[/2]; // OK
char (*ac3)[/2] = new char[/2]; // OK
char (*ac4)[/2] = new <char[2]>; // OK
char s1[] = "text"; // s1 has type char[5]
char s2[/] = "text"; // s2 has type char[/5]
auto s3 = +s1; // +s1 has type char[/5], s3 has type char[/5]
auto s4 = s2; // s4 has type char[/5]
char s5[] = s1; // s5 has type char[5]
char s6[] = s2; // s6 has type char[5]
static_assert(
std::is_same<std::decay<char[/2]>::type, char[/2]>{}, ""); // OK
auto f(char x[/2]) -> char[2] // OK, x has type char[/2]
{ return x; } // OK
> Because I'm pretty sure that would break all kinds of backwards
> compatibility.
No breaking changes.
Can you give them sizing member functions?
We could use begin(array), end(array) and size(array) instead of
array.begin(), array.end() and array.size().
> What about not decaying to pointers without an explicit conversion?
>
I doubt that that would be useful, but we could have
int a[/2];
int *p1(a); // well-formed
int *p2 = a; // ill-formed
> But std::array exists because boost::array was a very successful,
> well-liked class that many people adopted.
>
boost::enable_if/std::enable_if and boost::bind/std::bind are also very
useful, because there are no suitable alternatives. Proper core language
constructs might completely replace such crutches and be much more useful.
--
------=_Part_181_6478855.1358326578701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, January 15, 2013 3:52:26 PM UTC+4, Nicol Bolas wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div>We still have built-in arrays, so novices actually have to learn two =
things instead of one: how built-in arrays work and how std::array works (a=
nd then think about which one should be preferred in a particular case).<br=
></div></blockquote><div><br>Do they?</div></blockquote><div><br>Yes. The p=
resence of std::array doesn't imply that programmers won't have to deal wit=
h built-in arrays anymore.<br> </div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div> How many novices can actually tell you the difference bet=
ween `Type *[2]` and `Type (*)[2]`? Compare this to the number that could t=
ell you the difference between `std::array<Type, 2>*` and `std::array=
<Type*, 2>`.<br></div></blockquote><div><br>They still have to learn =
that difference.<br> </div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div>As for which should be preferred, again, that's obvious: std::array.=
It has value semantics like any other object, not a bunch of funky rules l=
ike "decays to pointer" and some such.<br></div></blockquote><div><br>That'=
s not obvious and your reasoning is not convincing.<br> </div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div>Remember: many intro C++ texts al=
ready tell users to use std::vector <i>instead</i> of arrays even today.</d=
iv></blockquote><div><br>How horrible. It seems that I'm already dealing wi=
th consequences of such wise advices :-(<br> </div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Al=
l workarounds are intented to do something, so what? I still don't see any =
reason why C++ programmers should use std::array instead of full-fledged bu=
ilt-in arrays.<br></div></blockquote><div><br>Then you're not paying attent=
ion to the <i>very reason</i> this thread exists: to give C-style arrays si=
milar abilities as std::array.<br></div></blockquote><div><br>I don't see p=
oint in your conclusion.<br> <br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">Can you give arrays value semantics like regular types?</bloc=
kquote><div><br>If we want array types such that std::decay<array_type&g=
t;::type would be the same as std::remove_cv<array_type>::<div><wbr>t=
ype,
then we would need alternative kind of built-in arrays, which could=20
have much better flexibility and interoperability with regular arrays=20
than std::array:<br><br> int *i =3D new <int>; // O=
K<br> char (*ac1)[2] =3D new <char[2]>; // OK<br>&n=
bsp; char (*ac2)[2] =3D new char[/2]; // OK<br> &nbs=
p; char (*ac3)[/2] =3D new char[/2]; // OK<br> char (*ac4=
)[/2] =3D new <char[2]>; // OK<br><br> char s1[] =
=3D "text"; // s1 has type char[5]<br> char s2[/] =3D "te=
xt"; // s2 has type char[/5]<br> auto s3 =3D +s1; // +s1 =
has type char[/5], s3 has type char[/5]<br> auto s4 =3D s=
2; // s4 has type char[/5]<br> char s5[] =3D s1; // s5 ha=
s type char[5]<br> char s6[] =3D s2; // s6 has type char[=
5]<br><br> static_assert(<br> &nbs=
p; std::is_same<std::decay<char[/<wbr>2]>::type, char[=
/2]>{}, ""); // OK<br> <br> auto f(char x[/2]) -&=
gt; char[2] // OK, x has type char[/2]<br> &nb=
sp; { return x; } // OK</div> </div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"> Because I'm pretty sure that would break all kinds of bac=
kwards compatibility.</blockquote><div><br>No breaking changes.<br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"> Can you give them sizing me=
mber functions?</blockquote><div><br>We could use begin(array), end(array) =
and size(array) instead of array.begin(), array.end() and array.size().<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> What about not de=
caying to pointers without an explicit conversion?<br></blockquote><div><br=
>I doubt that that would be useful, but we could have<br><br> &n=
bsp; int a[/2];<br> int *p1(a); // well-formed<br> &=
nbsp; int *p2 =3D a; // ill-formed<br> </div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div>But std::array exists because boost::array=
was a very successful, well-liked class that many people adopted.<br></div=
></blockquote><div><br>boost::enable_if/std::enable_if and boost::bind/std:=
:bind are also very useful, because there are
no suitable alternatives. Proper core language constructs might=20
completely replace such crutches and be much more useful.</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_181_6478855.1358326578701--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Wed, 16 Jan 2013 08:19:18 -0800 (PST)
Raw View
------=_Part_881_31431067.1358353158479
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, January 16, 2013 9:01:52 AM UTC+1, Zhihao Yuan wrote:
>
> On Tue, Jan 15, 2013 at 5:40 PM, Sylvester Hesp <s.h...@oisyn.nl<javascript:>>
> wrote:
> > Yes, I'd like that, but the implementation needs to be somewhat extended
> to
> > be able to "decay" a std::array<std::array<int, 2>, 3> into a
> int(&)[3][2].
>
> I think my idea of extending std::array to multidimensional is more
> clear.
That's besides the point, really. When explicitely dealing with
multidimensional array types, I agree. But you don't always do that.
template<class T>
void foo()
{
array<T, 2> a;
bar(underlying_array(a));
}
foo<array<int, 2>>();
You're going to have to deal with array<array<T, N>, M> sooner or later,
even if array<T, N, M> also exists. I'd like both of them to be compatible
with T(&)[M][N].
--
------=_Part_881_31431067.1358353158479
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, January 16, 2013 9:01:52 AM UTC+1, Zhihao Yuan wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">On Tue, Jan 15, 2013 at 5:40 P=
M, Sylvester Hesp <<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"uMpPcUp_qKcJ">s.h...@oisyn.nl</a>> wrote:
<br>> Yes, I'd like that, but the implementation needs to be somewhat ex=
tended to
<br>> be able to "decay" a std::array<std::array<int, 2>, 3>=
into a int(&)[3][2].
<br>
<br>I think my idea of extending std::array to multidimensional is more
<br>clear.</blockquote><div><br></div><div>That's besides the point, really=
.. When explicitely dealing with multidimensional array types, I agree. But =
you don't always do that.</div><div><br></div><div>template<class T><=
/div><div>void foo()</div><div>{</div><div> array<T, 2> =
a;</div><div> bar(underlying_array(a));<br></div><div>}</div><=
div><br></div><div>foo<array<int, 2>>();</div><div><br></div><d=
iv>You're going to have to deal with array<array<T, N>, M> soon=
er or later, even if array<T, N, M> also exists. I'd like both of the=
m to be compatible with T(&)[M][N].</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_881_31431067.1358353158479--
.