Does anybody know why boost::array does not support multiple dimensions?

newer
[GSoC 2022] [Graph] Potential...

Ivan Matek

1 Jan 2022 1 Jan '22

10:42 a.m.

I don't know much about library development, but with variadic templates does not seem so hard, although every library development is much harder than regular user code. Sure boost::array probably wants to support ancient compilers, but variadic version could exist only for "modern"(I do not consider >10y old standards modern) C++. I found this std:: proposal http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3794.html#Ch05 from 9 y ago, also author seemed to have some working impl on github https://github.com/CTMacUser/ArrayMD/tree/master/include/boost/container But I guess none of it ever progressed. Does anybody knows more about this? It is not trivial since there are probably a ton of edge cases, typdefs, semantics(what should size return?, I would say array of dims) to deal with, but I think it would be a nice extension since I find nested std::array hideous (with current syntax), e.g.: std::array, 4> arr; I would like to have this boost::array arr; P.S. I know I can use Eigen or some other library, but I think if not std then at least boost should support simple way to have multidim arrays.

Show replies by date

Andrzej Krzemienski

1 Jan 1 Jan

1:10 p.m.

sob., 1 sty 2022 o 11:42 Ivan Matek via Boost napisał(a):

...

I don't know much about library development, but with variadic templates does not seem so hard, although every library development is much harder than regular user code.

Sure boost::array probably wants to support ancient compilers, but variadic version could exist only for "modern"(I do not consider >10y old standards modern) C++.

I found this std:: proposal http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3794.html#Ch05 from 9 y ago, also author seemed to have some working impl on github https://github.com/CTMacUser/ArrayMD/tree/master/include/boost/container

But I guess none of it ever progressed.

Does anybody knows more about this? It is not trivial since there are probably a ton of edge cases, typdefs, semantics(what should size return?, I would say array of dims) to deal with, but I think it would be a nice extension since I find nested std::array hideous (with current syntax), e.g.:

std::array, 4> arr;

I would like to have this boost::array arr;

P.S. I know I can use Eigen or some other library, but I think if not std then at least boost should support simple way to have multidim arrays.

What is your use case? Maybe you are looking for a matrix or tensor library? Maybe Boost Basic Linear Algebra would work for you? https://www.boost.org/doc/libs/1_78_0/libs/numeric/ublas/doc/index.html Regards, &rzej;

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Ivan Matek

2 Jan 2 Jan

8:40 a.m.

Answering multiple people in one mail to prevent me spamming this topic, let me know if prefer multiple mails @ Andrzej Sometimes I need the multidim array of statically known dims and I find Eigen or some of boost stuff you suggested an overkill for such basic functionality. This is philosophical claim(what is an overkill) and not something measurable, but I do feel that way. @Andrey I believe you are right, seems too complex, shame, although I believe it might possible to hack the array to be recursively defined, but for some reason agg initialization does not seem to work... :/ https://godbolt.org/z/Pzrbh49WK There is probably a ton of other issues, once again C++ turns out to be much harder than I assumed. :( But at least you can see API I would like to see. @pdimov I agree with your original idea, but we are where we are and I prefer not to mix existing boost/std::array and C array syntax. It just looks horrible for me, in same way that std::vectorstd::string and vector<string> are fine, but I cant hate std::vector<string> or vectorstd::string :) @John In godbolt link above you can see what I would like to see for basic API, basically struct containing N-1 dim array of itself unless we are at 1D level, then obviously we contain array of T. As mentioned I am not some C++ expert, but this is the most natural thing I could think of. @Robert I think multi_array is still heap allocating, but unlike vector<vector> it does one heap allocation so it is more efficient. to recap: if somebody thinks this is possible and is interested in working on this please let me know I would be happy to work on this, but I think this is out my capabilities to do on my own. :/ :)

Ivan Matek

8:51 a.m.

On Sun, Jan 2, 2022 at 9:40 AM Ivan Matek wrote:

...

@Andrey I believe you are right, seems too complex, shame, although I believe it might possible to hack the array to be recursively defined, but for some reason agg initialization does not seem to work... :/

Update: it seems agg init does not work for std::array also when nested... 💔 https://godbolt.org/z/9Moz19dhW https://stackoverflow.com/questions/28541488/nested-aggregate-initialization... :)

Ivan Matek

10:03 a.m.

Update on update: John showed me that all what we need is more cowbe... I mean curlies. :) arr a2_nested_init{ {{ {{1,2}}, {{3,4}},{{5,6}} }} }; https://godbolt.org/z/Kzs6xbo5T In my opinion this is very ugly since end users will just get angry and frustrated and switch to something else most of the time, but at least it seems equally ugly as nested std::array, so no "regression". On Sun, Jan 2, 2022 at 9:51 AM Ivan Matek wrote:

...

Update: it seems agg init does not work for std::array also when nested... 💔 https://godbolt.org/z/9Moz19dhW

https://stackoverflow.com/questions/28541488/nested-aggregate-initialization... :)

Andrey Semashev

12:44 p.m.

On 1/2/22 13:03, Ivan Matek wrote:

...

Update on update: John showed me that all what we need is more cowbe... I mean curlies. :) arr a2_nested_init{ {{ {{1,2}}, {{3,4}},{{5,6}} }} }; https://godbolt.org/z/Kzs6xbo5T https://godbolt.org/z/Kzs6xbo5T

In my opinion this is very ugly since end users will just get angry and frustrated and switch to something else most of the time, but at least it seems equally ugly as nested std::array, so no "regression".

I didn't think about the recursion approach, so I suppose you can have a generic implementation. Though it would seem it should be rather expensive in terms of compile times. Here's a prototype: https://godbolt.org/z/sj1Trs1TE It would need more work if you want references and iterators to work in terms of arr<> and not the built-in arrays.

Ivan Matek

2:18 p.m.

On Sun, Jan 2, 2022 at 1:45 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

It would need more work if you want references and iterators to work in terms of arr<> and not the built-in arrays.

Thank you for the implementation, but I still think there are major issues that make this "extension" unlikely to be usable. I think the nested aggregate initialization requiring a ton of {} would be bad for "normal" users (and AFAIK that is core language thing, so it is not me or any other library writer can just fix it), also I am not familiar with deduction guides so it may be hard/impossible to make multidimensional boost::array work nice with CTAD, for example this works fine in recent C++ std::array arr{1,2,3}; // std::array I have no idea if that be possible for multidimensional arrays, not to mention that even if it is it is very hard for users to get it right due to mentioned {} spam required... So in the end a bit of a disappointing development, but I guess now I learned why this is not as trivial as it looked. :)

John Maddock

2:20 p.m.

On 02/01/2022 14:18, Ivan Matek via Boost wrote:

...

On Sun, Jan 2, 2022 at 1:45 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...
It would need more work if you want references and iterators to work in terms of arr<> and not the built-in arrays.

Thank you for the implementation, but I still think there are major issues that make this "extension" unlikely to be usable.

Just thinking out loud here, can std::initializer_list help? -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Ivan Matek

2:58 p.m.

On Sun, Jan 2, 2022 at 3:21 PM John Maddock via Boost wrote:

...

Just thinking out loud here, can std::initializer_list help?

You mean adding a constructor with that takes the std::initializer_list of N-1 dimensional arrays? That *might *work, but it breaks the "aggregate-ness" since aggregate can not have user provided constructors :/ https://godbolt.org/z/zfrba368M Shame since I ♥ this syntax: arr a2 = {{10,20},{30,40}, {50,60}};

Seth

2:13 p.m.

On Sun, Jan 2, 2022, at 9:40 AM, Ivan Matek via Boost wrote:

...

Answering multiple > @Robert I think multi_array is still heap allocating, but unlike vector<vector> it does one heap allocation so it is more efficient.

Taking the liberty to appropriate that as a response to my post as well: https://godbolt.org/z/o4x6vGhW5 #include #include #include #include namespace bc = boost::container; int main() { constexpr auto K=2, L=3, M=5, NUM=K*L*M; using boost::extents; using boost::indices; bc::static_vector backing(NUM); // or small_vector that *can* optionally allocate std::iota(std::begin(backing), std::end(backing), 0); boost::multi_array_ref arr(backing.data(), extents[K][L][M]); fmt::print("K×L×M: {}\n", arr); arr.reshape(std::array{L,M,K}); fmt::print("L×M×K: {}\n", arr); using range = boost::multi_array_types::index_range; fmt::print("3d slice: {}\n", arr[indices[range(2, 3)][range(0, M, 2)][range()]]); fmt::print("2d slice: {}\n", arr[indices[range(2, 3)][range(0, M, 2)][1]]); } This demos some of the Multi-Array interface with zero dynamic allocation. The library has more expressive indexing/layout options (see "general storage ordering" https://www.boost.org/doc/libs/1_78_0/libs/multi_array/doc/user.html#sec_sto...).

Seth

2:16 p.m.

On Sun, Jan 2, 2022, at 3:13 PM, Seth wrote:

...

Taking the liberty to appropriate that as a response to my post as well: https://godbolt.org/z/o4x6vGhW5

I omitted the output of the sample: K×L×M: [[[0, 1, 2, 3, 4], [5, 6, 7, 8, 9], [10, 11, 12, 13, 14]], [[15, 16, 17, 18, 19], [20, 21, 22, 23, 24], [25, 26, 27, 28, 29]]] L×M×K: [[[0, 1], [2, 3], [4, 5], [6, 7], [8, 9]], [[10, 11], [12, 13], [14, 15], [16, 17], [18, 19]], [[20, 21], [22, 23], [24, 25], [26, 27], [28, 29]]] 3d slice: [[[20, 21], [24, 25], [28, 29]]] 2d slice: [[21, 25, 29]] Seth

Ivan Matek

2:34 p.m.

On Sun, Jan 2, 2022 at 3:21 PM Seth via Boost wrote:

...

This demos some of the Multi-Array interface with zero dynamic allocation. The library has more expressive indexing/layout options (see "general storage ordering" https://www.boost.org/doc/libs/1_78_0/libs/multi_array/doc/user.html#sec_sto... ).

Nice that I learned about this since I might need it in the future, but it is not really what I want if I really understand how it works. This is something like a string_view/span (nonowning type). I would just want a simple no heap alloc value type like std::array but with multiple dimensions.

Andrey Semashev

1 Jan 1 Jan

1:47 p.m.

On 1/1/22 13:42, Ivan Matek via Boost wrote:

...

I don't know much about library development, but with variadic templates does not seem so hard, although every library development is much harder than regular user code.

Sure boost::array probably wants to support ancient compilers, but variadic version could exist only for "modern"(I do not consider >10y old standards modern) C++.

I found this std:: proposal http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3794.html#Ch05 from 9 y ago, also author seemed to have some working impl on github https://github.com/CTMacUser/ArrayMD/tree/master/include/boost/container

But I guess none of it ever progressed.

Does anybody knows more about this? It is not trivial since there are probably a ton of edge cases, typdefs, semantics(what should size return?, I would say array of dims) to deal with, but I think it would be a nice extension since I find nested std::array hideous (with current syntax), e.g.:

std::array, 4> arr;

I would like to have this boost::array arr;

P.S. I know I can use Eigen or some other library, but I think if not std then at least boost should support simple way to have multidim arrays.

To my knowledge, this cannot be supported in a generic manner as a variadic sequence cannot be expanded into a sequence of array dimensions. Therefore the support would require a set of template specializations up to a predefined limit, a-la Boost.MPL and other C++03 libraries. The next thing is the result of operator[], which can no longer be a simple reference. The reference would have to retain information of the lower level dimensions in order to apply the index correctly. Then there are iterators and related APIs (front(), back(), size()) which no longer make sense, unless applied to the last dimension. Either that API has to be removed or redefined with new semantics. The bottom line is that such a multi-dimensional array would be a much more complicated component that is drastically different from the one-dimensional array. At the same time, array<> is supposed to be a thin and lightweight replacement for the language built-in arrays. IMO, it is not a worthy tradeoff. BTW, you still have the multidimensional language built-in arrays. Why can't you use those?

John Maddock

4:56 p.m.

...

The bottom line is that such a multi-dimensional array would be a much more complicated component that is drastically different from the one-dimensional array. At the same time, array<> is supposed to be a thin and lightweight replacement for the language built-in arrays. IMO, it is not a worthy tradeoff.

BTW, you still have the multidimensional language built-in arrays. Why can't you use those?

They're not as convenient or safe I would say. Interestingly Boost.Math uses 2-D arrays all over the place for test data, and I've always used an array, M> and never really thought about an alternative, but IMO it does rather make sense. Dereferenced iterators and operator [] would return a simple "smart index" object I guess, similar to Boost's Multi-Array. BTW the catch with multi-array is that it's dynamically allocated (more like a vector), where as the nice feature of std::array is the all static, constexpr initialization. So yes, I can see the point of view of the OP, and I don't even think it would be that hard or large to implement, it just doesn't get over the "need to have" barrier for me to want to do it ;) Best, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Peter Dimov

2:21 p.m.

Ivan Matek wrote:

...

I don't know much about library development, but with variadic templates does not seem so hard, although every library development is much harder than regular user code.

Sure boost::array probably wants to support ancient compilers, but variadic version could exist only for "modern"(I do not consider >10y old standards modern) C++.

I found this std:: proposal http://www.open- std.org/JTC1/SC22/WG21/docs/papers/2013/n3794.html#Ch05 from 9 y ago, also author seemed to have some working impl on github https://github.com/CTMacUser/ArrayMD/tree/master/include/boost/contain er

But I guess none of it ever progressed.

Does anybody knows more about this? It is not trivial since there are probably a ton of edge cases, typdefs, semantics(what should size return?, I would say array of dims) to deal with, but I think it would be a nice extension since I find nested std::array hideous (with current syntax), e.g.:

std::array, 4> arr;

I would like to have this boost::array arr;

boost::array should work, more or less. I've always felt that the syntax should have been array instead, which naturally extends to array, but it's too late now.

Seth

2:58 p.m.

I can't speak to the reasons why it's not in `boost::array` (but note that nothing like that ever got standardized either). I suppose that the equivalent to `T[N][M]` is already `array, M>`. Also, the obvious suggestion would be to use Boost MultiArray https://www.boost.org/doc/libs/1_78_0/libs/multi_array/doc/user.html

Robert Ramey

6:05 p.m.

On 1/1/22 6:58 AM, Seth via Boost wrote:

...

I can't speak to the reasons why it's not in `boost::array` (but note that nothing like that ever got standardized either).

I suppose that the equivalent to `T[N][M]` is already `array, M>`.

Also, the obvious suggestion would be to use Boost MultiArray https://www.boost.org/doc/libs/1_78_0/libs/multi_array/doc/user.html

Hmmm - looking at the docs for multi_array (which I had forgotten about) makes me think this is the solution you should look into first. It's dated 2006 and/but has the imprimatur of some of our best developers. It's a little hard to understand from the docs. Perhaps it would be a worthwhile investment to use some modern TMP to improve somewhat the interface/API and of course sync up the docs accordingly. Sounds to me like a small yet very worthwhile and interesting project. Robert Ramey

Helmut Zeisel

2 Jan 2 Jan

9:03 p.m.

Do you really need a nested array? You could also use a flat array and an adapter for the index, e,g, template concept is_convertible_to = std::is_convertible_v; template struct array_adapter { std::array m_a; constexpr array_adapter(is_convertible_to<T> auto ... t) requires (sizeof...(t) == Index::size()): m_a{t ...} {} constexpr T operator()(is_convertible_tostd::size_t auto ... i) const requires (sizeof...(i) == Index::dim()) { return m_a[Index{}(i...)]; } constexpr T& operator()(is_convertible_tostd::size_t auto ... i) requires (sizeof...(i) == Index::dim()) { return m_a[Index{}(i...)]; } }; For Index, you might e.g. use template struct row_major_index { static constexpr std::size_t size() { return (N*...); } template constexpr static std::size_t first(is_convertible_tostd::size_t auto... n) { if constexpr(i == 0) { return std::get<0>(std::make_tuple(n...)); } else { return std::get<i>(std::make_tuple(n...))+std::get<i>(std::make_tuple(N...))*f irst<i-1>(n...); } } constexpr std::size_t operator()(is_convertible_tostd::size_t auto... n) { return first(n...); } static constexpr std::size_t dim() { return sizeof...(N); } }; This can be used as follows: nt main() { static const int N1 = 2; static const int N2 = 3; static const int N3 = 4; array_adapter> a{111.,112.,113.,114., 121.,122.,123.,124., 131.,132.,133.,134., 211.,212.,213.,214., 221.,222.,223.,224., 231.,232.,233.,234.}; for(int n1=0; n1 != N1; ++n1) { for(int n2=0; n2!=N2; ++n2) { for(int n3=0; n3!=N3; ++n3) { std::cout << "a(" << n1 << "," << n2 << "," << n3 << ")=" << a(n1,n2,n3) << std::endl; } } } return 0; } Of course, this could be generaized to different types of arrays (e.g. std:.vecrtor) usng some policy class and template struct array_index_adapter { ... }; Helmut

Seth

10:59 p.m.

On Sun, Jan 2, 2022, at 10:03 PM, Helmut Zeisel via Boost wrote:

...

Do you really need a nested array?

You could also use a flat array and an adapter for the index, e,g,

I feel this is essentially what I have been suggesting, except reinventing the wheel for indexing the flat storage. I predict it's "not welcome" for the same reasons then.

Helmut Zeisel

6 Jan 6 Jan

6:47 a.m.

...

Von: "Seth via Boost"

On Sun, Jan 2, 2022, at 10:03 PM, Helmut Zeisel via Boost wrote:

...
Do you really need a nested array?

You could also use a flat array and an adapter for the index, e,g,

...

except reinventing the wheel for indexing the flat storage.

To avoid further reinventing the wheel: is there some multi dimensional array index adapter available in boost or in some other free librarry? Helmut

Seth

9:21 a.m.

On Thu, Jan 6, 2022, at 7:47 AM, Helmut Zeisel via Boost wrote:

...

To avoid further reinventing the wheel: is there some multi dimensional array index adapter available in boost or in some other free librarry?

Helmut

Other than boost::multi_array_ref I posted earlier in this conversation (https://godbolt.org/z/o4x6vGhW5) - I don't really know. Is there something wrong with that one, though? Seth

Helmut Zeisel

7 Jan 7 Jan

7:11 a.m.

...

Von: "Seth via Boost" On Thu, Jan 6, 2022, at 7:47 AM, Helmut Zeisel via Boost wrote:

...
To avoid further reinventing the wheel: is there some multi dimensional array index adapter available in boost or in some other free librarry?

Helmut

Other than boost::multi_array_ref I posted earlier in this conversation (https://godbolt.org/z/o4x6vGhW5) - I don't really know. Is there something wrong with that one, though?

Seth

I do not know whether boost::multi_array_ref is suitable fpr the purposes of the original question. For more general applications, according to my current understanding, boost::multi_array_ref has several restrictions: 1) boost::multi_array_ref does not own the memory (which creates at least the memory overhead of one pointer) 2) boost::multi_array_ref is not constexpr (maybe this can be fixed) 3) boost::multi_array_ref only works for a contiguous block of elements 4) boost::multi_array_ref supports only rectangular shapes (no other shapres like e.g. triangular matrices) Helmut

Ivan Matek

12:54 p.m.

On Fri, Jan 7, 2022 at 8:16 AM Helmut Zeisel via Boost < boost@lists.boost.org> wrote:

...

1) boost::multi_array_ref does not own the memory (which creates at least the memory overhead of one pointer)

AFAIK boost::multi_array (no _ref suffix) owns memory, but it still does 1 heap allocation. Still much better than vector<vector> that does many(one for each inner vector).

Helmut Zeisel

9 Jan 9 Jan

5:46 a.m.

...

Von: "Ivan Matek" On Fri, Jan 7, 2022 at 8:16 AM Helmut Zeisel via Boost wrote:

...
1) boost::multi_array_ref does not own the memory (which creates at least the memory overhead of one pointer) AFAIK boost::multi_array (no _ref suffix) owns memory, but it still does 1 heap allocation.

Yes. What I have in mind, however, (as I mentioned already ealier) is some general adapter class template struct array_index_adapter { ... }; that can apply different types of indices (row major, column major, triangular ...) to different containers (stack allocated, heap allocated, mixed like boost::small_vector etc). Helmut

Marshall Clow

6:53 a.m.

On Jan 8, 2022, at 9:46 PM, Helmut Zeisel via Boost wrote:

...

...
Von: "Ivan Matek" On Fri, Jan 7, 2022 at 8:16 AM Helmut Zeisel via Boost wrote:

...
1) boost::multi_array_ref does not own the memory (which creates at least the memory overhead of one pointer) AFAIK boost::multi_array (no _ref suffix) owns memory, but it still does 1 heap allocation.

Yes.

What I have in mind, however, (as I mentioned already ealier) is some general adapter class

template struct array_index_adapter { ... };

that can apply different types of indices (row major, column major, triangular ...) to different containers (stack allocated, heap allocated, mixed like boost::small_vector etc).

You should look at mdspan, then. It’s been in use at various national labs for many years, and is being proposed for a future standard. A reference implementation is here: https://github.com/kokkos/mdspan — Marshall

Helmut Zeisel

3:44 p.m.

...

Von: "Marshall Clow via Boost"

...
On Fri, Jan 7, 2022 at 8:16 AM Helmut Zeisel via Boost wrote:

...

...
What I have in mind, however, (as I mentioned already ealier) is some general adapter class

template struct array_index_adapter { ... };

that can apply different types of indices (row major, column major, triangular ...) to different containers (stack allocated, heap allocated, mixed like boost::small_vector etc).

...

You should look at mdspan, then. It’s been in use at various national labs for many years, and is being proposed for a future standard.

...

A reference implementation is here: https://github.com/kokkos/mdspan

mdspan.hpp has the implementation detail::__compressed_pair __members{}; As I understand, "pointer" is restricted to "true" pointers. What I have in mind, however, is "container" instead of pointer. E.g. if "container" is std::vector, it will be a simple multidimensional array. "container" can still be a plain pointer or a smart pointer (or std::reference_wrapper) to some container; then it will be a view. Acutally up to some degree this is also discussed in the mdarray proposal https://isocpp.org/files/papers/D1684R0.html "2.4.2 Analogs in the Standard Library: Container Adapters" but for some reason it is restricted to pointer = Container*; and not pointer = Container; IMHO an adapter can also be done directly for the container itself, not only for a pointer to the container. Helmut

Ivan Matek

3 Jan 3 Jan

3:54 a.m.

On Sun, Jan 2, 2022 at 10:08 PM Helmut Zeisel via Boost < boost@lists.boost.org> wrote:

...

Do you really need a nested array?

Not sure, probably not. First idea was to just reuse/mimic as much as possible from boost/std::array, including the syntax (just add more commas and numbers inside <> to get more dimensions), and also to keep the curly initialization working. I never considered using the view you propose, I presume C++23? std::mdspan is a similar thing, but it obviously does not own the data. https://github.com/kokkos/mdspan/wiki/A-Gentle-Introduction-to-mdspan

Peter Dimov

4:09 a.m.

Ivan Matek wrote:

...

On Sun, Jan 2, 2022 at 10:08 PM Helmut Zeisel via Boost < boost@lists.boost.org> wrote:

...
Do you really need a nested array?

Not sure, probably not. First idea was to just reuse/mimic as much as possible from boost/std::array, including the syntax (just add more commas and numbers inside <> to get more dimensions), and also to keep the curly initialization working.

Just use the remaining array as the value type, as I already suggested. E.g. https://godbolt.org/z/afcMqMqrK

Ivan Matek

10:43 a.m.

On Mon, Jan 3, 2022 at 5:09 AM Peter Dimov via Boost wrote:

...

https://godbolt.org/z/afcMqMqrK

Very nice, I had similar idea in message with this link: https://godbolt.org/z/Kzs6xbo5T but just to double check: no way to make initialization work with less {} because that is a language limitation, right? I mean we could add std::initializer_list constructor but then array is no longer aggregate? In other words no way to turn this array a{{ { { 1, 2, 3 }, { 4, 5, 6 } }, { { 7, 8, 9 }, { 10, 11, 12 } } }}; into array a{ { 1, 2, 3 }, { 4, 5, 6 }, { 7, 8, 9 }, { 10, 11, 12 } }; without breaking aggregate property of array? This is what I tried: https://godbolt.org/z/MoPE8W79v IMAO although this is less friendly for people that want to just initialize md array with bunch of scalar values I think the syntax with using "last level array" is nicer... Obviously I did not think of all the edge cases so my opinion might change rapidly. One big problem I noticed is that we loose ability to group the initialization(you can see the example in godbolt), but here it is inline. array a223{ { 1, 2, 3 }, { 4, 5, 6 } , { 7, 8, 9 }, { 10, 11, 12 } }; // Unfortunately no way to group stuff with {} for more clarity // array a223_grouped{ // {{ 1, 2, 3 }, { 4, 5, 6 }} , // {{ 7, 8, 9 }, { 10, 11, 12 } } //};

Peter Dimov

10:51 a.m.

Ivan Matek wrote:

...

On Mon, Jan 3, 2022 at 5:09 AM Peter Dimov via Boost mailto:boost@lists.boost.org > wrote:

https://godbolt.org/z/afcMqMqrK

Very nice, I had similar idea in message with this link: https://godbolt.org/z/Kzs6xbo5T

but just to double check: no way to make initialization work with less {} because that is a language limitation, right? I mean we could add std::initializer_list constructor but then array is no longer aggregate?

Unfortunately not. Or at least I can't think of a way.

Ivan Matek

11:06 a.m.

On Mon, Jan 3, 2022 at 11:51 AM Peter Dimov wrote:

...

Unfortunately not. Or at least I can't think of a way.

Shame, but that is what I suspected...

To be honest I still like the end result, like might be too strong of a word but I certainly prefer it to nested boost/std::array. Obviously: * due to large differences in syntax it should have a distinct name * I might hit some issues I did not encounter of as of now so that might change my opinion Thanks everybody for your comments and code.

Brian Smith

8 Jan 8 Jan

2:15 a.m.

On Sat, Jan 1, 2022 at 10:42 AM Ivan Matek via Boost wrote:

...

I would like to have this boost::array arr;

How about https://godbolt.org/z/n11xMd7P3. The comparison ops are missing, as well as the iterator code, but that's pretty much the same as the std version for a single dimension array. It was proposed some years ago for inclusion in Boost but stagnated, then got removed.

Ivan Matek

9 Jan 9 Jan

10:12 a.m.

...

How about https://godbolt.org/z/n11xMd7P3. The comparison ops are missing, as well as the iterator code, but that's pretty much the same as the std version for a single dimension array. It was proposed some years ago for inclusion in Boost but stagnated, then got removed.

That still suffers from {} spam, right? No way to nicely initialize it

without a ton of {}? https://godbolt.org/z/jsTEEbcan

Brian Smith

10:24 a.m.

On Sun, Jan 9, 2022 at 10:12 AM Ivan Matek wrote:

...

...
How about https://godbolt.org/z/n11xMd7P3. The comparison ops are missing, as well as the iterator code, but that's pretty much the same as the std version for a single dimension array. It was proposed some years ago for inclusion in Boost but stagnated, then got removed.

That still suffers from {} spam, right? No way to nicely initialize it without a ton of {}? https://godbolt.org/z/jsTEEbcan

The opposite I would say, one set of braces is sufficient.

Ivan Matek

10:28 a.m.

On Sun, Jan 9, 2022 at 11:24 AM Brian Smith wrote: The opposite I would say, one set of braces is sufficient. I dont like debating preferences, but I think good %(maybe not majority but many) of users would agree with that "1D" initialization is harder to read than when you have nested {}.

Brian Smith

10 Jan 10 Jan

1:23 p.m.

On Sun, Jan 9, 2022 at 10:28 AM Ivan Matek wrote:

...

On Sun, Jan 9, 2022 at 11:24 AM Brian Smith wrote: The opposite I would say, one set of braces is sufficient. I dont like debating preferences, but I think good %(maybe not majority but many) of users would agree with that "1D" initialization is harder to read than when you have nested {}.

We apparently have a least one person who's not keen on single brace initialisation. I could counter that (almost) everyone else wouldn't mind since, notwithstanding language limitations, multidimensional arrays can be initialised that way too, but that would be debatable and exactly what we're trying avoid :)

1051

Age (days ago)

1060

Last active (days ago)

List overview

Download

35 comments

10 participants

participants (10)

Andrey Semashev
Andrzej Krzemienski
Brian Smith
Helmut Zeisel
Ivan Matek
John Maddock
Marshall Clow
Peter Dimov
Robert Ramey
Seth