Does anybody know why boost::array does not support multiple dimensions?
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<std::array<int,3>, 4> arr; I would like to have this boost::array<int,4,3> 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.
sob., 1 sty 2022 o 11:42 Ivan Matek via Boost <boost@lists.boost.org> 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<std::array<int,3>, 4> arr;
I would like to have this boost::array<int,4,3> 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
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::vector<std::string> and vector<string> are fine, but I cant hate std::vector<string> or vector<std::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. :/ :)
On Sun, Jan 2, 2022 at 9:40 AM Ivan Matek <libbooze@gmail.com> 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... :)
Update on update: John showed me that all what we need is more cowbe... I mean curlies. :) arr<int, 3, 2> 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 <libbooze@gmail.com> 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... :)
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<int, 3, 2> 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.
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<int,3> 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. :)
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
On Sun, Jan 2, 2022 at 3:21 PM John Maddock via Boost <boost@lists.boost.org> 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<int, 3, 2> a2 = {{10,20},{30,40}, {50,60}};
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 <boost/container/static_vector.hpp> #include <boost/container/small_vector.hpp> #include <boost/multi_array.hpp> #include <fmt/ranges.h> 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<float, K*L*M> backing(NUM); // or small_vector that *can* optionally allocate std::iota(std::begin(backing), std::end(backing), 0); boost::multi_array_ref<float, 3> 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...).
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
On Sun, Jan 2, 2022 at 3:21 PM Seth via Boost <boost@lists.boost.org> 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.
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<std::array<int,3>, 4> arr;
I would like to have this boost::array<int,4,3> 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?
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<array<T, N>, 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
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<std::array<int,3>, 4> arr;
I would like to have this boost::array<int,4,3> arr;
boost::array<int[4], 3> should work, more or less. I've always felt that the syntax should have been array<int[3]> instead, which naturally extends to array<int[4][3]>, but it's too late now.
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<array<T, N>, 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
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<array<T, N>, 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
Do you really need a nested array? You could also use a flat array and an adapter for the index, e,g, template<typename T, typename U> concept is_convertible_to = std::is_convertible_v<T, U>; template<typename T, typename Index> struct array_adapter { std::array<T, Index::size()> m_a; constexpr array_adapter(is_convertible_to<T> auto ... t) requires (sizeof...(t) == Index::size()): m_a{t ...} {} constexpr T operator()(is_convertible_to<std::size_t> auto ... i) const requires (sizeof...(i) == Index::dim()) { return m_a[Index{}(i...)]; } constexpr T& operator()(is_convertible_to<std::size_t> auto ... i) requires (sizeof...(i) == Index::dim()) { return m_a[Index{}(i...)]; } }; For Index, you might e.g. use template<std::size_t ... N> struct row_major_index { static constexpr std::size_t size() { return (N*...); } template<std::size_t i> constexpr static std::size_t first(is_convertible_to<std::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_to<std::size_t> auto... n) { return first<sizeof...(n)-1>(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<double, row_major_index<N1,N2,N3>> 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<typename T, typename Index, typename Policy> struct array_index_adapter { ... }; Helmut
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.
Von: "Seth via Boost" <boost@lists.boost.org>
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
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
Von: "Seth via Boost" <boost@lists.boost.org> 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
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).
Von: "Ivan Matek" <libbooze@gmail.com> On Fri, Jan 7, 2022 at 8:16 AM Helmut Zeisel via Boost <boost@lists.boost.org[mailto: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.
Yes. What I have in mind, however, (as I mentioned already ealier) is some general adapter class template<typename T, typename Index, typename Policy> 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
On Jan 8, 2022, at 9:46 PM, Helmut Zeisel via Boost <boost@lists.boost.org> wrote:
Von: "Ivan Matek" <libbooze@gmail.com> On Fri, Jan 7, 2022 at 8:16 AM Helmut Zeisel via Boost <boost@lists.boost.org[mailto: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.
Yes.
What I have in mind, however, (as I mentioned already ealier) is some general adapter class
template<typename T, typename Index, typename Policy> 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
Von: "Marshall Clow via Boost" <boost@lists.boost.org>
On Fri, Jan 7, 2022 at 8:16 AM Helmut Zeisel via Boost <boost@lists.boost.org[mailto:boost@lists.boost.org]> wrote:
What I have in mind, however, (as I mentioned already ealier) is some general adapter class
template<typename T, typename Index, typename Policy> 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<pointer, __map_acc_pair_t> __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
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
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
On Mon, Jan 3, 2022 at 5:09 AM Peter Dimov via Boost <boost@lists.boost.org> wrote:
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<int, 2, 2, 3> a{{ { { 1, 2, 3 }, { 4, 5, 6 } }, { { 7, 8, 9 }, { 10, 11, 12 } } }}; into array<int, 2, 2, 3> 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<int, 2, 2, 3> a223{ { 1, 2, 3 }, { 4, 5, 6 } , { 7, 8, 9 }, { 10, 11, 12 } }; // Unfortunately no way to group stuff with {} for more clarity // array<int, 2, 2, 3> a223_grouped{ // {{ 1, 2, 3 }, { 4, 5, 6 }} , // {{ 7, 8, 9 }, { 10, 11, 12 } } //};
Ivan Matek wrote:
On Mon, Jan 3, 2022 at 5:09 AM Peter Dimov via Boost <boost@lists.boost.org <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.
On Mon, Jan 3, 2022 at 11:51 AM Peter Dimov <pdimov@gmail.com> 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.
On Sat, Jan 1, 2022 at 10:42 AM Ivan Matek via Boost <boost@lists.boost.org> wrote:
I would like to have this boost::array<int,4,3> 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.
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
On Sun, Jan 9, 2022 at 10:12 AM Ivan Matek <libbooze@gmail.com> 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.
On Sun, Jan 9, 2022 at 11:24 AM Brian Smith <bjs3141@gmail.com> 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 {}.
On Sun, Jan 9, 2022 at 10:28 AM Ivan Matek <libbooze@gmail.com> wrote:
On Sun, Jan 9, 2022 at 11:24 AM Brian Smith <bjs3141@gmail.com> 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 :)
participants (10)
-
Andrey Semashev -
Andrzej Krzemienski -
Brian Smith -
Helmut Zeisel -
Ivan Matek -
John Maddock -
Marshall Clow -
Peter Dimov -
Robert Ramey -
Seth