| commit | 9fbffbbfacbff555c92a2b6aca4fba5ef07b3feb | |
| author | Roland Schulz <roland.schulz@intel.com> | |
| Tue, 3 Oct 2017 19:40:09 +0000 (3 12:40 -0700) | ||
| committer | Berk Hess <hess@kth.se> | |
| Wed, 4 Oct 2017 14:59:06 +0000 (4 16:59 +0200) | ||
| tree | e403ac91accf94c7bcf39edc343d92fbefcc13d3 | treesnapshot (tar.gz zip) |
| parent | c546855b919109d6f18e7f3ae86f947b757e0e38 | commitdiff |
Allow non-const access for const ArrayRef
const ArrayRef<T> should not mean that the data contained in the range
is const. If it were used that way, it behave very purely as a const
object because if it is copied it looses its const. Instead
ConstArrayRef<T> (or potentially ArrayRef<const T>) should be used
consistently. This makes having const versions of operator[]/at and
begin/end/front/back confusing and inconsistent. The meaning of
const ArraryRef should be that reassigning a new range to the ref
is not allowed. To be consistent, even for a const ArrayRef non-const
access to the data should be allowed.
Change-Id: I7e921c1a5562889bfd26eb0688b475406c87857c
const ArrayRef<T> should not mean that the data contained in the range
is const. If it were used that way, it behave very purely as a const
object because if it is copied it looses its const. Instead
ConstArrayRef<T> (or potentially ArrayRef<const T>) should be used
consistently. This makes having const versions of operator[]/at and
begin/end/front/back confusing and inconsistent. The meaning of
const ArraryRef should be that reassigning a new range to the ref
is not allowed. To be consistent, even for a const ArrayRef non-const
access to the data should be allowed.
Change-Id: I7e921c1a5562889bfd26eb0688b475406c87857c
| src/gromacs/utility/arrayref.h | diffblobblamehistory |