------=_Part_190_1768627184.1429241919635
Content-Type: multipart/alternative;
 boundary="----=_Part_191_1995923361.1429241919635"

------=_Part_191_1995923361.1429241919635
Content-Type: text/plain; charset=UTF-8

I very much like the generality with which this proposal considers the
problem of multi-dimensional arrays.  It is obviously not really a complete
proposal in itself, but it is particularly valuable in pointing out the
issues that are not really addressed by n4346, and which are really quite
critical to consider before standardizing anything.

Even though it is not a complete proposal, I do have some particular
comments on it, that I'd be interested in discussing with other members of
this forum:

- Something called shared_array ought to be fully general like shared_ptr,
in that it can be constructed from an arbitrary memory pointer and deleter
(possibly directly from a shared_ptr, and using an actual shared_ptr as the
internal representation).  A constructor or free function for actually
allocating an array based on a supplied or default constructor is of course
very necessary as well, but that should just be a convenience interface on
top of the primary (pointer, deleter) interface.

- Something called weak_array ought to behave like weak_ptr for
consistency.  In particular the data should not be accessible directly,
only by first calling lock and getting a shared_array.  This type would be
used only when the user actually needs the safety and semantics implied by
weak_ptr.  There should be a separate array_view type that just uses a raw
pointer, and can be implicitly constructed from a shared_array, when the
user knows the underlying memory will stay valid.  Trying to use weak_array
for both purposes seems like a bad idea.

- While the generic layout support is a very interesting direction, I worry
that it may be too opaque/high-level to actually be of use.  It seems that
virtually every operation on an multi-dimensional array, e.g. subscripting,
slicing, transposing/permuting dimensions, efficient iteration, would have
to be implemented separately for each layout type. Certainly if all
operations are implemented for all layout types, the result is very useful
to users, but this doesn't really scale: if I want to add a new operation,
I have to implement it for each layout type, and if I want to add a new
layout type, I need to also implement all of the operations that I want to
use.  Potentially this level of generality is just too much, and it makes
sense to restrict to only strided layouts (and exclude things like tiled
layouts), with possibly some additional information known at compile time
(e.g. that it is in fact a C or Fortran layout).  This is a sufficiently
rich abstraction that it is possible in many cases to write a generic
implementation.

--

---
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_191_1995923361.1429241919635
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I very much like the generality with which this proposal c=
onsiders the problem of multi-dimensional arrays.&nbsp; It is obviously not=
 really a complete proposal in itself, but it is particularly valuable in p=
ointing out the issues that are not really addressed by n4346, and which ar=
e really quite critical to consider before standardizing anything.<br><br>E=
ven though it is not a complete proposal, I do have some particular comment=
s on it, that I'd be interested in discussing with other members of this fo=
rum:<br><br>- Something called shared_array ought to be fully general like =
shared_ptr, in that it can be constructed from an arbitrary memory pointer =
and deleter (possibly directly from a shared_ptr, and using an actual share=
d_ptr as the internal representation).&nbsp; A constructor or free function=
 for actually allocating an array based on a supplied or default constructo=
r is of course very necessary as well, but that should just be a convenienc=
e interface on top of the primary (pointer, deleter) interface.<br><br>- So=
mething called weak_array ought to behave like weak_ptr for consistency.&nb=
sp; In particular the data should not be accessible directly, only by first=
 calling lock and getting a shared_array.&nbsp; This type would be used onl=
y when the user actually needs the safety and semantics implied by weak_ptr=
..&nbsp; There should be a separate array_view type that just uses a raw poi=
nter, and can be implicitly constructed from a shared_array, when the user =
knows the underlying memory will stay valid.&nbsp; Trying to use weak_array=
 for both purposes seems like a bad idea.<br><br>- While the generic layout=
 support is a very interesting direction, I worry that it may be too opaque=
/high-level to actually be of use.&nbsp; It seems that virtually every oper=
ation on an multi-dimensional array, e.g. subscripting, slicing, transposin=
g/permuting dimensions, efficient iteration, would have to be implemented s=
eparately for each layout type. Certainly if all operations are implemented=
 for all layout types, the result is very useful to users, but this doesn't=
 really scale: if I want to add a new operation, I have to implement it for=
 each layout type, and if I want to add a new layout type, I need to also i=
mplement all of the operations that I want to use.&nbsp; Potentially this l=
evel of generality is just too much, and it makes sense to restrict to only=
 strided layouts (and exclude things like tiled layouts), with possibly som=
e additional information known at compile time (e.g. that it is in fact a C=
 or Fortran layout).&nbsp; This is a sufficiently rich abstraction that it =
is possible in many cases to write a generic implementation.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_191_1995923361.1429241919635--
------=_Part_190_1768627184.1429241919635--

.