Cfxtrjtrk

I implemented a 2D counterpart of std::array named array2d in C++17. It is an aggregate like std::array, and provides similar interface. The goal is that if you know how to use std::array, then you will find yourself at home using array2d. Any comments are welcome :) For better viewing experience with highlighting, you can refer to this GitHub page.

#include <cstddef>

#include <array>

#include <iterator>



template <typename T, std::size_t N0, std::size_t N1>

struct array2d {

  using row_t = std::array<T, N1>;

  inline static constexpr std::array sizes{ N0, N1 };



  static constexpr std::size_t size() noexcept { return N0 * N1; }

  static constexpr bool empty() noexcept { return !size(); }



  T& at(std::size_t i, std::size_t j) { return data_.at(i).at(j); }

  const T& at(std::size_t i, std::size_t j) const { return data_.at(i).at(j); }



  row_t& operator(std::size_t i) noexcept { return data_[i]; }

  const row_t& operator(std::size_t i) const noexcept { return data_[i]; }



  T& front() { return data_.front().front(); }

  const T& front() const { return data_.front().front(); }



  T& back() { return data_.back().back(); }

  const T& back() const { return data_.back().back(); }



  T* data() noexcept { return data_.data()->data(); }

  const T* data() const noexcept { return data_.data()->data(); }



  T* begin() noexcept { return data(); }

  const T* begin() const noexcept { return data(); }



  T* end() noexcept { return data() + size(); }

  const T* end() const noexcept { return data() + size(); }



  auto rbegin() noexcept { return std::make_reverse_iterator(end()); }

  auto rbegin() const noexcept { return std::make_reverse_iterator(end()); }



  auto rend() noexcept { return std::make_reverse_iterator(begin()); }

  auto rend() const noexcept { return std::make_reverse_iterator(begin()); }



  void fill(const T& v) {

    for (auto& row : data_) {

      row.fill(v);

    }

  }



  friend void swap(array2d& a, array2d& b) { a.data_.swap(b.data_); }



  std::array<row_t, N0> data_;

};

Let me collect a couple of thoughts here.

• 
  

  Aggregate initialization currently works like this:

  
  
  

  array2d<int, 2, 2> a{{1, 2, 3, 4}};
  
  

  
  
  

  but wouldn't it be favorable to allow for

  
  
  

  array2d<int, 2, 2> a{{1, 2}, {3, 4}};
  
  

  
  



• std::array::at performs bound checking and throws upon an out of bounds index. When your intention is to stick with the std::array interface, you should do the same.




• If you want the container to be standard-compliant, there are some type aliases missing and maybe more. In particular, there are no cbegin(), cend(), crbegin(), crend() member functions. Is this intended?




• You implicitly use row-major order. Are you sure everyone expects this? Users familiar with Eigen and their fixed size matrices might at least want to customize row-/column-major ordering, e.g. Eigen::Matrix<int, 2, 2, Eigen::ColMajor> m;



• 
  

  A range based for loop will considerably differ from a manual loop over rows and columns. Example:

  
  
  

  // Loop over elements, transposed access. Requires nested loop.
  
  for (std::size_t i = 0; i < 2; ++i)
  
     for (std::size_t j = 0; j < 2; ++j)
  
        std::cout << a[j][i] << "n";
  
  
  
  // Loop over elements, tranposed access impossible. Only one loop.
  
  for (const auto& i : d)
  
      std::cout << i << "n";
  
  

  
  
  

  This is slightly unintuitive. Shouldn't the range based for loop require a nested loop as well?

  
  



• The static data member sizes is not used anywhere.

Getting a two-dimensional array to work is not that much of an effort. Getting the semantics right is hard. Sticking to the std::array interface is a good goal when ease of use is intended for those familiar with the std::array template. But the additional dimension pulls in requirements that can't be tackled with the concepts of std::array. I would recommend having a look at established linear algebra libraries and their fixed size matrices. Also, the mdspan proposal for a multi-dimensional view on array types might be a good read.