Simplify Cell

* ra/expr.hh (Cell): Minimize base classes. Use the same static/nonstatic
  pattern for all Iterator functions.

Author: lloda

TODO

@@ -83,7 +83,7 @@ checkbox [C-ct] flip TODO
       is that len_s lets me return ANY for some axes and finite for others and to do that with just
       len() would require len(integral constant) overloads possibly -- len(int k) cannot be static
       or not depending on k.
-      - Looked at this again on <2025-09-19 Fri>, added Match::len(is_constant) overload.
+      - Looked at this again on <2025-09-19 Fri>, added Match::len(is_ctype) overload.
     - [ ] Use if consteval to replace rank/rank_s/size/size_s with just rank/size.
     - [ ] Support tuple as a kind of foreign vector
       - [ ] Iterator type for tuple (like Vector for std::vector).
@@ -123,8 +123,8 @@ Some of these aren't bugs in the sense that I expect to solve them, but more lik
       be registered as scalar, but that clashes with how std::ranges sees it. OTOH we don't want
       format(std::string_view) to print it as a foreign vector, so we have an exception for it
       there. As things stand, you can register it as scalar or not.
-  13. [ ] CellBig needs to copy its Dimv in some cases, which also complicates ViewBig::iter<>. Problem
-      is demonstrated in ra-5.cc.
+  13. [ ] Cell needs to copy its Dimv in some dynamic cases, which also complicates
+      ViewBig::iter<>. Problem is demonstrated in ra-5.cc.
   14. [X] Conversion-to-scalar operators for dynamic-rank ViewBig(). I thought this could be
       https://wg21.link/cwg976 but gcc 14 doesn't fix it. There are two issues here, 1) why isn't
       const conversion enough and 2) ambiguity with Small's 'any' constructor (cf 'c++ converting
@@ -208,12 +208,12 @@ Some of these aren't bugs in the sense that I expect to solve them, but more lik
       - [X] make View be View<pointer> and not View<value_type>
   - [X] Support operator <=> <2020-09-15 Tue 13:50>
     - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96278 is annoying
-  - [X] `*(it.flat())` is inefficient for some it, eg CellBig, because we need to create/copy flat
-    in case it gets modified, and then it isn't. Do we need Iterator::operator* ?
+  - [X] `*(it.flat())` is inefficient for some it, eg dynamic dimv Cell, because we need to
+    create/copy flat in case it gets modified, and then it isn't. Do we need Iterator::operator* ?
   - [X] During traversal (ply) the pattern loc = save_location(it); move flat;
     it.set_location(loc); would allow flat to modify the original it. Loc is often just a pointer
     so this would be cheap. The current design is that move flat can't modify it so it has to be a
-    new object. CellBig is one case where that is costly, because dimv has to be copied along with
+    new object. Var rank Cell is one case where that is costly, because dimv has to be copied along with
     the pointer to make up a View, even though dimv is constant all through traversal.
   - [X] Review Container constructors. Why do we need (&) when we have (const &)?
     - <2025-07-24 Thu 11:35> was caused by auto && x constructor interfereing.

bench/bench-at.cc

@@ -75,7 +75,7 @@ int main(int argc, char * * argv)
         ra::Big<int> bigdi({100, 4}, ra::none);
         ra::Small<int, 100, 4> smoli;
         test2(smola, smoli, reps, "warmup");
-// regression in b40c2d412be04c4c2b4758a332424c05257f71ff due to CellSmall copy ctor.
+// regression in b40c2d412be04c4c2b4758a332424c05257f71ff due to copy ctor in static dimv Cell.
         test2(smola, smoli, reps, "small/small");
         test2(bigsa, smoli, reps, "bigs/small");
         test2(bigda, smoli, reps, "bigd/small");

docs/index.html

@@ -2018,9 +2018,9 @@ These are array types that own their data in one way or another.
 
 These are array views into data in memory, which may be writable. Any of the @b{Container} types can be treated as a @b{View}, but one may also create @b{View}s into memory that has been allocated independently.
 
-@item @b{Iterator} --- @code{CellBig}, @code{CellSmall}, @code{Ptr}, @code{Scalar}, @code{Map}, @code{Pick}
+@item @b{Iterator} --- @code{Cell}, @code{Scalar}, @code{Map}, @code{Pick}
 
-This is a traversable object. @b{Iterator}s are accepted by all the array functions such as @code{map}, @code{for_each}, etc. @code{map} produces an @b{Iterator} itself, so most array expressions are @b{Iterator}s. @b{Iterator}s are created from @b{View}s and from certain foreign array-like types primarily through the function @code{iter}. This is done automatically when those types are used in array expressions.
+These are traversable objects. @b{Iterator}s are accepted by all the array functions such as @code{map}, @code{for_each}, etc. @code{map} produces an @b{Iterator} itself, so most array expressions are @b{Iterator}s. @b{Iterator}s are created from @b{View}s and from certain foreign array-like types primarily through the function @code{iter}. This is done automatically when those types are used in array expressions.
 
 @b{Iterator}s have two traversal functions: @code{.adv(k, d)}, moves the iterator along any dimension @var{k}, and @code{.mov(d)}, is used on linearized views of the array. The methods @code{len()}, @code{step()}, @code{keep()} are used to determine the extent of these linearized views. In this way, a loop involving @b{Iterator}s can have its inner loop unfolded, which is faster than a nested loop, especially if the inner dimensions of the loop are small.
 

docs/ra-ra.texi

@@ -1,7 +1,7 @@
 // -*- mode: c++; coding: utf-8 -*-
 // ra-ra - Views and containers.
 
-// (c) Daniel Llorens - 2013-2025
+// (c) Daniel Llorens - 2013-2026
 // This library is free software; you can redistribute it and/or modify it under
 // the terms of the GNU Lesser General Public License as published by the Free
 // Software Foundation; either version 3 of the License, or (at your option) any

ra/arrays.hh

@@ -62,7 +62,7 @@ namespace ra {
 
 template <auto V> using ic_t = std::integral_constant<std::remove_const_t<decltype(V)>, V>;
 template <auto V> constexpr std::integral_constant<std::remove_const_t<decltype(V)>, V> ic {};
-template <class A> concept is_constant = requires (A a) { []<auto X>(ic_t<X> const &){}(a); };
+template <class A> concept is_ctype = requires (A a) { []<auto X>(ic_t<X> const &){}(a); };
 template <int ... I> using ilist_t = std::tuple<ic_t<I> ...>;
 template <int ... I> constexpr ilist_t<I ...> ilist {};
 
@@ -371,7 +371,7 @@ concept Slice = requires (A a)
     template <class A> constexpr bool RA_JOIN(NAME, _def) = requires { requires PRED; }; \
     template <class A> concept NAME = RA_JOIN(NAME, _def)<std::decay_t< A >>;
 
-RA_IS_DEF(is_scalar, !std::is_pointer_v<A> && std::is_scalar_v<A> || is_constant<A>)
+RA_IS_DEF(is_scalar, !std::is_pointer_v<A> && std::is_scalar_v<A> || is_ctype<A>)
 template <> constexpr bool is_scalar_def<std::strong_ordering> = true;
 template <> constexpr bool is_scalar_def<std::weak_ordering> = true;
 template <> constexpr bool is_scalar_def<std::partial_ordering> = true;