------=_Part_176_28664580.1378513032372
Content-Type: text/plain; charset=ISO-8859-1

As an exercise in using variadic templates, I chose a multi-dimensional
variant of std::array.  I eventually made the interface match std::array
when the number of extents given is one.  When wondering if I should put
the class template up for consideration, I realized that it would be so
close to std::array, that I shouldn't propose my class directly for the
Standard Library, but propose a change to std::array instead.

I just put it up at https://github.com/CTMacUser/multiarray-iso-proposal,for requesting comments before officially proposing it.  (I should switch
to HTML or some other rich-text system for the next draft....)

Daryle W.


--

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

------=_Part_176_28664580.1378513032372
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>As an exercise in using variadic templates, I chose a=
 multi-dimensional variant of std::array.&nbsp; I eventually made the inter=
face match std::array when the number of extents given is one.&nbsp; When w=
ondering if I should put the class template up for consideration, I realize=
d that it would be so close to std::array, that I shouldn't propose my clas=
s directly for the Standard Library, but propose a change to std::array ins=
tead.</div><div>&nbsp;</div><div>I just put it up at <a href=3D"https://git=
hub.com/CTMacUser/multiarray-iso-proposal,">https://github.com/CTMacUser/mu=
ltiarray-iso-proposal,</a> for requesting comments before officially propos=
ing it.&nbsp; (I should switch to HTML or some other rich-text system for t=
he next draft....)</div><div>&nbsp;</div><div>Daryle W.</div><div>&nbsp;</d=
iv></div>

<p></p>

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

------=_Part_176_28664580.1378513032372--

.

------=_Part_68_25515849.1378519110097
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I think the initializer_list overloads may be unnecessary, and turn what=20
should be a compile-time arity check to a runtime assertion on size(). They=
=20
could help to support very high dimensionality, higher than the maximum=20
supported number of function arguments, but I don't think most relevant=20
platforms actually have such a limitation, and low dimensionality could be=
=20
penalized by adding the overhead of the pointers and "hard" stack=20
allocation.

Another approach would be to make std::multi_array an alias template to a=
=20
nested std::array type. The multidimensional accessor overloads could be=20
added to one-dimensional std::array and delegate recursively to the=20
underlying type. This would support existing code which nests std::array,=
=20
or even other numeric libraries inside std::array (which I have done with=
=20
Eigen; there are advantages to this and practical use cases). It would=20
incur nonsense semantics for operator() on an array over a type with=20
well-defined operator() ( std::size_t [, std::size_t =85 ] )=97 but that's =
a=20
corner case, and array::operator() isn't so far defined anyway. The=20
interface and implementation would be more lightweight.

When was the last time n-adic operator[] support was considered? Doesn't=20
the potential use in the scientific arena outweigh the need to support=20
abuse of the comma operator inside square brackets? C'mon, let's deprecate=
=20
that syntactic sucker.

--=20

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

------=_Part_68_25515849.1378519110097
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think the initializer_list overloads may be unnecessary,=
 and turn what should be a compile-time arity check to a runtime assertion =
on size(). They could help to support very high dimensionality, higher than=
 the maximum supported number of function arguments, but I don't think most=
 relevant platforms actually have such a limitation, and low dimensionality=
 could be penalized by adding the overhead of the pointers and "hard" stack=
 allocation.<br><br>Another approach would be to make <span style=3D"font-f=
amily: courier new,monospace;">std::multi_array</span> an alias template to=
 a nested <span style=3D"font-family: courier new,monospace;">std::array</s=
pan> type. The multidimensional accessor overloads could be added to one-di=
mensional <span style=3D"font-family: courier new,monospace;">std::array</s=
pan> and delegate recursively to the underlying type. This would support ex=
isting code which nests <span style=3D"font-family: courier new,monospace;"=
>std::array</span>, or even other numeric libraries inside <span style=3D"f=
ont-family: courier new,monospace;">std::array</span> (which I have done wi=
th Eigen; there are advantages to this and practical use cases). It would i=
ncur nonsense semantics for operator() on an array over a type with well-de=
fined <span style=3D"font-family: courier new,monospace;">operator() ( std:=
:size_t [, std::size_t =85 ] )</span>=97 but that's a corner case, and <spa=
n style=3D"font-family: courier new,monospace;">array::operator()</span> is=
n't so far defined anyway. The interface and implementation would be more l=
ightweight.<br><br>When was the last time n-adic <span style=3D"font-family=
: courier new,monospace;">operator[]</span> support was considered? Doesn't=
 the potential use in the scientific arena outweigh the need to support abu=
se of the comma operator inside square brackets? C'mon, let's deprecate tha=
t syntactic sucker.<br><br></div>

<p></p>

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

------=_Part_68_25515849.1378519110097--

.

------=_Part_133_32865093.1378519121133
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I think the initializer_list overloads may be unnecessary, and turn what=20
should be a compile-time arity check to a runtime assertion on size(). They=
=20
could help to support very high dimensionality, higher than the maximum=20
supported number of function arguments, but I don't think most relevant=20
platforms actually have such a limitation, and low dimensionality could be=
=20
penalized by adding the overhead of the pointers and "hard" stack=20
allocation.

Another approach would be to make std::multi_array an alias template to a=
=20
nested std::array type. The multidimensional accessor overloads could be=20
added to one-dimensional std::array and delegate recursively to the=20
underlying type. This would support existing code which nests std::array,=
=20
or even other numeric libraries inside std::array (which I have done with=
=20
Eigen; there are advantages to this and practical use cases). It would=20
incur nonsense semantics for operator() on an array over a type with=20
well-defined operator() ( std::size_t [, std::size_t =85 ] )=97 but that's =
a=20
corner case, and array::operator() isn't so far defined anyway. The=20
interface and implementation would be more lightweight.

When was the last time n-adic operator[] support was considered? Doesn't=20
the potential use in the scientific arena outweigh the need to support=20
abuse of the comma operator inside square brackets? C'mon, let's deprecate=
=20
that syntactic sucker.

--=20

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

------=_Part_133_32865093.1378519121133
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think the initializer_list overloads may be unnecessary,=
 and turn what should be a compile-time arity check to a runtime assertion =
on size(). They could help to support very high dimensionality, higher than=
 the maximum supported number of function arguments, but I don't think most=
 relevant platforms actually have such a limitation, and low dimensionality=
 could be penalized by adding the overhead of the pointers and "hard" stack=
 allocation.<br><br>Another approach would be to make <span style=3D"font-f=
amily: courier new,monospace;">std::multi_array</span> an alias template to=
 a nested <span style=3D"font-family: courier new,monospace;">std::array</s=
pan> type. The multidimensional accessor overloads could be added to one-di=
mensional <span style=3D"font-family: courier new,monospace;">std::array</s=
pan> and delegate recursively to the underlying type. This would support ex=
isting code which nests <span style=3D"font-family: courier new,monospace;"=
>std::array</span>, or even other numeric libraries inside <span style=3D"f=
ont-family: courier new,monospace;">std::array</span> (which I have done wi=
th Eigen; there are advantages to this and practical use cases). It would i=
ncur nonsense semantics for operator() on an array over a type with well-de=
fined <span style=3D"font-family: courier new,monospace;">operator() ( std:=
:size_t [, std::size_t =85 ] )</span>=97 but that's a corner case, and <spa=
n style=3D"font-family: courier new,monospace;">array::operator()</span> is=
n't so far defined anyway. The interface and implementation would be more l=
ightweight.<br><br>When was the last time n-adic <span style=3D"font-family=
: courier new,monospace;">operator[]</span> support was considered? Doesn't=
 the potential use in the scientific arena outweigh the need to support abu=
se of the comma operator inside square brackets? C'mon, let's deprecate tha=
t syntactic sucker.<br><br></div>

<p></p>

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

------=_Part_133_32865093.1378519121133--

.

------=_Part_239_20302054.1378571446971
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Friday, September 6, 2013 9:58:30 PM UTC-4, David Krauss wrote:
>
> I think the initializer_list overloads may be unnecessary, and turn what=
=20
> should be a compile-time arity check to a runtime assertion on size(). Th=
ey=20
> could help to support very high dimensionality, higher than the maximum=
=20
> supported number of function arguments, but I don't think most relevant=
=20
> platforms actually have such a limitation, and low dimensionality could b=
e=20
> penalized by adding the overhead of the pointers and "hard" stack=20
> allocation.
>
> The indexing operator (operator []) takes exactly one operand.  To work=
=20
around that, I made the variadic operator() member templates.  I even made=
=20
them return a sub-array when fewer arguments than dimensions were given.  I=
=20
made versions of at to match.  Then I read the Standard and found out opera=
tor=20
[] now supports multiple arguments indirectly through the braced-init-list=
=20
syntax.  So I got to make a version of operator [] that takes "multiple"=20
arguments, more as a demonstration than a straight-up necessity.  Then I=20
made similar versions of at to match, then operator () so no one will be=20
asking why I skipped that one.
=20
Compilers should make true array access faster than pointer arithmetic.
=20
Stack allocation is the point of things like std::array over the regular=20
containers.  Plus, non-dynamic containers can be used in constant=20
expressions, including constexpr contexts.
=20

> Another approach would be to make std::multi_array an alias template to a=
=20
> nested std::array type. The multidimensional accessor overloads could be=
=20
> added to one-dimensional std::array and delegate recursively to the=20
> underlying type. This would support existing code which nests std::array,=
=20
> or even other numeric libraries inside std::array (which I have done with=
=20
> Eigen; there are advantages to this and practical use cases). It would=20
> incur nonsense semantics for operator() on an array over a type with=20
> well-defined operator() ( std::size_t [, std::size_t =85 ] )=97 but that'=
s a=20
> corner case, and array::operator() isn't so far defined anyway. The=20
> interface and implementation would be more lightweight.
>
> This multi_array would be like the stack and queue adaptors?  You can=20
already make an array of a built-in array type, another std::array, or a=20
custom array-like class type.  But the point was to make something more=20
integrated.
=20
=20

> When was the last time n-adic operator[] support was considered? Doesn't=
=20
> the potential use in the scientific arena outweigh the need to support=20
> abuse of the comma operator inside square brackets? C'mon, let's deprecat=
e=20
> that syntactic sucker.
>
> I don't know why non-single parameters are banned for operator[].  But no=
w=20
C++11 has given us a single std::initializer_list parameter as a=20
workaround.=20
=20
Daryle W.
=20

--=20

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

------=_Part_239_20302054.1378571446971
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Friday, September 6, 2013 9:58:30 PM UTC-4, David K=
rauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I think the initi=
alizer_list overloads may be unnecessary, and turn what should be a compile=
-time arity check to a runtime assertion on size(). They could help to supp=
ort very high dimensionality, higher than the maximum supported number of f=
unction arguments, but I don't think most relevant platforms actually have =
such a limitation, and low dimensionality could be penalized by adding the =
overhead of the pointers and "hard" stack allocation.<br><br></div></blockq=
uote><div>The indexing operator (<font face=3D"courier new,monospace">opera=
tor []</font>) takes exactly one operand.&nbsp; To work around that, I made=
 the variadic <font face=3D"courier new,monospace">operator()</font> member=
 templates.&nbsp; I even made them return a sub-array when fewer arguments =
than dimensions were given.&nbsp; I made versions of <font face=3D"courier =
new,monospace">at</font> to match.&nbsp; Then I read the Standard and found=
 out <font face=3D"courier new,monospace">operator []</font> now supports m=
ultiple arguments indirectly&nbsp;through the braced-init-list syntax.&nbsp=
; So I got to make a version of <font face=3D"courier new,monospace">operat=
or []</font> that takes "multiple" arguments, more as a demonstration than =
a straight-up necessity.&nbsp; Then I made similar versions of <font face=
=3D"courier new,monospace">at</font> to match, then <font face=3D"courier n=
ew,monospace">operator ()</font> so no one will be asking why I skipped tha=
t one.</div><div>&nbsp;</div><div>Compilers should make true array access f=
aster than pointer arithmetic.</div><div>&nbsp;</div><div>Stack allocation =
is the point of things like <font face=3D"courier new,monospace">std::array=
</font> over the regular containers.&nbsp; Plus, non-dynamic containers can=
 be <font face=3D"arial,sans-serif">used in constant expressions, including=
 <font face=3D"courier new,monospace">constexpr</font> contexts</font>.</di=
v><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">Another ap=
proach would be to make <span style=3D"font-family: courier new,monospace;"=
>std::multi_array</span> an alias template to a nested <span style=3D"font-=
family: courier new,monospace;">std::array</span> type. The multidimensiona=
l accessor overloads could be added to one-dimensional <span style=3D"font-=
family: courier new,monospace;">std::array</span> and delegate recursively =
to the underlying type. This would support existing code which nests <span =
style=3D"font-family: courier new,monospace;">std::array</span>, or even ot=
her numeric libraries inside <span style=3D"font-family: courier new,monosp=
ace;">std::array</span> (which I have done with Eigen; there are advantages=
 to this and practical use cases). It would incur nonsense semantics for op=
erator() on an array over a type with well-defined <span style=3D"font-fami=
ly: courier new,monospace;">operator() ( std::size_t [, std::size_t =85 ] )=
</span>=97 but that's a corner case, and <span style=3D"font-family: courie=
r new,monospace;">array::operator()</span> isn't so far defined anyway. The=
 interface and implementation would be more lightweight.<br><br></div></blo=
ckquote><div>This <font face=3D"courier new,monospace">multi_array</font> w=
ould be like the <font face=3D"courier new,monospace">stack</font> and <fon=
t face=3D"courier new,monospace">queue</font> adaptors?&nbsp; You can alrea=
dy make an <font face=3D"courier new,monospace">array</font> of a built-in =
array type, another <font face=3D"courier new,monospace">std::array</font>,=
 or a custom array-like class type.&nbsp; But the point was to make somethi=
ng more integrated.</div><div>&nbsp;</div><div>&nbsp;</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bo=
rder-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-st=
yle: solid;"><div dir=3D"ltr">When was the last time n-adic <span style=3D"=
font-family: courier new,monospace;">operator[]</span> support was consider=
ed? Doesn't the potential use in the scientific arena outweigh the need to =
support abuse of the comma operator inside square brackets? C'mon, let's de=
precate that syntactic sucker.<br><br></div></blockquote><div>I don't know =
why non-single parameters are&nbsp;banned for operator[].&nbsp; But now C++=
11 has given us&nbsp;a single <font face=3D"courier new,monospace">std::ini=
tializer_list</font> parameter as a workaround.&nbsp;</div><div>&nbsp;</div=
><div>Daryle W.</div><div>&nbsp;</div></div>

<p></p>

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

------=_Part_239_20302054.1378571446971--

.

------=_Part_798_21321706.1378600192983
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Sunday, September 8, 2013 12:30:46 AM UTC+8, Daryle Walker wrote:
>
>
> On Friday, September 6, 2013 9:58:30 PM UTC-4, David Krauss wrote:
>>
>> I think the initializer_list overloads may be unnecessary, and turn what=
=20
>> should be a compile-time arity check to a runtime assertion on size(). T=
hey=20
>> could help to support very high dimensionality, higher than the maximum=
=20
>> supported number of function arguments, but I don't think most relevant=
=20
>> platforms actually have such a limitation, and low dimensionality could =
be=20
>> penalized by adding the overhead of the pointers and "hard" stack=20
>> allocation.
>>
>> The indexing operator (operator []) takes exactly one operand.  To work=
=20
> around that, I made the variadic operator() member templates.  I even=20
> made them return a sub-array when fewer arguments than dimensions were=20
> given.  I made versions of at to match.  Then I read the Standard and=20
> found out operator [] now supports multiple arguments indirectly through=
=20
> the braced-init-list syntax.
>

What other class braced-init-lists which are required to be an exact size?=
=20
Just because the core language makes something possible, doesn't make it a=
=20
good idea.
=20

> Compilers should make true array access faster than pointer arithmetic.
>

???=20

 Stack allocation is the point of things like std::array over the regular=
=20
> containers.  Plus, non-dynamic containers can be used in constant=20
> expressions, including constexpr contexts.
>

I mean allocating space for the index arguments, not the array. They should=
=20
go into registers. When it comes to temporary, small arrays, registers =3D=
=20
fast, stack =3D slow, heap =3D stupid.=20
=20

> Another approach would be to make std::multi_array an alias template to a=
=20
>> nested std::array type. The multidimensional accessor overloads could be=
=20
>> added to one-dimensional std::array and delegate recursively to the=20
>> underlying type. This would support existing code which nests std::array=
,=20
>> or even other numeric libraries inside std::array (which I have done=20
>> with Eigen; there are advantages to this and practical use cases). It wo=
uld=20
>> incur nonsense semantics for operator() on an array over a type with=20
>> well-defined operator() ( std::size_t [, std::size_t =85 ] )=97 but that=
's a=20
>> corner case, and array::operator() isn't so far defined anyway. The=20
>> interface and implementation would be more lightweight.
>>
>> This multi_array would be like the stack and queue adaptors?
>

No, an alias template =97 a metafunction which looks like a class template.

template< typename t, std::size_t next_extent, std::size_t ... rem_extent >
struct multi_array_helper // metafunction
    { typedef std::array< typename multi_array_helper< t, rem_extent ... >:=
:type=20
> type; };

template< typename t, std::size_t extent >
struct multi_array_helper< t, extent >
    { typedef std::array< t, extent > type; };

template< typename t, std::size_t ... extent >
using multi_array =3D typename multi_array_helper< t, extent ... >::type; /=
/=20
alias template
=20

>   You can already make an array of a built-in array type, another=20
> std::array, or a custom array-like class type.  But the point was to make=
=20
> something more integrated.=20
>

"Separate" is the opposite of "integrated." The best-integrated solution is=
=20
the one which leverages existing facilities and avoids creating new types.

As I said, my proposal would support existing code using nested std::array<=
=20
std::array< =85 > > and other non-standard array types inside std::array.
=20

> When was the last time n-adic operator[] support was considered? Doesn't=
=20
>> the potential use in the scientific arena outweigh the need to support=
=20
>> abuse of the comma operator inside square brackets? C'mon, let's depreca=
te=20
>> that syntactic sucker.
>>
>> I don't know why non-single parameters are banned for operator[].  But=
=20
> now C++11 has given us a single std::initializer_list parameter as a=20
> workaround.=20
>

Accepting different semantics to get a syntactic workaround is a bad idea.=
=20
The ban is for the reason I mentioned, comma operator abuse e.g. x[y, z].

--=20

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

------=_Part_798_21321706.1378600192983
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Sunday, September 8, 2013 12:30:46 AM UTC+8, Daryle=
 Walker wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><br>On Friday, September 6, 2013 9:58:30 PM UTC-4, David Krauss wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-lef=
t:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-=
style:solid"><div dir=3D"ltr">I
 think the initializer_list overloads may be unnecessary, and turn what=20
should be a compile-time arity check to a runtime assertion on size().=20
They could help to support very high dimensionality, higher than the=20
maximum supported number of function arguments, but I don't think most=20
relevant platforms actually have such a limitation, and low=20
dimensionality could be penalized by adding the overhead of the pointers
 and "hard" stack allocation.<br><br></div></blockquote><div>The indexing o=
perator (<font face=3D"courier new,monospace">operator []</font>) takes exa=
ctly one operand.&nbsp; To work around that, I made the variadic <font face=
=3D"courier new,monospace">operator()</font> member templates.&nbsp; I even=
 made them return a sub-array when fewer arguments than dimensions were giv=
en.&nbsp; I made versions of <font face=3D"courier new,monospace">at</font>=
 to match.&nbsp; Then I read the Standard and found out <font face=3D"couri=
er new,monospace">operator []</font> now supports multiple arguments indire=
ctly&nbsp;through the braced-init-list syntax.</div></div></blockquote><div=
><br>What
 other class braced-init-lists which are required to be an exact size?=20
Just because the core language makes something possible, doesn't make it
 a good idea.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">Compilers should make true array access faster than pointer=
 arithmetic.</div></blockquote><div><br>??? <br><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 dir=3D"ltr"><div>&nbsp;Stack allocation is=
 the point of things like <font face=3D"courier new,monospace">std::array</=
font> over the regular containers.&nbsp; Plus, non-dynamic containers can b=
e <font face=3D"arial,sans-serif">used in constant expressions, including <=
font face=3D"courier new,monospace">constexpr</font> contexts</font>.<br></=
div></div></blockquote><div><br>I mean allocating space for the index argum=
ents, not the <span style=3D"font-family: courier new,monospace;">array</sp=
an>. They should go into registers. When it comes to temporary, small array=
s, registers =3D fast, stack =3D slow, heap =3D stupid. <br>&nbsp;</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border=
-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"=
><div dir=3D"ltr">Another approach would be to make <span style=3D"font-fam=
ily:courier new,monospace">std::multi_array</span> an alias template to a n=
ested <span style=3D"font-family:courier new,monospace">std::array</span> t=
ype. The multidimensional accessor overloads could be added to one-dimensio=
nal <span style=3D"font-family:courier new,monospace">std::array</span> and=
 delegate recursively to the underlying type. This would support existing c=
ode which nests <span style=3D"font-family:courier new,monospace">std::arra=
y</span>, or even other numeric libraries inside <span style=3D"font-family=
:courier new,monospace">std::array</span>
 (which I have done with Eigen; there are advantages to this and=20
practical use cases). It would incur nonsense semantics for operator()=20
on an array over a type with well-defined <span style=3D"font-family:courie=
r new,monospace">operator() ( std::size_t [, std::size_t =85 ] )</span>=97 =
but that's a corner case, and <span style=3D"font-family:courier new,monosp=
ace">array::operator()</span> isn't so far defined anyway. The interface an=
d implementation would be more lightweight.<br><br></div></blockquote><div>=
This <font face=3D"courier new,monospace">multi_array</font> would be like =
the <font face=3D"courier new,monospace">stack</font> and <font face=3D"cou=
rier new,monospace">queue</font> adaptors?</div></div></blockquote><div><br=
>No, an alias template =97 a metafunction which looks like a class template=
..<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 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"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">tem=
plate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> t</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">size_t next_extent</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"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">size_t </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 rem_extent </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> multi_array_h=
elper // metafunction<br>&nbsp; &nbsp; </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: #008;" class=3D"styled-by=
-prettify">typedef</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">array<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> multi_array_helper</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> t</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> rem_extent </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">type </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> type</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> t</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>size_t extent </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">struct<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> multi_arra=
y_helper</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> extent </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">typedef</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">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> extent </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> type</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><code class=3D"prettyprint"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> t</span><span style=3D"color: #660;" class=3D"styl=
ed-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">size_t =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> extent </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">using</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> multi_array </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> multi_array_helper</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> t</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> extent </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: #660;" class=3D"styled-by-prettify">&gt;::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">type</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"></span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> // alias template<br></span></code><=
/div></code></div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div>&nbsp; You can already make an <font face=3D"courier =
new,monospace">array</font> of a built-in array type, another <font face=3D=
"courier new,monospace">std::array</font>, or a custom array-like class typ=
e.&nbsp; But the point was to make something more integrated. <br></div></d=
iv></blockquote><div><br>"Separate"
 is the opposite of "integrated." The best-integrated solution is the=20
one which leverages existing facilities and avoids creating new types.<br><=
br>As I said, my proposal would support existing code using nested <span st=
yle=3D"font-family: courier new,monospace;">std::array&lt; std::array&lt; =
=85 &gt; &gt;</span> and other non-standard array types inside <span style=
=3D"font-family: courier new,monospace;">std::array</span>.<br>&nbsp;</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bor=
der-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:sol=
id"><div dir=3D"ltr">When was the last time n-adic <span style=3D"font-fami=
ly:courier new,monospace">operator[]</span>
 support was considered? Doesn't the potential use in the scientific=20
arena outweigh the need to support abuse of the comma operator inside=20
square brackets? C'mon, let's deprecate that syntactic sucker.<br><br></div=
></blockquote><div>I don't know why non-single parameters are&nbsp;banned f=
or operator[].&nbsp; But now C++11 has given us&nbsp;a single <font face=3D=
"courier new,monospace">std::initializer_list</font> parameter as a workaro=
und.&nbsp;</div></div></blockquote><div><br>Accepting different semantics t=
o get a syntactic workaround is a bad idea. The ban is for the reason I men=
tioned, comma operator abuse e.g. <span style=3D"font-family: courier new,m=
onospace;">x[y, z]</span>.<br></div></div>

<p></p>

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

------=_Part_798_21321706.1378600192983--

.

------=_Part_1265_26249738.1378672204293
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Saturday, September 7, 2013 8:29:52 PM UTC-4, David Krauss wrote:
>
>
> On Sunday, September 8, 2013 12:30:46 AM UTC+8, Daryle Walker wrote:
>>
>>
>> On Friday, September 6, 2013 9:58:30 PM UTC-4, David Krauss wrote:
>>>
>>> I think the initializer_list overloads may be unnecessary, and turn wha=
t=20
>>> should be a compile-time arity check to a runtime assertion on size(). =
They=20
>>> could help to support very high dimensionality, higher than the maximum=
=20
>>> supported number of function arguments, but I don't think most relevant=
=20
>>> platforms actually have such a limitation, and low dimensionality could=
 be=20
>>> penalized by adding the overhead of the pointers and "hard" stack=20
>>> allocation.
>>>
>>> The indexing operator (operator []) takes exactly one operand.  To work=
=20
>> around that, I made the variadic operator() member templates.  I even=20
>> made them return a sub-array when fewer arguments than dimensions were=
=20
>> given.  I made versions of at to match.  Then I read the Standard and=20
>> found out operator [] now supports multiple arguments indirectly through=
=20
>> the braced-init-list syntax.
>>
>
> What other class braced-init-lists which are required to be an exact size=
?=20
> Just because the core language makes something possible, doesn't make it =
a=20
> good idea.
> =20
>
None, as far as I know.  But the other braced-init-lists in the standard=20
are either aggregate initialization or constructor calls (especially=20
std::initializer_list, especially for the dynamic containers).  This would=
=20
be the first Standard type to use the operator []( std::initializer_list )f=
eature.
=20
The main reason for the fixed size is that std::initializer_list wasn't a=
=20
literal type in C++11, so I couldn't read the list's size at constexpr time=
=20
and remove the appropriate number of extents from the return type.  Since I=
=20
had to choose exactly one return type, I chose value_type and fixed input=
=20
list length.  C++14 makes std::initializer_list a literal type, but I can=
=20
only change the operator only if there's no way to make an initializer list=
=20
that can only be read at run-time.
=20
A class with an indexing operator with an initializer-list parameter that's=
=20
flexible as you suggest could be something like std::vector, except both=20
the number of extents and their values have to be dynamic.  You would have=
=20
to return objects of the same class since the selected subset would also be=
=20
flexible.  Unless all std::initializer_list objects are constexpr, type=20
and/or length fixing has to happen.
=20

> Compilers should make true array access faster than pointer arithmetic.
>>
>
> ???=20
>
> Given b[j] and c[j], where j is an integer value, b is an array, and c is=
=20
a pointer, the assembly instructions between the two differ and the array=
=20
access should be faster than the pointer version.
=20

> Another approach would be to make std::multi_array an alias template to a=
=20
>>> nested std::array type. The multidimensional accessor overloads could=
=20
>>> be added to one-dimensional std::array and delegate recursively to the=
=20
>>> underlying type. This would support existing code which nests std::arra=
y,=20
>>> or even other numeric libraries inside std::array (which I have done=20
>>> with Eigen; there are advantages to this and practical use cases). It w=
ould=20
>>> incur nonsense semantics for operator() on an array over a type with=20
>>> well-defined operator() ( std::size_t [, std::size_t =85 ] )=97 but tha=
t's=20
>>> a corner case, and array::operator() isn't so far defined anyway. The=
=20
>>> interface and implementation would be more lightweight.
>>>
>>> This multi_array would be like the stack and queue adaptors?
>>
>
> No, an alias template =97 a metafunction which looks like a class templat=
e.
>
> template< typename t, std::size_t next_extent, std::size_t ... rem_extent=
=20
> >
> struct multi_array_helper // metafunction
>     { typedef std::array< typename multi_array_helper< t, rem_extent ...=
=20
> >::type > type; };
>
> template< typename t, std::size_t extent >
> struct multi_array_helper< t, extent >
>     { typedef std::array< t, extent > type; };
>
> template< typename t, std::size_t ... extent >
> using multi_array =3D typename multi_array_helper< t, extent ... >::type;=
// alias template
> =20
>
>>   You can already make an array of a built-in array type, another=20
>> std::array, or a custom array-like class type.  But the point was to=20
>> make something more integrated.=20
>>
>
> "Separate" is the opposite of "integrated." The best-integrated solution=
=20
> is the one which leverages existing facilities and avoids creating new=20
> types.
>
> As I said, my proposal would support existing code using nested std::arra=
y<=20
> std::array< =85 > > and other non-standard array types inside std::array.
>
> I don't prefer nested smart-array approach.  It looks ugly, and if there'=
s=20
trailing padding in any instance, any higher-level instances will get=20
padding holes everywhere.  (You can also get it if there's heading=20
padding.  Heading padding can only occur if the element type is not=20
standard-layout.)  A key point of my example is that it's=20
backwards-compatible with C++11 std::array (when using one extent), so=20
you can still do nested smart-arrays if you want.
=20
Daryle W.
=20

--=20

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

------=_Part_1265_26249738.1378672204293
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Saturday, September 7, 2013 8:29:52 PM UTC-4, David=
 Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br>On Sunday, =
September 8, 2013 12:30:46 AM UTC+8, Daryle Walker wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr"><br>On Friday, September 6, 2013 9:58:30 PM UT=
C-4, David Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I
 think the initializer_list overloads may be unnecessary, and turn what=20
should be a compile-time arity check to a runtime assertion on size().=20
They could help to support very high dimensionality, higher than the=20
maximum supported number of function arguments, but I don't think most=20
relevant platforms actually have such a limitation, and low=20
dimensionality could be penalized by adding the overhead of the pointers
 and "hard" stack allocation.<br><br></div></blockquote><div>The indexing o=
perator (<font face=3D"courier new,monospace">operator []</font>) takes exa=
ctly one operand.&nbsp; To work around that, I made the variadic <font face=
=3D"courier new,monospace">operator()</font> member templates.&nbsp; I even=
 made them return a sub-array when fewer arguments than dimensions were giv=
en.&nbsp; I made versions of <font face=3D"courier new,monospace">at</font>=
 to match.&nbsp; Then I read the Standard and found out <font face=3D"couri=
er new,monospace">operator []</font> now supports multiple arguments indire=
ctly&nbsp;through the braced-init-list syntax.</div></div></blockquote><div=
><br>What
 other class braced-init-lists which are required to be an exact size?=20
Just because the core language makes something possible, doesn't make it
 a good idea.<br>&nbsp;</div></div></blockquote><div>None, as far as I know=
..&nbsp; But the other braced-init-lists in the standard are either aggregat=
e initialization or constructor calls (especially <font face=3D"courier new=
,monospace">std::initializer_list</font>, especially for the dynamic contai=
ners).&nbsp; This would be the first Standard type to use the <font face=3D=
"courier new,monospace">operator []( std::initializer_list )</font> feature=
..</div><div>&nbsp;</div><div>The main&nbsp;reason for the fixed size is tha=
t <font face=3D"courier new,monospace">std::initializer_list</font> wasn't =
a literal type in C++11, so I couldn't read the list's size at <font face=
=3D"courier new,monospace">constexpr</font> time and remove the appropriate=
 number of extents from the return type.&nbsp; Since I had to choose exactl=
y one return type, I chose <font face=3D"courier new,monospace">value_type<=
/font> and fixed input list length.&nbsp; C++14 makes <font face=3D"courier=
 new,monospace">std::initializer_list</font> a literal type, but I can only=
 change the operator only&nbsp;if there's no way to make an initializer lis=
t that can only be read at run-time.</div><div>&nbsp;</div><div>A class wit=
h an indexing operator with an initializer-list parameter that's flexible a=
s you suggest could be something like <font face=3D"courier new,monospace">=
std::vector</font>, except both the number of extents and their values have=
 to be dynamic.&nbsp; You would have to return objects of the same class si=
nce the selected subset would also be flexible.&nbsp; Unless all <font face=
=3D"courier new,monospace">std::initializer_list</font> objects are <font f=
ace=3D"courier new,monospace">constexpr</font>, type and/or length fixing h=
as to happen.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-w=
idth: 1px; border-left-style: solid;"><div dir=3D"ltr">Compilers should mak=
e true array access faster than pointer arithmetic.</div></blockquote><div>=
<br>??? <br><br></div></div></blockquote><div>Given <font face=3D"courier n=
ew,monospace">b[j]</font> and <font face=3D"courier new,monospace">c[j]</fo=
nt>, where <font face=3D"courier new,monospace">j</font> is an integer valu=
e, <font face=3D"courier new,monospace">b</font> is an array, and <font fac=
e=3D"courier new,monospace">c</font> is a pointer, the assembly instruction=
s between the two differ and the array access should be faster than the poi=
nter version.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-w=
idth: 1px; border-left-style: solid;"><div dir=3D"ltr"><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border=
-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style:=
 solid;"><div dir=3D"ltr">Another approach would be to make <span style=3D"=
font-family: courier new,monospace;">std::multi_array</span> an alias templ=
ate to a nested <span style=3D"font-family: courier new,monospace;">std::ar=
ray</span> type. The multidimensional accessor overloads could be added to =
one-dimensional <span style=3D"font-family: courier new,monospace;">std::ar=
ray</span> and delegate recursively to the underlying type. This would supp=
ort existing code which nests <span style=3D"font-family: courier new,monos=
pace;">std::array</span>, or even other numeric libraries inside <span styl=
e=3D"font-family: courier new,monospace;">std::array</span>
 (which I have done with Eigen; there are advantages to this and=20
practical use cases). It would incur nonsense semantics for operator()=20
on an array over a type with well-defined <span style=3D"font-family: couri=
er new,monospace;">operator() ( std::size_t [, std::size_t =85 ] )</span>=
=97 but that's a corner case, and <span style=3D"font-family: courier new,m=
onospace;">array::operator()</span> isn't so far defined anyway. The interf=
ace and implementation would be more lightweight.<br><br></div></blockquote=
><div>This <font face=3D"courier new,monospace">multi_array</font> would be=
 like the <font face=3D"courier new,monospace">stack</font> and <font face=
=3D"courier new,monospace">queue</font> adaptors?</div></div></blockquote><=
div><br>No, an alias template =97 a metafunction which looks like a class t=
emplate.<br><br><div style=3D"border: 1px solid rgb(187, 187, 187); word-wr=
ap: break-word; background-color: rgb(250, 250, 250);"><code><div><span sty=
le=3D"color: rgb(0, 0, 136);">template</span><span style=3D"color: rgb(102,=
 102, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 0);"> </span><span st=
yle=3D"color: rgb(0, 0, 136);">typename</span><span style=3D"color: rgb(0, =
0, 0);"> t</span><span style=3D"color: rgb(102, 102, 0);">,</span><span sty=
le=3D"color: rgb(0, 0, 0);"> std</span><span style=3D"color: rgb(102, 102, =
0);">::</span><span style=3D"color: rgb(0, 0, 0);">size_t next_extent</span=
><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rgb=
(0, 0, 0);"> std</span><span style=3D"color: rgb(102, 102, 0);">::</span><s=
pan style=3D"color: rgb(0, 0, 0);">size_t </span><span style=3D"color: rgb(=
102, 102, 0);">...</span><span style=3D"color: rgb(0, 0, 0);"> rem_extent <=
/span><span style=3D"color: rgb(102, 102, 0);">&gt;</span><span style=3D"co=
lor: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(0, 0, 136);">struc=
t</span><span style=3D"color: rgb(0, 0, 0);"> multi_array_helper // metafun=
ction<br>&nbsp; &nbsp; </span><span style=3D"color: rgb(102, 102, 0);">{</s=
pan><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(=
0, 0, 136);">typedef</span><span style=3D"color: rgb(0, 0, 0);"> std</span>=
<span style=3D"color: rgb(102, 102, 0);">::</span><span style=3D"color: rgb=
(0, 0, 0);">array</span><span style=3D"color: rgb(102, 102, 0);">&lt;</span=
><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, =
0, 136);">typename</span><span style=3D"color: rgb(0, 0, 0);"> multi_array_=
helper</span><span style=3D"color: rgb(102, 102, 0);">&lt;</span><span styl=
e=3D"color: rgb(0, 0, 0);"> t</span><span style=3D"color: rgb(102, 102, 0);=
">,</span><span style=3D"color: rgb(0, 0, 0);"> rem_extent </span><span sty=
le=3D"color: rgb(102, 102, 0);">...</span><span style=3D"color: rgb(0, 0, 0=
);"> </span><span style=3D"color: rgb(102, 102, 0);">&gt;::</span><span sty=
le=3D"color: rgb(0, 0, 0);">type </span><span style=3D"color: rgb(102, 102,=
 0);">&gt;</span><span style=3D"color: rgb(0, 0, 0);"> type</span><span sty=
le=3D"color: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);=
"> </span><span style=3D"color: rgb(102, 102, 0);">};</span><span style=3D"=
color: rgb(0, 0, 0);"><br><br></span><span style=3D"color: rgb(0, 0, 136);"=
>template</span><span style=3D"color: rgb(102, 102, 0);">&lt;</span><span s=
tyle=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);=
">typename</span><span style=3D"color: rgb(0, 0, 0);"> t</span><span style=
=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);">=
 std</span><span style=3D"color: rgb(102, 102, 0);">::</span><span style=3D=
"color: rgb(0, 0, 0);">size_t extent </span><span style=3D"color: rgb(102, =
102, 0);">&gt;</span><span style=3D"color: rgb(0, 0, 0);"><br></span><span =
style=3D"color: rgb(0, 0, 136);">struct</span><span style=3D"color: rgb(0, =
0, 0);"> multi_array_helper</span><span style=3D"color: rgb(102, 102, 0);">=
&lt;</span><span style=3D"color: rgb(0, 0, 0);"> t</span><span style=3D"col=
or: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);"> extent=
 </span><span style=3D"color: rgb(102, 102, 0);">&gt;</span><span style=3D"=
color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; </span><span style=3D"color: rgb(10=
2, 102, 0);">{</span><span style=3D"color: rgb(0, 0, 0);"> </span><span sty=
le=3D"color: rgb(0, 0, 136);">typedef</span><span style=3D"color: rgb(0, 0,=
 0);"> std</span><span style=3D"color: rgb(102, 102, 0);">::</span><span st=
yle=3D"color: rgb(0, 0, 0);">array</span><span style=3D"color: rgb(102, 102=
, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 0);"> t</span><span style=
=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);">=
 extent </span><span style=3D"color: rgb(102, 102, 0);">&gt;</span><span st=
yle=3D"color: rgb(0, 0, 0);"> type</span><span style=3D"color: rgb(102, 102=
, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"=
color: rgb(102, 102, 0);">};</span><span style=3D"color: rgb(0, 0, 0);"><br=
></span><span style=3D"color: rgb(0, 0, 0);"><br></span><code><span style=
=3D"color: rgb(0, 0, 136);">template</span><span style=3D"color: rgb(102, 1=
02, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 0);"> </span><span styl=
e=3D"color: rgb(0, 0, 136);">typename</span><span style=3D"color: rgb(0, 0,=
 0);"> t</span><span style=3D"color: rgb(102, 102, 0);">,</span><span style=
=3D"color: rgb(0, 0, 0);"> std</span><span style=3D"color: rgb(102, 102, 0)=
;">::</span><span style=3D"color: rgb(0, 0, 0);">size_t </span><span style=
=3D"color: rgb(102, 102, 0);">...</span><span style=3D"color: rgb(0, 0, 0);=
"> extent </span><span style=3D"color: rgb(102, 102, 0);">&gt;</span><span =
style=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(0, 0, 1=
36);">using</span><span style=3D"color: rgb(0, 0, 0);"> multi_array </span>=
<span style=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"color: rg=
b(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">typename</span>=
<span style=3D"color: rgb(0, 0, 0);"> multi_array_helper</span><span style=
=3D"color: rgb(102, 102, 0);">&lt;</span><span style=3D"color: rgb(0, 0, 0)=
;"> t</span><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D=
"color: rgb(0, 0, 0);"> extent </span><span style=3D"color: rgb(102, 102, 0=
);">...</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"c=
olor: rgb(102, 102, 0);">&gt;::</span><span style=3D"color: rgb(0, 0, 0);">=
type</span><span style=3D"color: rgb(102, 102, 0);">;</span><span style=3D"=
color: rgb(0, 0, 0);"></span><span style=3D"color: rgb(0, 0, 0);"> // alias=
 template<br></span></code></div></code></div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr"><div>&nbsp; You can already make an <font face=
=3D"courier new,monospace">array</font> of a built-in array type, another <=
font face=3D"courier new,monospace">std::array</font>, or a custom array-li=
ke class type.&nbsp; But the point was to make something more integrated. <=
br></div></div></blockquote><div><br>"Separate"
 is the opposite of "integrated." The best-integrated solution is the=20
one which leverages existing facilities and avoids creating new types.<br><=
br>As I said, my proposal would support existing code using nested <span st=
yle=3D"font-family: courier new,monospace;">std::array&lt; std::array&lt; =
=85 &gt; &gt;</span> and other non-standard array types inside <span style=
=3D"font-family: courier new,monospace;">std::array</span>.<br><br></div></=
div></blockquote><div>I don't prefer nested smart-array approach.&nbsp; It =
looks ugly, and&nbsp;if there's trailing padding in any instance, any&nbsp;=
higher-level instances will get padding&nbsp;holes everywhere.&nbsp; (You&n=
bsp;can also get it if there's&nbsp;heading padding.&nbsp; Heading padding =
can only occur if the element type is not standard-layout.)&nbsp; A key poi=
nt of my example is that it's backwards-compatible with C++11 std::array (w=
hen using one extent), so you&nbsp;can still do nested smart-arrays if you =
want.</div><div>&nbsp;</div><div>Daryle W.</div><div>&nbsp;</div></div>

<p></p>

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

------=_Part_1265_26249738.1378672204293--

.

------=_Part_225_18490997.1378686904482
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Monday, September 9, 2013 4:30:04 AM UTC+8, Daryle Walker wrote:
>
> None, as far as I know.  But the other braced-init-lists in the standard=
=20
> are either aggregate initialization or constructor calls (especially=20
> std::initializer_list, especially for the dynamic containers).  This=20
> would be the first Standard type to use the operator [](=20
> std::initializer_list ) feature.
>

Ah, right =97 that leads to the correct implementation of the subscript=20
interface,

operator [] ( std::array< std::size_t, sizeof ... (extents) > )

This can also be initialized by a braced-init-list. The remaining downside=
=20
is that if the list is too short, it will be padded out with zeroes and you=
=20
can't diagnose the condition. So, I still don't think it's a good idea.
=20

> A class with an indexing operator with an initializer-list parameter=20
> that's flexible as you suggest could be something like std::vector,
>

I did not suggest to use a flexible parameter. I suggested that you not do=
=20
so.
=20

>  Given b[j] and c[j], where j is an integer value, b is an array, and cis=
 a pointer, the assembly instructions between the two differ and the=20
> array access should be faster than the pointer version.
>

Not all arrays are created equal; a std::array argument is more likely to=
=20
be promoted to registers than the underlying array of std::initializer_list=
,=20
whose begin member provides pointer-semantic access to an array. So it=20
seems that you're on the wrong side of your own argument=85
=20

>  I don't prefer nested smart-array approach.  It looks ugly,
>

It looks the same from the user's perspective, for well-formed code, except=
=20
that there are no new types, just new functionality for existing types.
=20

> and if there's trailing padding in any instance, any higher-level=20
> instances will get padding holes everywhere.
>

Huh? Access would be delegated through the successive inner types, which=20
need not even represent flat arrays.

--=20

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

------=_Part_225_18490997.1378686904482
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Monday, September 9, 2013 4:30:04 AM UTC+8, Dar=
yle Walker wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">None, as far as I know.&nbsp; But the other braced-init-lists in the st=
andard are either aggregate initialization or constructor calls (especially=
 <font face=3D"courier new,monospace">std::initializer_list</font>, especia=
lly for the dynamic containers).&nbsp; This would be the first Standard typ=
e to use the <font face=3D"courier new,monospace">operator []( std::initial=
izer_list )</font> feature.</div></blockquote><div><br>Ah, right =97 that l=
eads to the correct implementation of the subscript interface,<br><br><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">operator</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[]</span><span style=3D"colo=
r: #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"> 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">array</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&lt;</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"styled-by-prettify">size_t</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: #=
008;" class=3D"styled-by-prettify">sizeof</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"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">e=
xtents</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</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"><br></span></div></code></div><br>This can als=
o be initialized by a braced-init-list. The remaining downside is that if t=
he list is too short, it will be padded out with zeroes and you can't diagn=
ose the condition. So, I still don't think it's a good idea.<br>&nbsp;</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">A class with=
 an indexing operator with an initializer-list parameter that's flexible as=
 you suggest could be something like <font face=3D"courier new,monospace">s=
td::vector</font>,</div></blockquote><div><br>I did not suggest to use a fl=
exible parameter. I suggested that you not do so.<br>&nbsp;</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>&nbsp;Given <font =
face=3D"courier new,monospace">b[j]</font> and <font face=3D"courier new,mo=
nospace">c[j]</font>, where <font face=3D"courier new,monospace">j</font> i=
s an integer value, <font face=3D"courier new,monospace">b</font> is an arr=
ay, and <font face=3D"courier new,monospace">c</font> is a pointer, the ass=
embly instructions between the two differ and the array access should be fa=
ster than the pointer version.</div></div></blockquote><div><br>Not all arr=
ays are created equal; a <span style=3D"font-family: courier new,monospace;=
">std::array</span> argument is more likely to be promoted to registers tha=
n the underlying array of <span style=3D"font-family: courier new,monospace=
;">std::initializer_list</span>, whose <span style=3D"font-family: courier =
new,monospace;">begin</span> member provides pointer-semantic access to an =
array. So it seems that you're on the wrong side of your own argument=85<br=
>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>&nbsp;I don't prefer nested smart-array approach.&nbsp; It looks ugly,=
</div></div></blockquote><div><br>It looks the same from the user's perspec=
tive, for well-formed code, except that there are no new types, just new fu=
nctionality for existing types.<br>&nbsp;<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div> and&nbsp;if there's trailing pa=
dding in any instance, any&nbsp;higher-level instances will get padding&nbs=
p;holes everywhere.</div></div></blockquote><div><br>Huh? Access would be d=
elegated through the successive inner types, which need not even represent =
flat arrays.</div></div>

<p></p>

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

------=_Part_225_18490997.1378686904482--

.

------=_Part_63_1904876.1378936465116
Content-Type: text/plain; charset=ISO-8859-1

On Friday, September 6, 2013 8:17:12 PM UTC-4, Daryle Walker wrote:
>
> As an exercise in using variadic templates, I chose a multi-dimensional
> variant of std::array.  I eventually made the interface match std::array
> when the number of extents given is one.  When wondering if I should put
> the class template up for consideration, I realized that it would be so
> close to std::array, that I shouldn't propose my class directly for the
> Standard Library, but propose a change to std::array instead.
>
> I just put it up at https://github.com/CTMacUser/multiarray-iso-proposal,for requesting comments before officially proposing it.  (I should switch
> to HTML or some other rich-text system for the next draft....)
>

I uploaded another draft earlier today.  Now it's in HTML.  I've added a
make_array function template and an (explicit) conversion operator.  I'll
probably make it an official proposal soon.

Daryle W.


--

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

------=_Part_63_1904876.1378936465116
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, September 6, 2013 8:17:12 PM UTC-4, Daryle Walk=
er wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-w=
idth: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>As an exercise =
in using variadic templates, I chose a multi-dimensional variant of std::ar=
ray.&nbsp; I eventually made the interface match std::array when the number=
 of extents given is one.&nbsp; When wondering if I should put the class te=
mplate up for consideration, I realized that it would be so close to std::a=
rray, that I shouldn't propose my class directly for the Standard Library, =
but propose a change to std::array instead.</div><div>&nbsp;</div><div>I ju=
st put it up at <a href=3D"https://github.com/CTMacUser/multiarray-iso-prop=
osal," target=3D"_blank">https://github.com/CTMacUser/<wbr>multiarray-iso-p=
roposal,</a> for requesting comments before officially proposing it.&nbsp; =
(I should switch to HTML or some other rich-text system for the next draft.=
....)&nbsp;</div></div></blockquote><div>&nbsp;</div><div>I uploaded another=
 draft earlier today.&nbsp; Now it's in&nbsp;HTML.&nbsp; I've added a <font=
 face=3D"courier new,monospace">make_array</font> function template and an =
(explicit) conversion operator.&nbsp; I'll probably make it an official pro=
posal soon.</div><div>&nbsp;</div><div>Daryle W.</div><div>&nbsp;</div></di=
v>

<p></p>

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

------=_Part_63_1904876.1378936465116--

.

------=_Part_44_18038919.1378944308307
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Thursday, September 12, 2013 5:54:24 AM UTC+8, Daryle Walker wrote:
>
> On Friday, September 6, 2013 8:17:12 PM UTC-4, Daryle Walker wrote:
>>
>> As an exercise in using variadic templates, I chose a multi-dimensional=
=20
>> variant of std::array.  I eventually made the interface match std::array=
=20
>> when the number of extents given is one.  When wondering if I should put=
=20
>> the class template up for consideration, I realized that it would be so=
=20
>> close to std::array, that I shouldn't propose my class directly for the=
=20
>> Standard Library, but propose a change to std::array instead.
>> =20
>> I just put it up at https://github.com/CTMacUser/multiarray-iso-proposal=
,
>>
>
Please avoid putting the comma after a non-linked URL on this board, and=20
please provide a link to the actual file. The best I can find is this link<=
https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/array-propo=
sal.html>which provides incorrect MIME so the browser doesn't render anythi=
ng, but=20
displays HTML source.

How much testing and research has gone into this? (Has it actually been=20
used by people in a real project? How much have you used it?)=20
Boost.Multiarray isn't even mentioned. Is submission as an international=20
standard really the next step for this library?

I can't really read it, but only looking at make_array,

   1. The common_type makes it too easy to accidentally get the wrong type=
=20
   of array. Besides numeric cases, a base-class argument would incur slici=
ng=20
   derived-class arguments.
   2. Separate T parameter does not seem to serve a purpose, except perhaps=
=20
   to prevent a signature that would instantiate ill-defined=20
   std::common_type<>, but that doesn't seem a likely reason. The solution=
=20
   to that problem would be a requires clause.
   3. This does not conceptually belong to a "multiarray" library. It is a=
=20
   utility for creating a one-dimensional array. (Although it does evaluate=
=20
   the array_t metafunction, it is a pointless exercise as the arguments=20
   seem to map directly to std::array<T,N>. Although I can't see where=20
   std::array<=85>::type is defined at all. Using a valid object type as a=
=20
   metafunction is sure to be controversial, if that's really what this is=
=20
   doing, but I'll wait until I can read the proposal without straining.)
  =20

--=20

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

------=_Part_44_18038919.1378944308307
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, September 12, 2013 5:54:24 AM UTC+8, =
Daryle Walker wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Friday, September 6, 2013 8:17:12 PM UTC-4, Daryle Walker wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid"><div dir=3D"ltr"><div>As an exercise in using variadic te=
mplates, I chose a multi-dimensional variant of std::array.&nbsp; I eventua=
lly made the interface match std::array when the number of extents given is=
 one.&nbsp; When wondering if I should put the class template up for consid=
eration, I realized that it would be so close to std::array, that I shouldn=
't propose my class directly for the Standard Library, but propose a change=
 to std::array instead.</div><div>&nbsp;</div><div>I just put it up at <a h=
ref=3D"https://github.com/CTMacUser/multiarray-iso-proposal," target=3D"_bl=
ank">https://github.com/CTMacUser/<wbr>multiarray-iso-proposal,</a></div></=
div></blockquote></div></blockquote><div><br>Please avoid putting the comma=
 after a non-linked URL on this board, and please provide a link to the act=
ual file. The best I can find is <a href=3D"https://raw.github.com/CTMacUse=
r/multiarray-iso-proposal/master/array-proposal.html">this link</a> which p=
rovides incorrect MIME so the browser doesn't render anything, but displays=
 HTML source.<br><br>How much testing and research has gone into this? (Has=
 it actually been used by people in a real project? How much have you used =
it?) Boost.Multiarray isn't even mentioned. Is submission as an internation=
al standard really the next step for this library?<br><br>I can't really re=
ad it, but only looking at <span style=3D"font-family: courier new,monospac=
e;">make_array</span>,<br><ol><li>The <span style=3D"font-family: courier n=
ew,monospace;">common_type</span> makes it too easy to accidentally get the=
 wrong type of array. Besides numeric cases, a base-class argument would in=
cur slicing derived-class arguments.</li><li>Separate <span style=3D"font-f=
amily: courier new,monospace;">T</span> parameter does not seem to serve a =
purpose, except perhaps to prevent a signature that would instantiate ill-d=
efined <span style=3D"font-family: courier new,monospace;">std::common_type=
&lt;&gt;</span>, but that doesn't seem a likely reason. The solution to tha=
t problem would be a requires clause.<br></li><li>This does not conceptuall=
y belong to a "multiarray" library. It is a utility for creating a one-dime=
nsional array. (Although it does evaluate the <span style=3D"font-family: c=
ourier new,monospace;">array_t</span> metafunction, it is a pointless exerc=
ise as the arguments seem to map directly to <span style=3D"font-family: co=
urier new,monospace;">std::array&lt;T,N&gt;</span>. Although I can't see wh=
ere <span style=3D"font-family: courier new,monospace;">std::array&lt;=85&g=
t;::type</span> is defined at all. Using a valid object type as a metafunct=
ion is sure to be controversial, if that's really what this is doing, but I=
'll wait until I can read the proposal without straining.)<br></li></ol></d=
iv></div>

<p></p>

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

------=_Part_44_18038919.1378944308307--

.

--047d7b6dc2245b200504e624d829
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 11, 2013 at 5:05 PM, David Krauss <potswa@gmail.com> wrote:

>
>
> On Thursday, September 12, 2013 5:54:24 AM UTC+8, Daryle Walker wrote:
>>
>> On Friday, September 6, 2013 8:17:12 PM UTC-4, Daryle Walker wrote:
>>>
>>> As an exercise in using variadic templates, I chose a multi-dimensional
>>> variant of std::array.  I eventually made the interface match std::arra=
y
>>> when the number of extents given is one.  When wondering if I should pu=
t
>>> the class template up for consideration, I realized that it would be so
>>> close to std::array, that I shouldn't propose my class directly for the
>>> Standard Library, but propose a change to std::array instead.
>>>
>>> I just put it up at https://github.com/CTMacUser/**
>>> multiarray-iso-proposal,<https://github.com/CTMacUser/multiarray-iso-pr=
oposal,>
>>>
>>
> Please avoid putting the comma after a non-linked URL on this board, and
> please provide a link to the actual file. The best I can find is this lin=
k<https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/array-pro=
posal.html>which provides incorrect MIME so the browser doesn't render anyt=
hing, but
> displays HTML source.
>

http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarray-i=
so-proposal/master/array-proposal.html


> How much testing and research has gone into this? (Has it actually been
> used by people in a real project? How much have you used it?)
> Boost.Multiarray isn't even mentioned. Is submission as an international
> standard really the next step for this library?
>
> I can't really read it, but only looking at make_array,
>
>    1. The common_type makes it too easy to accidentally get the wrong
>    type of array. Besides numeric cases, a base-class argument would incu=
r
>    slicing derived-class arguments.
>    2. Separate T parameter does not seem to serve a purpose, except
>    perhaps to prevent a signature that would instantiate ill-defined
>    std::common_type<>, but that doesn't seem a likely reason. The
>    solution to that problem would be a requires clause.
>    3. This does not conceptually belong to a "multiarray" library. It is
>    a utility for creating a one-dimensional array. (Although it does eval=
uate
>    the array_t metafunction, it is a pointless exercise as the arguments
>    seem to map directly to std::array<T,N>. Although I can't see where
>    std::array<=85>::type is defined at all. Using a valid object type as =
a
>    metafunction is sure to be controversial, if that's really what this i=
s
>    doing, but I'll wait until I can read the proposal without straining.)
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

--047d7b6dc2245b200504e624d829
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Sep 11, 2013 at 5:05 PM, David Krauss <span dir=3D=
"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmai=
l.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote">
<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;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><br><br>On Thursday, Se=
ptember 12, 2013 5:54:24 AM UTC+8, Daryle Walker wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr">On Friday, September 6, 2013 8:17:12 PM UTC-4, Daryle Walk=
er wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid">
<div dir=3D"ltr"><div>As an exercise in using variadic templates, I chose a=
 multi-dimensional variant of std::array.=A0 I eventually made the interfac=
e match std::array when the number of extents given is one.=A0 When wonderi=
ng if I should put the class template up for consideration, I realized that=
 it would be so close to std::array, that I shouldn&#39;t propose my class =
directly for the Standard Library, but propose a change to std::array inste=
ad.</div>
<div>=A0</div><div>I just put it up at <a href=3D"https://github.com/CTMacU=
ser/multiarray-iso-proposal," target=3D"_blank">https://github.com/CTMacUse=
r/<u></u>multiarray-iso-proposal,</a></div></div></blockquote></div></block=
quote>
</div><div><br>Please avoid putting the comma after a non-linked URL on thi=
s board, and please provide a link to the actual file. The best I can find =
is <a href=3D"https://raw.github.com/CTMacUser/multiarray-iso-proposal/mast=
er/array-proposal.html" target=3D"_blank">this link</a> which provides inco=
rrect MIME so the browser doesn&#39;t render anything, but displays HTML so=
urce.<br>
</div></div></blockquote><div><br></div><div><a href=3D"http://htmlpreview.=
github.io/?https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/=
array-proposal.html">http://htmlpreview.github.io/?https://raw.github.com/C=
TMacUser/multiarray-iso-proposal/master/array-proposal.html</a><br>
</div><div>=A0</div><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);borde=
r-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>How much testing=
 and research has gone into this? (Has it actually been used by people in a=
 real project? How much have you used it?) Boost.Multiarray isn&#39;t even =
mentioned. Is submission as an international standard really the next step =
for this library?<br>
<br>I can&#39;t really read it, but only looking at <span style=3D"font-fam=
ily:&#39;courier new&#39;,monospace">make_array</span>,<br><ol><li>The <spa=
n style=3D"font-family:&#39;courier new&#39;,monospace">common_type</span> =
makes it too easy to accidentally get the wrong type of array. Besides nume=
ric cases, a base-class argument would incur slicing derived-class argument=
s.</li>
<li>Separate <span style=3D"font-family:&#39;courier new&#39;,monospace">T<=
/span> parameter does not seem to serve a purpose, except perhaps to preven=
t a signature that would instantiate ill-defined <span style=3D"font-family=
:&#39;courier new&#39;,monospace">std::common_type&lt;&gt;</span>, but that=
 doesn&#39;t seem a likely reason. The solution to that problem would be a =
requires clause.<br>
</li><li>This does not conceptually belong to a &quot;multiarray&quot; libr=
ary. It is a utility for creating a one-dimensional array. (Although it doe=
s evaluate the <span style=3D"font-family:&#39;courier new&#39;,monospace">=
array_t</span> metafunction, it is a pointless exercise as the arguments se=
em to map directly to <span style=3D"font-family:&#39;courier new&#39;,mono=
space">std::array&lt;T,N&gt;</span>. Although I can&#39;t see where <span s=
tyle=3D"font-family:&#39;courier new&#39;,monospace">std::array&lt;=85&gt;:=
:type</span> is defined at all. Using a valid object type as a metafunction=
 is sure to be controversial, if that&#39;s really what this is doing, but =
I&#39;ll wait until I can read the proposal without straining.)<br>
</li></ol></div></div><div class=3D""><div class=3D"h5">

<p></p>

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

<p></p>

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

--047d7b6dc2245b200504e624d829--

.

------=_Part_953_30847448.1379006164492
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wednesday, September 11, 2013 8:05:08 PM UTC-4, David Krauss wrote:
>
> On Thursday, September 12, 2013 5:54:24 AM UTC+8, Daryle Walker wrote:
>>
>> On Friday, September 6, 2013 8:17:12 PM UTC-4, Daryle Walker wrote:
>>>
>>> As an exercise in using variadic templates, I chose a multi-dimensional=
=20
>>> variant of std::array.  I eventually made the interface match std::arra=
y=20
>>> when the number of extents given is one.  When wondering if I should pu=
t=20
>>> the class template up for consideration, I realized that it would be so=
=20
>>> close to std::array, that I shouldn't propose my class directly for the=
=20
>>> Standard Library, but propose a change to std::array instead.
>>> =20
>>> I just put it up at=20
>>> https://github.com/CTMacUser/multiarray-iso-proposal,
>>>
>>
> Please avoid putting the comma after a non-linked URL on this board, and=
=20
> please provide a link to the actual file. The best I can find is this lin=
k<https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/array-pro=
posal.html>which provides incorrect MIME so the browser doesn't render anyt=
hing, but=20
> displays HTML source.
>
=20
AFAIK, GitHub never instantiates rich formats.  Binary files are shown as a=
=20
blob flag and text-based files (like HTML) are shown their raw text source.
=20
Like Richard Smith said, you can go to http://htmlpreview.github.io/ and=20
feed its form the URL of a HTML-based GitHub file for test viewing.  I=20
didn't know that either; I just previewed with my PC's browser's local=20
mode.  I think GitHub added a web-page service; I'll see if I can use that.
=20

> How much testing and research has gone into this? (Has it actually been=
=20
> used by people in a real project? How much have you used it?)=20
> Boost.Multiarray isn't even mentioned. Is submission as an international=
=20
> standard really the next step for this library?
>
=20
As I said earlier, I came up with this idea a few months ago as an=20
exercise.  AFAIK, it's only been used in my unit test program for it.  But=
=20
I don't think there's any experience requirement; as long as a proposal is=
=20
submitted, a library with a decade of in-field hard testing and a library=
=20
from a five-minute as^H^Hhead-pull are equivalent.  Since this library=20
isn't trying to bring new innovations in (C++) programming, simple=20
inspection is still useful.
=20
I haven't mentioned Boost.Multiarray since it's dynamic-memory based.
=20

> I can't really read it, but only looking at make_array,
>
>    1. The common_type makes it too easy to accidentally get the wrong=20
>    type of array. Besides numeric cases, a base-class argument would incu=
r=20
>    slicing derived-class arguments.
>
> The expected use cases would have the same type for all of arguments; I=
=20
used common_type to automate the process.  As said with other libraries, if=
=20
you use a set of arguments that'll break when used together, it's your own=
=20
fault.  What alternative would you suggest for your example?  You can=20
always manually cast each argument to your chosen element type.  There's no=
=20
common_except_when_it_will_break_stuff_type template.

>
>    1. Separate T parameter does not seem to serve a purpose, except=20
>    perhaps to prevent a signature that would instantiate ill-defined=20
>    std::common_type<>, but that doesn't seem a likely reason. The=20
>    solution to that problem would be a requires clause.
>
> The purpose of a separate first parameter is to enforce that make_arrayis=
 passed at least one argument.  (If zero-arguments were allowed, what=20
would the element type be?  How could I determine it?)  I guess a *Requires=
*clause could work.  The declaration of common_type=20
in the Standard is only a type parameter pack, although its definition=20
precludes zero-size type lists.  (Maybe I'll try making my test make_arrayu=
se only a general type pack, and if it chokes with zero parameters, maybe=
=20
that'll be sufficient.)

>
>    1. This does not conceptually belong to a "multiarray" library. It is=
=20
>    a utility for creating a one-dimensional array. (Although it does eval=
uate=20
>    the array_t metafunction, it is a pointless exercise as the arguments=
=20
>    seem to map directly to std::array<T,N>. Although I can't see where=20
>    std::array<=85>::type is defined at all. Using a valid object type as =
a=20
>    metafunction is sure to be controversial, if that's really what this i=
s=20
>    doing, but I'll wait until I can read the proposal without straining.)
>
> Single-dimension arrays are a subset of multi-dimensional ones, especiall=
y=20
since I'm modifying the existing single-dimension std::array instead of=20
making a new class template.  Should it be a separate proposal?  Use of=20
array_t as the return type of make_array was a mistake; I've uploaded=20
corrected versions that use array.  (The array_t alias can't be used, since=
=20
it resolves to a built-in array type, which can't be used as return types.)
=20
The new array uses the standard variadic recursion shtick in my sample=20
implementation.  That means each instantiation carries around a type-alias=
=20
to whatever built-in array type it uses for its data.  My sample library=20
uses "array_type" as the name.  A trait for getting a built-in array type=
=20
given an element type an a list of extents should be a separate class=20
template, but the best name is already being used!  Since I need that=20
type-alias around anyway, why not pull double-duty and use "type" in the=20
Standard version?
=20
Daryle W.
=20

--=20

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

------=_Part_953_30847448.1379006164492
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, September 11, 2013 8:05:08 PM UTC-4, David K=
rauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Thursday, Sept=
ember 12, 2013 5:54:24 AM UTC+8, Daryle Walker wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;"><div dir=3D"ltr">On Friday, September 6, 2013 8:17:12 PM UTC-4, Dary=
le Walker wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>As an ex=
ercise in using variadic templates, I chose a multi-dimensional variant of =
std::array.&nbsp; I eventually made the interface match std::array when the=
 number of extents given is one.&nbsp; When wondering if I should put the c=
lass template up for consideration, I realized that it would be so close to=
 std::array, that I shouldn't propose my class directly for the Standard Li=
brary, but propose a change to std::array instead.</div><div>&nbsp;</div><d=
iv>I just put it up at <a href=3D"https://github.com/CTMacUser/multiarray-i=
so-proposal," target=3D"_blank">https://github.com/CTMacUser/<wbr>multiarra=
y-iso-proposal,</a></div></div></blockquote></div></blockquote><div><br>Ple=
ase avoid putting the comma after a non-linked URL on this board, and pleas=
e provide a link to the actual file. The best I can find is <a href=3D"http=
s://raw.github.com/CTMacUser/multiarray-iso-proposal/master/array-proposal.=
html" target=3D"_blank">this link</a> which provides incorrect MIME so the =
browser doesn't render anything, but displays HTML source.</div></div></blo=
ckquote><div>&nbsp;</div><div>AFAIK, GitHub never instantiates rich formats=
..&nbsp; Binary files are shown as a blob flag and text-based files (like HT=
ML) are shown their raw text source.</div><div>&nbsp;</div><div>Like Richar=
d Smith said, you can go to <a href=3D"http://htmlpreview.github.io/">http:=
//htmlpreview.github.io/</a> and feed its form the URL of a HTML-based GitH=
ub file for test viewing.&nbsp; I didn't know that either; I just previewed=
 with my PC's browser's local mode.&nbsp; I think GitHub added a web-page s=
ervice; I'll see if I can use that.</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr"><div>How much testing and research has gone in=
to this? (Has it actually been used by people in a real project? How much h=
ave you used it?) Boost.Multiarray isn't even mentioned. Is submission as a=
n international standard really the next step for this library?</div></div>=
</blockquote><div>&nbsp;</div><div>As I said earlier, I came up with this i=
dea a few months ago as an exercise.&nbsp; AFAIK, it's only been used in my=
 unit test program for it.&nbsp; But I don't think there's any experience r=
equirement; as long as a proposal is submitted, a library with a decade of =
in-field hard testing and a library from a five-minute as^H^Hhead-pull are =
equivalent.&nbsp; Since this library isn't trying to bring new innovations =
in (C++) programming, simple inspection is still useful.</div><div>&nbsp;</=
div><div>I haven't mentioned Boost.Multiarray since it's dynamic-memory bas=
ed.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><di=
v>I can't really read it, but only looking at <span style=3D"font-family: c=
ourier new,monospace;">make_array</span>,<br><ol><li>The <span style=3D"fon=
t-family: courier new,monospace;">common_type</span> makes it too easy to a=
ccidentally get the wrong type of array. Besides numeric cases, a base-clas=
s argument would incur slicing derived-class arguments.</li></ol></div></di=
v></blockquote><div>The&nbsp;expected use cases would&nbsp;have the same ty=
pe for all of arguments; I used <font face=3D"courier new,monospace">common=
_type</font> to automate the process.&nbsp; As said with other libraries, i=
f you use a set of arguments that'll break when used together, it's your ow=
n fault.&nbsp; What alternative would you suggest for your example?&nbsp; Y=
ou can always manually cast each argument to your chosen element type.&nbsp=
; There's no <font face=3D"courier new,monospace">common_except_when_it_wil=
l_break_stuff_type</font> template.</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: r=
gb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div =
dir=3D"ltr"><div><ol><li>Separate <span style=3D"font-family: courier new,m=
onospace;">T</span> parameter does not seem to serve a purpose, except perh=
aps to prevent a signature that would instantiate ill-defined <span style=
=3D"font-family: courier new,monospace;">std::common_type&lt;&gt;</span>, b=
ut that doesn't seem a likely reason. The solution to that problem would be=
 a requires clause.</li></ol></div></div></blockquote><div>The purpose of a=
 separate first parameter is to enforce that <font face=3D"courier new,mono=
space">make_array</font> is passed at least one argument.&nbsp; (If zero-ar=
guments were allowed, what would the element type be?&nbsp; How could I det=
ermine it?)&nbsp; I guess a <em>Requires</em> clause could work.&nbsp; The =
declaration of <font face=3D"courier new,monospace">common_type </font>in t=
he Standard is only a type parameter pack, although its definition preclude=
s zero-size type lists.&nbsp; (Maybe I'll try making my test <font face=3D"=
courier new,monospace">make_array</font> use only a general type pack, and =
if it chokes with zero parameters, maybe that'll be sufficient.)</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;"><div dir=3D"ltr"><div><ol><li>This does not concept=
ually belong to a "multiarray" library. It is a utility for creating a one-=
dimensional array. (Although it does evaluate the <span style=3D"font-famil=
y: courier new,monospace;">array_t</span> metafunction, it is a pointless e=
xercise as the arguments seem to map directly to <span style=3D"font-family=
: courier new,monospace;">std::array&lt;T,N&gt;</span>. Although I can't se=
e where <span style=3D"font-family: courier new,monospace;">std::array&lt;=
=85&gt;::type</span> is defined at all. Using a valid object type as a meta=
function is sure to be controversial, if that's really what this is doing, =
but I'll wait until I can read the proposal without straining.)</li></ol></=
div></div></blockquote><div>Single-dimension arrays are a subset of multi-d=
imensional ones, especially since I'm modifying the existing single-dimensi=
on<font face=3D"courier new,monospace"> std::array</font> instead of making=
 a new class template.&nbsp; Should it be a separate proposal?&nbsp; Use of=
 <font face=3D"courier new,monospace">array_t</font> as the return type of =
<font face=3D"courier new,monospace">make_array</font> was a mistake; I've =
uploaded corrected versions that use <font face=3D"courier new,monospace">a=
rray</font>.&nbsp; (The <font face=3D"courier new,monospace">array_t</font>=
 alias can't be used, since it resolves to a built-in array type, which can=
't be used as return types.)</div><div>&nbsp;</div><div>The new <font face=
=3D"courier new,monospace">array</font> uses the standard variadic recursio=
n shtick in my sample implementation.&nbsp; That means each instantiation c=
arries around a type-alias to whatever built-in array type it uses for its =
data.&nbsp; My sample library uses "array_type" as the name.&nbsp; A trait =
for getting a built-in array type given an element type an a list of extent=
s should be a separate class template, but the best name is already being u=
sed!&nbsp; Since I need that type-alias around anyway, why not pull double-=
duty and use "type" in the Standard version?</div><div>&nbsp;</div><div>Dar=
yle W.</div><div>&nbsp;</div></div>

<p></p>

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

------=_Part_953_30847448.1379006164492--

.

------=_Part_881_17736299.1379029162537
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Friday, September 13, 2013 1:16:04 AM UTC+8, Daryle Walker wrote:
>
> On Wednesday, September 11, 2013 8:05:08 PM UTC-4, David Krauss wrote:
>>
>> How much testing and research has gone into this? (Has it actually been=
=20
>> used by people in a real project? How much have you used it?)=20
>> Boost.Multiarray isn't even mentioned. Is submission as an international=
=20
>> standard really the next step for this library?
>>
> =20
> As I said earlier, I came up with this idea a few months ago as an=20
> exercise.  AFAIK, it's only been used in my unit test program for it.  Bu=
t=20
> I don't think there's any experience requirement; as long as a proposal i=
s=20
> submitted, a library with a decade of in-field hard testing and a library=
=20
> from a five-minute as^H^Hhead-pull are equivalent.  Since this library=20
> isn't trying to bring new innovations in (C++) programming, simple=20
> inspection is still useful.
>

Except that it *is* trying to be innovative.

Simple (code) inspection is useful, but at this stage you or your friends=
=20
should be the one doing it. IMHO (I'm relatively new here) the official=20
channels have their hands full without reviewing almost completely=20
untested, rough drafts. There's no rule against submitting whatever you=20
like, but that doesn't mean you *should*.

There are more issues, for example arr[ arr.size() - 1 ] is all but=20
guaranteed to go past the end in the multidimensional case. value_type and=
=20
dereference need to be sorted out. Cursory usage will turn up major flaws=
=20
the library.
=20

> I haven't mentioned Boost.Multiarray since it's dynamic-memory based.
>

Memory allocation is but one concern.
=20

> That means each instantiation carries around a type-alias to whatever=20
> built-in array type it uses for its data.  My sample library uses=20
> "array_type" as the name.  A trait for getting a built-in array type give=
n=20
> an element type an a list of extents should be a separate class template,=
=20
> but the best name is already being used!  Since I need that type-alias=20
> around anyway, why not pull double-duty and use "type" in the Standard=20
> version?
>

Using an object type as a metafunction requires that all declarations=20
besides ::type be instantiated when the metafunction is evaluated. This=20
requires that those declarations will be well-formed even though they=20
aren't used, and it requires the compiler to do the extra work.

B'sides=85 separation of concerns. Need I say more?

--=20

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

------=_Part_881_17736299.1379029162537
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, September 13, 2013 1:16:04 AM UTC+8, Da=
ryle Walker wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Wednesday, September 11, 2013 8:05:08 PM UTC-4, David Krauss wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><div>How much testing and research has go=
ne into this? (Has it actually been used by people in a real project? How m=
uch have you used it?) Boost.Multiarray isn't even mentioned. Is submission=
 as an international standard really the next step for this library?</div><=
/div></blockquote><div>&nbsp;</div><div>As I said earlier, I came up with t=
his idea a few months ago as an exercise.&nbsp; AFAIK, it's only been used =
in my unit test program for it.&nbsp; But I don't think there's any experie=
nce requirement; as long as a proposal is submitted, a library with a decad=
e of in-field hard testing and a library from a five-minute as^H^Hhead-pull=
 are equivalent.&nbsp; Since this library isn't trying to bring new innovat=
ions in (C++) programming, simple inspection is still useful.</div></div></=
blockquote><div><br>Except that it <i>is</i> trying to be innovative.<br><b=
r>Simple (code) inspection is useful, but at this stage you or your friends=
 should be the one doing it. IMHO (I'm relatively new here) the official ch=
annels have their hands full without reviewing almost completely untested, =
rough drafts. There's no rule against submitting whatever you like, but tha=
t doesn't mean you <i>should</i>.<br><br>There are more issues, for example=
 <span style=3D"font-family: courier new,monospace;">arr[ arr.size() - 1 ]<=
/span> is all but guaranteed to go past the end in the multidimensional cas=
e. <span style=3D"font-family: courier new,monospace;">value_type</span> an=
d <span style=3D"font-family: courier new,monospace;">dereference</span> ne=
ed to be sorted out. Cursory usage will turn up major flaws the library.<br=
>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>I haven't mentioned Boost.Multiarray since it's dynamic-memory based.<=
/div></div></blockquote><div><br>Memory allocation is but one concern.<br>&=
nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Th=
at means each instantiation carries around a type-alias to whatever built-i=
n array type it uses for its data.&nbsp; My sample library uses "array_type=
" as the name.&nbsp; A trait for getting a built-in array type given an ele=
ment type an a list of extents should be a separate class template, but the=
 best name is already being used!&nbsp; Since I need that type-alias around=
 anyway, why not pull double-duty and use "type" in the Standard version?</=
div></blockquote><div><br>Using an object type as a metafunction requires t=
hat all declarations besides <span style=3D"font-family: courier new,monosp=
ace;">::type</span> be instantiated when the metafunction is evaluated. Thi=
s requires that those declarations will be well-formed even though they are=
n't used, and it requires the compiler to do the extra work.<br><br>B'sides=
=85 separation of concerns. Need I say more?<br><br></div></div>

<p></p>

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

------=_Part_881_17736299.1379029162537--

.

------=_Part_1495_10208852.1379032569451
Content-Type: text/plain; charset=ISO-8859-1

I also have an implementation that I started on a few nights ago, and can
be seen here: http://bryanstamour.com/array.cxx

My implementation mimics that of std::array so that there are no surprises
with it's use. It can be indexed via successive calls to operator [], just
like C-style arrays. And it's also a simple aggregate type, so the layout
is nice too.

If you are interested in collaboration, I would love to help out with your
proposal effort.

Bryan St. Amour

On Friday, 6 September 2013 20:17:12 UTC-4, Daryle Walker wrote:
>
> As an exercise in using variadic templates, I chose a multi-dimensional
> variant of std::array.  I eventually made the interface match std::array
> when the number of extents given is one.  When wondering if I should put
> the class template up for consideration, I realized that it would be so
> close to std::array, that I shouldn't propose my class directly for the
> Standard Library, but propose a change to std::array instead.
>
> I just put it up at https://github.com/CTMacUser/multiarray-iso-proposal,for requesting comments before officially proposing it.  (I should switch
> to HTML or some other rich-text system for the next draft....)
>
> Daryle W.
>
>

--

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

------=_Part_1495_10208852.1379032569451
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I also have an implementation that I started on a few nigh=
ts ago, and can be seen here: http://bryanstamour.com/array.cxx<br><br>My i=
mplementation mimics that of std::array so that there are no surprises with=
 it's use. It can be indexed via successive calls to operator [], just like=
 C-style arrays. And it's also a simple aggregate type, so the layout is ni=
ce too.<br><br>If you are interested in collaboration, I would love to help=
 out with your proposal effort.<br><br>Bryan St. Amour<br><br>On Friday, 6 =
September 2013 20:17:12 UTC-4, Daryle Walker  wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div>As an exercise in using variadi=
c templates, I chose a multi-dimensional variant of std::array.&nbsp; I eve=
ntually made the interface match std::array when the number of extents give=
n is one.&nbsp; When wondering if I should put the class template up for co=
nsideration, I realized that it would be so close to std::array, that I sho=
uldn't propose my class directly for the Standard Library, but propose a ch=
ange to std::array instead.</div><div>&nbsp;</div><div>I just put it up at =
<a href=3D"https://github.com/CTMacUser/multiarray-iso-proposal," target=3D=
"_blank">https://github.com/CTMacUser/<wbr>multiarray-iso-proposal,</a> for=
 requesting comments before officially proposing it.&nbsp; (I should switch=
 to HTML or some other rich-text system for the next draft....)</div><div>&=
nbsp;</div><div>Daryle W.</div><div>&nbsp;</div></div></blockquote></div>

<p></p>

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

------=_Part_1495_10208852.1379032569451--

.

------=_Part_1090_15799416.1379032662657
Content-Type: text/plain; charset=ISO-8859-1

P.S. Sorry.

It's of course not quite complete yet: I need to go over the description of
std::array with a fine toothed comb to ensure that my constexpr/noexcept
specifications are correct.

B

On Thursday, 12 September 2013 20:36:09 UTC-4, Bryan St. Amour wrote:
>
> I also have an implementation that I started on a few nights ago, and can
> be seen here: http://bryanstamour.com/array.cxx
>
> My implementation mimics that of std::array so that there are no surprises
> with it's use. It can be indexed via successive calls to operator [], just
> like C-style arrays. And it's also a simple aggregate type, so the layout
> is nice too.
>
> If you are interested in collaboration, I would love to help out with your
> proposal effort.
>
> Bryan St. Amour
>
> On Friday, 6 September 2013 20:17:12 UTC-4, Daryle Walker wrote:
>>
>> As an exercise in using variadic templates, I chose a multi-dimensional
>> variant of std::array.  I eventually made the interface match std::array
>> when the number of extents given is one.  When wondering if I should put
>> the class template up for consideration, I realized that it would be so
>> close to std::array, that I shouldn't propose my class directly for the
>> Standard Library, but propose a change to std::array instead.
>>
>> I just put it up at https://github.com/CTMacUser/multiarray-iso-proposal,for requesting comments before officially proposing it.  (I should switch
>> to HTML or some other rich-text system for the next draft....)
>>
>> Daryle W.
>>
>>
>

--

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

------=_Part_1090_15799416.1379032662657
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">P.S. Sorry.<br><br>It's of course not quite complete yet: =
I need to go over the description of std::array with a fine toothed comb to=
 ensure that my constexpr/noexcept specifications are correct.<br><br>B<br>=
<br>On Thursday, 12 September 2013 20:36:09 UTC-4, Bryan St. Amour  wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I also have an=
 implementation that I started on a few nights ago, and can be seen here: <=
a href=3D"http://bryanstamour.com/array.cxx" target=3D"_blank">http://bryan=
stamour.com/array.<wbr>cxx</a><br><br>My implementation mimics that of std:=
:array so that there are no surprises with it's use. It can be indexed via =
successive calls to operator [], just like C-style arrays. And it's also a =
simple aggregate type, so the layout is nice too.<br><br>If you are interes=
ted in collaboration, I would love to help out with your proposal effort.<b=
r><br>Bryan St. Amour<br><br>On Friday, 6 September 2013 20:17:12 UTC-4, Da=
ryle Walker  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>As an exercise in using variadic templates, I chose a multi-dimension=
al variant of std::array.&nbsp; I eventually made the interface match std::=
array when the number of extents given is one.&nbsp; When wondering if I sh=
ould put the class template up for consideration, I realized that it would =
be so close to std::array, that I shouldn't propose my class directly for t=
he Standard Library, but propose a change to std::array instead.</div><div>=
&nbsp;</div><div>I just put it up at <a href=3D"https://github.com/CTMacUse=
r/multiarray-iso-proposal," target=3D"_blank">https://github.com/CTMacUser/=
<wbr>multiarray-iso-proposal,</a> for requesting comments before officially=
 proposing it.&nbsp; (I should switch to HTML or some other rich-text syste=
m for the next draft....)</div><div>&nbsp;</div><div>Daryle W.</div><div>&n=
bsp;</div></div></blockquote></div></blockquote></div>

<p></p>

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

------=_Part_1090_15799416.1379032662657--

.

------=_Part_1454_16943203.1379031252184
Content-Type: text/plain; charset=ISO-8859-1

I also have an implementation of a multi_array that is the same as
std::array, down to also being an aggregate type.
http://bryanstamour.com/array.cxx

If you find it interesting, would you want to work on a proposal together?

On Friday, 6 September 2013 20:17:12 UTC-4, Daryle Walker wrote:
>
> As an exercise in using variadic templates, I chose a multi-dimensional
> variant of std::array.  I eventually made the interface match std::array
> when the number of extents given is one.  When wondering if I should put
> the class template up for consideration, I realized that it would be so
> close to std::array, that I shouldn't propose my class directly for the
> Standard Library, but propose a change to std::array instead.
>
> I just put it up at https://github.com/CTMacUser/multiarray-iso-proposal,for requesting comments before officially proposing it.  (I should switch
> to HTML or some other rich-text system for the next draft....)
>
> Daryle W.
>
>

--

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

------=_Part_1454_16943203.1379031252184
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I also have an implementation of a multi_array that is the=
 same as std::array, down to also being an aggregate type. <a href=3D"http:=
//bryanstamour.com/array.cxx">http://bryanstamour.com/array.cxx</a><br><br>=
If you find it interesting, would you want to work on a proposal together?<=
br><br>On Friday, 6 September 2013 20:17:12 UTC-4, Daryle Walker  wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>As an exerc=
ise in using variadic templates, I chose a multi-dimensional variant of std=
::array.&nbsp; I eventually made the interface match std::array when the nu=
mber of extents given is one.&nbsp; When wondering if I should put the clas=
s template up for consideration, I realized that it would be so close to st=
d::array, that I shouldn't propose my class directly for the Standard Libra=
ry, but propose a change to std::array instead.</div><div>&nbsp;</div><div>=
I just put it up at <a href=3D"https://github.com/CTMacUser/multiarray-iso-=
proposal," target=3D"_blank">https://github.com/CTMacUser/<wbr>multiarray-i=
so-proposal,</a> for requesting comments before officially proposing it.&nb=
sp; (I should switch to HTML or some other rich-text system for the next dr=
aft....)</div><div>&nbsp;</div><div>Daryle W.</div><div>&nbsp;</div></div><=
/blockquote></div>

<p></p>

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

------=_Part_1454_16943203.1379031252184--

.

------=_Part_1356_1003938.1379031122577
Content-Type: text/plain; charset=ISO-8859-1

I also have an implementation that I finished last night:
http://bryanstamour.com/array.cxx

I haven't fully tested everything yet, and I hope to nail down the
constexpr/noexcept bits next to ensure that it exactly matches the
interface of std::array. Perhaps we can work together if you wish to move
forward with a proposal? I'd be interested in helping out...

On Friday, 6 September 2013 20:17:12 UTC-4, Daryle Walker wrote:
>
> As an exercise in using variadic templates, I chose a multi-dimensional
> variant of std::array.  I eventually made the interface match std::array
> when the number of extents given is one.  When wondering if I should put
> the class template up for consideration, I realized that it would be so
> close to std::array, that I shouldn't propose my class directly for the
> Standard Library, but propose a change to std::array instead.
>
> I just put it up at https://github.com/CTMacUser/multiarray-iso-proposal,for requesting comments before officially proposing it.  (I should switch
> to HTML or some other rich-text system for the next draft....)
>
> Daryle W.
>
>

--

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

------=_Part_1356_1003938.1379031122577
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I also have an implementation that I finished last night: =
<a href=3D"http://bryanstamour.com/array.cxx">http://bryanstamour.com/array=
..cxx</a><br><br>I haven't fully tested everything yet, and I hope to nail d=
own the constexpr/noexcept bits next to ensure that it exactly matches the =
interface of std::array. Perhaps we can work together if you wish to move f=
orward with a proposal? I'd be interested in helping out...<br><br>On Frida=
y, 6 September 2013 20:17:12 UTC-4, Daryle Walker  wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>As an exercise in using v=
ariadic templates, I chose a multi-dimensional variant of std::array.&nbsp;=
 I eventually made the interface match std::array when the number of extent=
s given is one.&nbsp; When wondering if I should put the class template up =
for consideration, I realized that it would be so close to std::array, that=
 I shouldn't propose my class directly for the Standard Library, but propos=
e a change to std::array instead.</div><div>&nbsp;</div><div>I just put it =
up at <a href=3D"https://github.com/CTMacUser/multiarray-iso-proposal," tar=
get=3D"_blank">https://github.com/CTMacUser/<wbr>multiarray-iso-proposal,</=
a> for requesting comments before officially proposing it.&nbsp; (I should =
switch to HTML or some other rich-text system for the next draft....)</div>=
<div>&nbsp;</div><div>Daryle W.</div><div>&nbsp;</div></div></blockquote></=
div>

<p></p>

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

------=_Part_1356_1003938.1379031122577--

.

------=_Part_5610_23178844.1379404407270
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thursday, September 12, 2013 7:39:22 PM UTC-4, David Krauss wrote:
>
> On Friday, September 13, 2013 1:16:04 AM UTC+8, Daryle Walker wrote:
>>
>> On Wednesday, September 11, 2013 8:05:08 PM UTC-4, David Krauss wrote:
>>>
>>> How much testing and research has gone into this? (Has it actually been=
=20
>>> used by people in a real project? How much have you used it?)=20
>>> Boost.Multiarray isn't even mentioned. Is submission as an internationa=
l=20
>>> standard really the next step for this library?
>>>
>> =20
>> As I said earlier, I came up with this idea a few months ago as an=20
>> exercise.  AFAIK, it's only been used in my unit test program for it.  B=
ut=20
>> I don't think there's any experience requirement; as long as a proposal =
is=20
>> submitted, a library with a decade of in-field hard testing and a librar=
y=20
>> from a five-minute as^H^Hhead-pull are equivalent.  Since this library=
=20
>> isn't trying to bring new innovations in (C++) programming, simple=20
>> inspection is still useful.
>>
>
> Except that it *is* trying to be innovative.
>
> Simple (code) inspection is useful, but at this stage you or your friends=
=20
> should be the one doing it. IMHO (I'm relatively new here) the official=
=20
> channels have their hands full without reviewing almost completely=20
> untested, rough drafts. There's no rule against submitting whatever you=
=20
> like, but that doesn't mean you *should*.
>
> There are more issues, for example arr[ arr.size() - 1 ] is all but=20
> guaranteed to go past the end in the multidimensional case. value_typeand=
=20
> dereference need to be sorted out. Cursory usage will turn up major flaws=
=20
> the library.
>
=20
Calling the subscript operator like that is a misuse.  Doing it is just=20
like indexing by T in a multidimensional built-in array of T using one=20
index.
=20
A sequence container is linear, but a multi-dimensional container is=20
non-linear.  Fortunately, those definitions only come in conflict with the=
=20
definitions of operator[]() and at().  I specifically exclude those two=20
operations from the sequence requirements with non-one rank in my=20
modifications to section 23.2.3 and refer to section 23.3.2.D for the=20
substitute operations.
=20
For the non-linear arrays, I move from subscripting being an addition to=20
begin() to a multi-coordinate address system.  Iteration is still=20
supported, so the linear case, range-for, and standard algorithms still=20
work.  An alternate form of access is passing a function object while the=
=20
library code does the iteration, but the function object receives=20
the element's coordinates with the element.  Note that all the access=20
methods return a reference to either value_type or a built-in array type,=
=20
never some sort of sub-std::array.
=20
value_type is the type given in the template header.  dereference is the=20
type returned from the scalar version of the subscripting operator. =20
(That's why it's omitted when sizeof...(N) =3D=3D 0.)  In the linear case, =
the=20
two type-aliases point to the same type.  Even for higher-ranks, dereferenc=
ealiases one-extent less than the internal built-in array type.
=20

> I haven't mentioned Boost.Multiarray since it's dynamic-memory based.
>
> Memory allocation is but one concern.=20
>
=20
Boost.Multiarray uses a different static interface (The template arguments=
=20
are the element type and the rank), so it's incompatible with my proposal=
=20
to begin with, which extents the current std::array in a=20
backwards-compatible way.  BM gets the actual extent values during the=20
constructor call, while new std::array keeps them in the template header. =
=20
Both classes support indexing through bracket chains and a single=20
multi-index object.  BM has an extensive view system, while new std::arrayk=
eeps the lack of same as current=20
std::array and built-in arrays do.  BM has a same-type & same-rank=20
reshaping, one preserving total size and another for adding or removing=20
elements; I just added a reshaping function that can change type, rank, and=
=20
total size, but it always makes a copy.
=20

> That means each instantiation carries around a type-alias to whatever=20
>> built-in array type it uses for its data.  My sample library uses=20
>> "array_type" as the name.  A trait for getting a built-in array type giv=
en=20
>> an element type an a list of extents should be a separate class template=
,=20
>> but the best name is already being used!  Since I need that type-alias=
=20
>> around anyway, why not pull double-duty and use "type" in the Standard=
=20
>> version?
>>
>
> Using an object type as a metafunction requires that all declarations=20
> besides ::type be instantiated when the metafunction is evaluated. This=
=20
> requires that those declarations will be well-formed even though they=20
> aren't used, and it requires the compiler to do the extra work.
>
=20
I tried to check this, but Chapter 14 (Template) is very deep and dense. =
=20
What sections were you looking at?  Even if all the other declarations are=
=20
instantiated, all of them should always be well-formed (except maybe the=20
zero-elements specializations).
=20

> B'sides=85 separation of concerns. Need I say more?
>
=20
Daryle W.
=20

--=20

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

------=_Part_5610_23178844.1379404407270
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, September 12, 2013 7:39:22 PM UTC-4, David Kr=
auss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Friday, Septemb=
er 13, 2013 1:16:04 AM UTC+8, Daryle Walker wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left=
-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: soli=
d;"><div dir=3D"ltr">On Wednesday, September 11, 2013 8:05:08 PM UTC-4, Dav=
id Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>How much=
 testing and research has gone into this? (Has it actually been used by peo=
ple in a real project? How much have you used it?) Boost.Multiarray isn't e=
ven mentioned. Is submission as an international standard really the next s=
tep for this library?</div></div></blockquote><div>&nbsp;</div><div>As I sa=
id earlier, I came up with this idea a few months ago as an exercise.&nbsp;=
 AFAIK, it's only been used in my unit test program for it.&nbsp; But I don=
't think there's any experience requirement; as long as a proposal is submi=
tted, a library with a decade of in-field hard testing and a library from a=
 five-minute as^H^Hhead-pull are equivalent.&nbsp; Since this library isn't=
 trying to bring new innovations in (C++) programming, simple inspection is=
 still useful.</div></div></blockquote><div><br>Except that it <i>is</i> tr=
ying to be innovative.<br><br>Simple (code) inspection is useful, but at th=
is stage you or your friends should be the one doing it. IMHO (I'm relative=
ly new here) the official channels have their hands full without reviewing =
almost completely untested, rough drafts. There's no rule against submittin=
g whatever you like, but that doesn't mean you <i>should</i>.<br><br>There =
are more issues, for example <span style=3D"font-family: courier new,monosp=
ace;">arr[ arr.size() - 1 ]</span> is all but guaranteed to go past the end=
 in the multidimensional case. <span style=3D"font-family: courier new,mono=
space;">value_type</span> and <span style=3D"font-family: courier new,monos=
pace;">dereference</span> need to be sorted out. Cursory usage will turn up=
 major flaws the library.</div></div></blockquote><div>&nbsp;</div><div>Cal=
ling the subscript operator like that is&nbsp;a misuse.&nbsp; Doing it is j=
ust like indexing by <font face=3D"courier new,monospace">T</font> in a mul=
tidimensional built-in array of <font face=3D"courier new,monospace">T</fon=
t> using one index.</div><div>&nbsp;</div><div>A sequence container is line=
ar, but a multi-dimensional container is non-linear.&nbsp; Fortunately, tho=
se definitions only come in conflict with the definitions of <font face=3D"=
courier new,monospace">operator[]()</font> and <font face=3D"courier new,mo=
nospace">at()</font>.&nbsp; I specifically exclude those two operations fro=
m the sequence requirements with non-one rank in my modifications to sectio=
n 23.2.3 and refer to section 23.3.2.D for the substitute operations.</div>=
<div>&nbsp;</div><div>For the non-linear arrays, I move from subscripting b=
eing an addition to <font face=3D"courier new,monospace">begin()</font> to =
a multi-coordinate address system.&nbsp; Iteration is still supported, so t=
he linear case, range-for, and standard algorithms still work.&nbsp;&nbsp;A=
n alternate form of access is passing a function object while the library&n=
bsp;code does the iteration, but the function object receives the&nbsp;elem=
ent's coordinates with the element.&nbsp; Note that all the access methods =
return a reference to either <font face=3D"courier new,monospace">value_typ=
e</font> or a built-in array type, never some sort of sub-<font face=3D"cou=
rier new,monospace">std::array</font>.</div><div>&nbsp;</div><div><font fac=
e=3D"courier new,monospace">value_type</font> is the type given in the temp=
late header.&nbsp; <font face=3D"courier new,monospace">dereference</font> =
is the type returned from the scalar version of the subscripting operator.&=
nbsp; (That's why it's omitted when <font face=3D"courier new,monospace">si=
zeof...(N) =3D=3D 0</font>.)&nbsp; In the linear case, the two type-aliases=
 point to the same type.&nbsp; Even for higher-ranks, <font face=3D"courier=
 new,monospace">dereference</font> aliases one-extent less than the interna=
l built-in array type.</div><div>&nbsp;</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><=
div dir=3D"ltr"><div>I haven't mentioned Boost.Multiarray since it's dynami=
c-memory based.</div><div><br>Memory allocation is but one concern.&nbsp;</=
div></div></blockquote><div>&nbsp;</div><div>Boost.Multiarray uses a differ=
ent static interface (The template arguments are the element type and the r=
ank), so it's incompatible with my proposal to begin with, which extents th=
e current <font face=3D"courier new,monospace">std::array</font> in&nbsp;a =
backwards-compatible way.&nbsp; BM gets the actual extent values during the=
 constructor call, while new <font face=3D"courier new,monospace">std::arra=
y</font> keeps them in the template header.&nbsp; Both classes support inde=
xing through bracket chains and a single multi-index object.&nbsp; BM has a=
n extensive view system, while new <font face=3D"courier new,monospace">std=
::array</font> keeps the lack of same as current <font face=3D"courier new,=
monospace">std::array</font> and built-in arrays do.&nbsp; BM has a same-ty=
pe &amp; same-rank reshaping, one preserving total size and another for add=
ing or removing elements; I just added a reshaping function that can change=
 type, rank, and total size, but it always makes a copy.</div><div>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
 1px; border-left-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left=
-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: soli=
d;"><div dir=3D"ltr">That means each instantiation carries around a type-al=
ias to whatever built-in array type it uses for its data.&nbsp; My sample l=
ibrary uses "array_type" as the name.&nbsp; A trait for getting a built-in =
array type given an element type an a list of extents should be a separate =
class template, but the best name is already being used!&nbsp; Since I need=
 that type-alias around anyway, why not pull double-duty and use "type" in =
the Standard version?</div></blockquote><div><br>Using an object type as a =
metafunction requires that all declarations besides <span style=3D"font-fam=
ily: courier new,monospace;">::type</span> be instantiated when the metafun=
ction is evaluated. This requires that those declarations will be well-form=
ed even though they aren't used, and it requires the compiler to do the ext=
ra work.</div></div></blockquote><div>&nbsp;</div><div>I tried to check thi=
s, but Chapter 14 (Template) is very deep and dense.&nbsp; What sections we=
re you looking at?&nbsp; Even if all the other declarations are instantiate=
d, all of them should always be well-formed (except maybe the zero-elements=
 specializations).</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: r=
gb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div =
dir=3D"ltr"><div>B'sides=85 separation of concerns. Need I say more?</div><=
/div></blockquote><div>&nbsp;</div><div>Daryle W.</div><div>&nbsp;</div></d=
iv>

<p></p>

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

------=_Part_5610_23178844.1379404407270--

.

------=_Part_26_8527193.1379404666780
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, September 12, 2013 8:37:42 PM UTC-4, Bryan St. Amour wrote:
>
> P.S. Sorry.
>
> It's of course not quite complete yet: I need to go over the description
> of std::array with a fine toothed comb to ensure that my constexpr/noexcept
> specifications are correct.
>

That may be harder than it seems, because I don't know if those
specifications are stable.  The C++14 draft before last (N3690) had as many
member functions as possible marked constexpr in std::array, but the latest
draft (N3691) purged all those qualifiers except for size/empty/max_size.


> B
>
> On Thursday, 12 September 2013 20:36:09 UTC-4, Bryan St. Amour wrote:
>>
>> I also have an implementation that I started on a few nights ago, and can
>> be seen here: http://bryanstamour.com/array.cxx
>>
>> My implementation mimics that of std::array so that there are no
>> surprises with it's use. It can be indexed via successive calls to operator
>> [], just like C-style arrays. And it's also a simple aggregate type, so the
>> layout is nice too.
>>
>> If you are interested in collaboration, I would love to help out with
>> your proposal effort.
>>
>> Bryan St. Amour
>>
>> On Friday, 6 September 2013 20:17:12 UTC-4, Daryle Walker wrote:
>>>
>>> As an exercise in using variadic templates, I chose a multi-dimensional
>>> variant of std::array.  I eventually made the interface match std::array
>>> when the number of extents given is one.  When wondering if I should put
>>> the class template up for consideration, I realized that it would be so
>>> close to std::array, that I shouldn't propose my class directly for the
>>> Standard Library, but propose a change to std::array instead.
>>>
>>> I just put it up at
>>> https://github.com/CTMacUser/multiarray-iso-proposal, for requesting
>>> comments before officially proposing it.  (I should switch to HTML or some
>>> other rich-text system for the next draft....)
>>>
>>> Daryle W.
>>>
>>>
>>

--

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

------=_Part_26_8527193.1379404666780
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, September 12, 2013 8:37:42 PM UTC-4, Bryan St=
.. Amour wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;"><div dir=3D"ltr">P.S. Sorry.<br>=
<br>It's of course not quite complete yet: I need to go over the descriptio=
n of std::array with a fine toothed comb to ensure that my constexpr/noexce=
pt specifications are correct.</div></blockquote><div>&nbsp;</div><div>That=
 may be harder than it seems, because I don't know if those specifications =
are stable.&nbsp; The C++14 draft before last (N3690) had as many member fu=
nctions as possible marked <font face=3D"courier new,monospace">constexpr <=
font face=3D"arial,sans-serif">in</font> std::array</font>, but the latest =
draft (N3691) purged all those qualifiers except for <font face=3D"courier =
new,monospace">size</font>/<font face=3D"courier new,monospace">empty</font=
>/<font face=3D"courier new,monospace">max_size</font>.</div><div>&nbsp;</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;"><div dir=3D"ltr">B<br><br>On Thursday, 12 S=
eptember 2013 20:36:09 UTC-4, Bryan St. Amour  wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-l=
eft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: s=
olid;"><div dir=3D"ltr">I also have an implementation that I started on a f=
ew nights ago, and can be seen here: <a href=3D"http://bryanstamour.com/arr=
ay.cxx" target=3D"_blank">http://bryanstamour.com/array.<wbr>cxx</a><br><br=
>My implementation mimics that of std::array so that there are no surprises=
 with it's use. It can be indexed via successive calls to operator [], just=
 like C-style arrays. And it's also a simple aggregate type, so the layout =
is nice too.<br><br>If you are interested in collaboration, I would love to=
 help out with your proposal effort.<br><br>Bryan St. Amour<br><br>On Frida=
y, 6 September 2013 20:17:12 UTC-4, Daryle Walker  wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr"><div>As an exercise in using variadic template=
s, I chose a multi-dimensional variant of std::array.&nbsp; I eventually ma=
de the interface match std::array when the number of extents given is one.&=
nbsp; When wondering if I should put the class template up for consideratio=
n, I realized that it would be so close to std::array, that I shouldn't pro=
pose my class directly for the Standard Library, but propose a change to st=
d::array instead.</div><div>&nbsp;</div><div>I just put it up at <a href=3D=
"https://github.com/CTMacUser/multiarray-iso-proposal," target=3D"_blank">h=
ttps://github.com/CTMacUser/<wbr>multiarray-iso-proposal,</a> for requestin=
g comments before officially proposing it.&nbsp; (I should switch to HTML o=
r some other rich-text system for the next draft....)</div><div>&nbsp;</div=
><div>Daryle W.</div><div>&nbsp;</div></div></blockquote></div></blockquote=
></div></blockquote></div>

<p></p>

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

------=_Part_26_8527193.1379404666780--

.

------=_Part_3848_22707957.1379407243106
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, September 17, 2013 3:53:27 PM UTC+8, Daryle Walker wrote:
>
> Calling the subscript operator like that is a misuse.  Doing it is just
> like indexing by T in a multidimensional built-in array of T using one
> index.
>

According to you. Without the special exception you propose for table 101,
generic code can assume that & c[n] == &* ( c.begin() + n ).


>  A sequence container is linear, but a multi-dimensional container is
> non-linear.
>

A multi-dimensional array is always linear. Each immediate subobject is an
array.


>   Fortunately, those definitions only come in conflict with the
> definitions of operator[]() and at().  I specifically exclude those two
> operations from the sequence requirements with non-one rank in my
> modifications to section 23.2.3 and refer to section 23.3.2.D for the
> substitute operations.
>

This is inconsistent with other containers.


> Boost.Multiarray uses a different static interface (The template arguments
> are the element type and the rank), so it's incompatible with my proposal
> to begin with, which extents the current std::array in a
> backwards-compatible way.  BM gets the actual extent values during the
> constructor call, while new std::array keeps them in the template header.
>

There are far more applications for variable-size multidimensional arrays.

  Both classes support indexing through bracket chains and a single
> multi-index object.  BM has an extensive view system,


Whether you have a fixed or variable amount of data, the multiply indexed
views have the same use. For example some code could work with both a
fixed-size kernel and the data series it operates on.

Perhaps a generic view is what we need, along the lines of std::slice and
std::gslice but divorced from valarray. Those classes could even perhaps be
reused.


> while new std::array keeps the lack of same as current std::array and
> built-in arrays do.  BM has a same-type & same-rank reshaping, one
> preserving total size and another for adding or removing elements; I just
> added a reshaping function that can change type, rank, and total size, but
> it always makes a copy.
>

This is a symptom of having used the multidimensional object to specify the
underlying storage. The view and the storage are separate concerns.

I tried to check this, but Chapter 14 (Template) is very deep and dense.
>

Instantiating a class template instantiates the declarations therein.
Instantiations of definitions are deferred until use.

--

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

------=_Part_3848_22707957.1379407243106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, September 17, 2013 3:53:27 PM UTC+8, D=
aryle Walker wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">Calling the subscript operator like that is&nbsp;a misuse.&nbsp; Doin=
g it is just like indexing by <font face=3D"courier new,monospace">T</font>=
 in a multidimensional built-in array of <font face=3D"courier new,monospac=
e">T</font> using one index.</div></blockquote><div><br>According to you. W=
ithout the special exception you propose for table 101, generic code can as=
sume that <span style=3D"font-family: courier new,monospace;">&amp; c[n] =
=3D=3D &amp;* ( c.begin() + n )</span>.<br>&nbsp;</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div>&nbsp;A sequence container i=
s linear, but a multi-dimensional container is non-linear.</div></div></blo=
ckquote><div><br>A multi-dimensional array is always linear. Each immediate=
 subobject is an array.<br>&nbsp;</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 dir=3D"ltr"><div>&nbsp; Fortunately, those definitions only c=
ome in conflict with the definitions of <font face=3D"courier new,monospace=
">operator[]()</font> and <font face=3D"courier new,monospace">at()</font>.=
&nbsp; I specifically exclude those two operations from the sequence requir=
ements with non-one rank in my modifications to section 23.2.3 and refer to=
 section 23.3.2.D for the substitute operations.</div></div></blockquote><d=
iv><br>This is inconsistent with other containers.<br>&nbsp;</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Boost.Multiarray uses =
a different static interface (The template arguments are the element type a=
nd the rank), so it's incompatible with my proposal to begin with, which ex=
tents the current <font face=3D"courier new,monospace">std::array</font> in=
&nbsp;a backwards-compatible way.&nbsp; BM gets the actual extent values du=
ring the constructor call, while new <font face=3D"courier new,monospace">s=
td::array</font> keeps them in the template header.</div></blockquote><div =
dir=3D"ltr"><br>There are far more applications for variable-size multidime=
nsional arrays.<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_q=
uote">&nbsp; Both classes support indexing through bracket chains and a sin=
gle multi-index object.&nbsp; BM has an extensive view system, </blockquote=
></div><div><br>Whether you have a fixed or variable amount of data, the mu=
ltiply indexed views have the same use. For example some code could work wi=
th both a fixed-size kernel and the data series it operates on.<br><br>Perh=
aps a generic view is what we need, along the lines of <span style=3D"font-=
family: courier new,monospace;">std::slice</span> and <span style=3D"font-f=
amily: courier new,monospace;">std::gslice</span> but divorced from <span s=
tyle=3D"font-family: courier new,monospace;">valarray</span>. Those classes=
 could even perhaps be reused.<br>&nbsp;</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 dir=3D"ltr">while new <font face=3D"courier new,monosp=
ace">std::array</font> keeps the lack of same as current <font face=3D"cour=
ier new,monospace">std::array</font> and built-in arrays do.&nbsp; BM has a=
 same-type &amp; same-rank reshaping, one preserving total size and another=
 for adding or removing elements; I just added a reshaping function that ca=
n change type, rank, and total size, but it always makes a copy.</div></blo=
ckquote><div><br>This is a symptom of having used the multidimensional obje=
ct to specify the underlying storage. The view and the storage are separate=
 concerns.<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 d=
ir=3D"ltr"><div>I tried to check this, but Chapter 14 (Template) is very de=
ep and dense.</div></div></blockquote><div><br>Instantiating a class templa=
te instantiates the declarations therein. Instantiations of definitions are=
 deferred until use.</div></div>

<p></p>

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

------=_Part_3848_22707957.1379407243106--

.

------=_Part_2087_19526543.1379808782128
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, September 17, 2013 4:40:43 AM UTC-4, David Krauss wrote:
>
> On Tuesday, September 17, 2013 3:53:27 PM UTC+8, Daryle Walker wrote:
>>
>> Calling the subscript operator like that is a misuse.  Doing it is just
>> like indexing by T in a multidimensional built-in array of T using one
>> index.
>>
>
> According to you. Without the special exception you propose for table 101,
> generic code can assume that & c[n] == &* ( c.begin() + n ).
>

The table is for OPTIONAL behavior (and each row is considered
independently).  The author's opinion (mine) is all that matters.  I kept
the behavior where it makes sense.  It also happens to be the same type
needed to preserve backwards-compatibility.  And where is the assertion for
generic code; I didn't see it looking through the Standard.


   1. The Standard algorithms work on iterator pairs, not containers.  And
   there isn't a way to reverse-engineer a container from iterators.
   2. There are no generic traits for containers, unlike iterators.  You
   have to look up container behavior in tables, like Table 101, which can be
   changed for newly-introduced types (like all non-linear arrayinstantiations).  What would that code do when given a
   std::list, for instance?  Or std::map?



>  A sequence container is linear, but a multi-dimensional container is
>> non-linear.
>>
>
> A multi-dimensional array is always linear. Each immediate subobject is an
> array.
>

But linear purity is limiting; there's no value-add.  Templates like a
std::multi_array that would nest (current) std::arrays together aren't that
useful.  Those templates says they work with T, but that's a lie, they're
really a (linear) array of an intermediate class no one cares about.
Everything (value_type, iterators, data, fill, etc.) are in terms of that
implementation type.  If the user is just using a bunch of [] calls to get Treferences, then there's little difference, but no other operation will
meet expectations since they're in the wrong units.  In fact, making a
std::multi_array map to std::array<T[Inner]..[Extents], OuterExtent> would
be more useful since the data member being a C-level multidimensional array
means the user can exploit the sloppy array-aggregate initialization
syntax.  (Aggregate class-types, at least up to and including C++11, don't
have that, so you would have to use double-braces everywhere and get the
nesting right.)


>   Fortunately, those definitions only come in conflict with the
>> definitions of operator[]() and at().  I specifically exclude those two
>> operations from the sequence requirements with non-one rank in my
>> modifications to section 23.2.3 and refer to section 23.3.2.D for the
>> substitute operations.
>>
>
> This is inconsistent with other containers.
>

None of them use (or need) multi-coordinate access, so new considerations
are required.


> Boost.Multiarray uses a different static interface (The template arguments
>> are the element type and the rank), so it's incompatible with my proposal
>> to begin with, which extents the current std::array in a
>> backwards-compatible way.  BM gets the actual extent values during the
>> constructor call, while new std::array keeps them in the template header.
>>
>
> There are far more applications for variable-size multidimensional arrays.
>

std::vector and (current) std::array didn't put the other out of business.
(Or in this case, vector's existence wasn't proof to block array getting
in.)  I don't see why static and dynamic multi-dimensional containers can't
co-exist.

Anyway, a dynamic multi-dimensional container will have the same
"conflicts" with operator[]() that you bring up.


>   Both classes support indexing through bracket chains and a single
>> multi-index object.  BM has an extensive view system,
>
>
> Whether you have a fixed or variable amount of data, the multiply indexed
> views have the same use. For example some code could work with both a
> fixed-size kernel and the data series it operates on.
>
> Perhaps a generic view is what we need, along the lines of std::slice and
> std::gslice but divorced from valarray. Those classes could even perhaps
> be reused.
>

Well, someone else can propose that.  Just like the current array wraps a
single-extent C-level array as a Regular type, the proposed extension does
the same for multiple-extent C-level arrays.  Those could all co-exist;
there're no need to wait for a "one-to-rule-them-all" type.  (We haven't
done it with the dynamic-memory containers.)  What if those other proposals
never come?


> while new std::array keeps the lack of same as current std::array and
>> built-in arrays do.  BM has a same-type & same-rank reshaping, one
>> preserving total size and another for adding or removing elements; I just
>> added a reshaping function that can change type, rank, and total size, but
>> it always makes a copy.
>>
>
> This is a symptom of having used the multidimensional object to specify
> the underlying storage. The view and the storage are separate concerns.
>

But the point of the array class template is to use the same view and
storage models as C-level arrays.  (That's why operator[]() works the way
it does, although it violates linear-container purity.)  If you want
something beyond that, make your own proposal.

BTW, I uploaded my sixth draft earlier today at my GitHub repository.

Daryle W.


--

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

------=_Part_2087_19526543.1379808782128
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, September 17, 2013 4:40:43 AM UTC-4, David Kra=
uss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Tuesday, Septemb=
er 17, 2013 3:53:27 PM UTC+8, Daryle Walker wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left=
-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: soli=
d;"><div dir=3D"ltr">Calling the subscript operator like that is&nbsp;a mis=
use.&nbsp; Doing it is just like indexing by <font face=3D"courier new,mono=
space">T</font> in a multidimensional built-in array of <font face=3D"couri=
er new,monospace">T</font> using one index.</div></blockquote><div><br>Acco=
rding to you. Without the special exception you propose for table 101, gene=
ric code can assume that <span style=3D"font-family: courier new,monospace;=
">&amp; c[n] =3D=3D &amp;* ( c.begin() + n )</span>.&nbsp;</div></div></blo=
ckquote><div>&nbsp;</div><div>The table is for OPTIONAL behavior (and each =
row is considered independently).&nbsp; The author's opinion (mine) is all =
that matters.&nbsp; I kept the behavior where it makes sense.&nbsp; It also=
 happens to be the same type needed to preserve backwards-compatibility.&nb=
sp; And where is the assertion for generic code; I didn't see it looking th=
rough the Standard.</div><div>&nbsp;</div><ol><li>The Standard algorithms w=
ork on iterator pairs, not containers.&nbsp; And there isn't a way to rever=
se-engineer a container from iterators.</li><li>There are no generic traits=
 for containers, unlike iterators.&nbsp; You have to look up container beha=
vior in tables, like Table 101, which can be changed for newly-introduced t=
ypes (like all non-linear <font face=3D"courier new,monospace">array</font>=
 instantiations).&nbsp; What would that code do when given a <font face=3D"=
courier new,monospace">std::list</font>, for instance?&nbsp; Or <font face=
=3D"courier new,monospace">std::map</font>?</li></ol><div>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: r=
gb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div =
dir=3D"ltr"><div>&nbsp;A sequence container is linear, but a multi-dimensio=
nal container is non-linear.</div></div></blockquote><div><br>A multi-dimen=
sional array is always linear. Each immediate subobject is an array.&nbsp;<=
/div></div></blockquote><div>&nbsp;</div><div>But linear purity is limiting=
; there's no value-add.&nbsp; Templates like a <font face=3D"courier new,mo=
nospace">std::multi_array</font> that would nest (current) <font face=3D"co=
urier new,monospace">std::array</font>s together aren't that useful.&nbsp; =
Those templates says&nbsp;they work with <font face=3D"courier new,monospac=
e">T</font>, but that's a lie, they're really a (linear) array of an interm=
ediate class no one cares about.&nbsp; Everything (<font face=3D"courier ne=
w,monospace">value_type</font>, iterators, <font face=3D"courier new,monosp=
ace">data</font>, <font face=3D"courier new,monospace">fill</font>, etc.) a=
re in terms of that implementation type.&nbsp; If the user is just using a =
bunch of <font face=3D"courier new,monospace">[]</font> calls to get <font =
face=3D"courier new,monospace">T</font> references, then there's little dif=
ference, but no other operation will meet expectations since they're in the=
 wrong units.&nbsp; In fact, making a <font face=3D"courier new,monospace">=
std::multi_array</font> map to <font face=3D"courier new,monospace">std::ar=
ray&lt;T[Inner]..[Extents], OuterExtent&gt;</font> would be more useful sin=
ce the data member being a C-level multidimensional array means the user ca=
n exploit the sloppy array-aggregate initialization syntax.&nbsp; (Aggregat=
e class-types, at least up to and including C++11, don't have that, so you =
would have to use double-braces everywhere and get the nesting right.)</div=
><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div dir=3D"ltr"><div>&nbsp; Fortunately, those definitio=
ns only come in conflict with the definitions of <font face=3D"courier new,=
monospace">operator[]()</font> and <font face=3D"courier new,monospace">at(=
)</font>.&nbsp; I specifically exclude those two operations from the sequen=
ce requirements with non-one rank in my modifications to section 23.2.3 and=
 refer to section 23.3.2.D for the substitute operations.</div></div></bloc=
kquote><div><br>This is inconsistent with other containers.&nbsp;</div></di=
v></blockquote><div>&nbsp;</div><div>None of them use (or need) multi-coord=
inate access, so new considerations are required.</div><div>&nbsp;</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-=
left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; b=
order-left-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
 rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><di=
v dir=3D"ltr">Boost.Multiarray uses a different static interface (The templ=
ate arguments are the element type and the rank), so it's incompatible with=
 my proposal to begin with, which extents the current <font face=3D"courier=
 new,monospace">std::array</font> in&nbsp;a backwards-compatible way.&nbsp;=
 BM gets the actual extent values during the constructor call, while new <f=
ont face=3D"courier new,monospace">std::array</font> keeps them in the temp=
late header.</div></blockquote><div dir=3D"ltr"><br>There are far more appl=
ications for variable-size multidimensional arrays.</div></div></blockquote=
><div>&nbsp;</div><div><font face=3D"courier new,monospace">std::vector</fo=
nt> and (current) <font face=3D"courier new,monospace">std::array</font> di=
dn't put the other out of business.&nbsp; (Or in this case, <font face=3D"c=
ourier new,monospace">vector</font>'s existence wasn't proof to block <font=
 face=3D"courier new,monospace">array</font> getting in.)&nbsp; I don't see=
 why static and dynamic multi-dimensional containers can't co-exist.</div><=
div>&nbsp;</div><div>Anyway, a dynamic multi-dimensional container will hav=
e the same "conflicts" with <font face=3D"courier new,monospace">operator[]=
()</font> that you bring up.</div><div>&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-lef=
t-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: sol=
id;"><div dir=3D"ltr"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;">&nbsp; =
Both classes support indexing through bracket chains and a single multi-ind=
ex object.&nbsp; BM has an extensive view system, </blockquote></div><div><=
br>Whether you have a fixed or variable amount of data, the multiply indexe=
d views have the same use. For example some code could work with both a fix=
ed-size kernel and the data series it operates on.<br><br>Perhaps a generic=
 view is what we need, along the lines of <span style=3D"font-family: couri=
er new,monospace;">std::slice</span> and <span style=3D"font-family: courie=
r new,monospace;">std::gslice</span> but divorced from <span style=3D"font-=
family: courier new,monospace;">valarray</span>. Those classes could even p=
erhaps be reused.&nbsp;</div></div></blockquote><div>&nbsp;</div><div>Well,=
 someone else can propose that.&nbsp; Just like the current <font face=3D"c=
ourier new,monospace">array</font> wraps a single-extent C-level array as a=
 Regular type, the proposed extension does the same for multiple-extent C-l=
evel arrays.&nbsp; Those could all co-exist; there're no need to wait&nbsp;=
for a "one-to-rule-them-all" type.&nbsp; (We haven't done it with the dynam=
ic-memory containers.)&nbsp; What if those other proposals never come?</div=
><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div dir=3D"ltr">while new <font face=3D"courier new,mono=
space">std::array</font> keeps the lack of same as current <font face=3D"co=
urier new,monospace">std::array</font> and built-in arrays do.&nbsp; BM has=
 a same-type &amp; same-rank reshaping, one preserving total size and anoth=
er for adding or removing elements; I just added a reshaping function that =
can change type, rank, and total size, but it always makes a copy.</div></b=
lockquote><div><br>This is a symptom of having used the multidimensional ob=
ject to specify the underlying storage. The view and the storage are separa=
te concerns.</div></div></blockquote><div>&nbsp;</div><div>But the point of=
 the <font face=3D"courier new,monospace">array</font> class template is to=
 use the same view and storage models as C-level arrays.&nbsp; (That's why =
<font face=3D"courier new,monospace">operator[]()</font> works the way it d=
oes, although it violates linear-container purity.)&nbsp; If you want somet=
hing beyond that, make your own proposal.</div><div>&nbsp;</div><div>BTW, I=
 uploaded my sixth draft earlier today at my GitHub repository.</div><div>&=
nbsp;</div><div>Daryle W.</div><div>&nbsp;</div></div>

<p></p>

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

------=_Part_2087_19526543.1379808782128--

.