This reverts merge request !564

Remove allocator template parameter from the classes
`base_array_unmanaged`, `compressed_base_array_unmanaged`,
`block_vector_unmanaged`, `compressed_block_vector_unmanaged`, and
`CompressedBlockVectorWindow`.
All of these classes do not manage memory on their own.
The provided allocator was only used to deduce `size_type`.
The latter is now provided as template parameter explicitely.

Notice that this (seemigly breaking) change is safe, because
all these classes are clearly marked as implementation details
that should not be used outside of dune-istl.

See https://reuse.software/ for a description.

This invokes undefined behaviour and was now replaced by asMatrix()
in dune-common.

Carsten Gräser authored 5 years ago and Oliver Sander committed 5 years ago

Using the wrapper generated by `asVector()` we can get rid of `toVector()`.
The important difference is, that `toVector()` invokes undefined behaviour
by dereferencing the result of an aliasing `reinterpret_cast`. However,
there's no noteable properties of the new implementation:
* You can't use `asVector()` directly in calls to `mv()` and friends,
  because the latter is not robust wrt. to proxy references.
* When creating copies of values, you can't replace
  `auto rhs = v[i];` by `auto rhs = Impl::asVector(v[i])`
  because proxy references don't use deep copy on purpose.
  Instead we have to use the two step
  `auto rhsValue = v[i]; auto&& rhs = Impl::asVector(rhsValue);`

Carsten Gräser authored 5 years ago and Oliver Sander committed 5 years ago

Using `Impl::asVector()` we can get rid of several `Hybrid::ifElse()`
constructions used to implement the special case of scalar entries
(i.e. `IsNumber==true`).

This uncovers a bug in the method axpy, which is also fixed
in this patch.

The BlockVector capacity is expected to be an unsigned integer.
However, literals like '100' are signed, and therefore triggered
a warning.

So, for example, you can write

  BlockVector<double>

instead of

  BlockVector<FieldVector<double,1> >

and it will do what you expect it to do.

Indeed, isNaN could be something complicated, although normally it just
should be double.

This helps to avoid a clang warning

Explicitly do `using std::sqrt;`.  This is needed to ensure an overload for
`sqrt()` can be found for the built-in types, even if some include puts an
overload of `sqrt()` into namespace `Dune`.

Stop doing memory management ourselves, use a `std::vector` instead.  This has
the advantage that allocation, deallocation, construction and destruction of
elements is handled for us using the supplied allocator in an exception-safe
manner.

This has the disadvantage of using an extra pointer and an extra size_type in
`base_array_unmanaged`, which are kept syncronized with the `std::vector` used
as storage.  Anything else would require interface modification of
`base_array_unmanaged` and `block_vector_unmanaged`, which in turn would
require modifications to `BlockVectorWindow`, `MatrixBase`, and
`VariableBlockVector` and make this patch even larger.

This adds a `swap()` operation and move-construction/assignment to
`BlockVector`.

The one-argument versions of `resize()` and `reserve()` now behave exactly as
they do for `std::vector`.  This means that using `reserve()` to shrink the
capacity of a BlockVector no longer has any effect.  Apart from that, the
behaviour with regard to capacity on copy and move has also changed to that of
`std::vector`: copying will only expand the capacity of the copied-to vector
to accomodate the size of the copied-from vector, not necessarily it's
capacity.

This deprecates the two-argument versions of `resize()` and `reserve()`, and
makes them behave exactly the same as the one-argument versions, ignoring the
second argument.  The second argument specified whether or not to copy the old
values upon reallocation.  This conflicted with the common container semantics
of always copying/moving.  For `resize()`, it also conflicted with the common
signature where the second argument specifies the value for newly created
elements.

There were only two uses of the two-argument version of `resize()` in
dune-istl that triggered in the unit tests (both in arpackpp.hh), and those
had no effect different from the the one-argument version, because the
BlockVectors were empty before the `resize()`.

Fixes: #41
Requires:
- dune-common!494 for the tested allocators to be usable with `std::vector`.

`Dune::BlockVectorWindow` is declared, but never defined.  Also get rid of
`BlockVector` assignment from `Dune::BlockVectorWindow` which can't possibly
have worked, since `Dune::BlockVectorWindow` is incomplete, and there are no
issues or MRs in istl complaining about this.

Note that there is a similar but unrelated (except possibly historically)
`Dune::Imp::BlockVectorWindow`.

Oliver Sander authored 8 years ago and Ansgar Burchardt committed 8 years ago

There are various classes in dune-istl that are effectively implementation
classes internal to dune-istl. A few of them are base_array_unmanaged,
base_array_window, compressed_base_array_unmanaged,block_vector_unmanaged,
BlockVectorWindow, compressed_block_vector_unmanaged, CompressedBlockVectorWindow

See #22 for a brief
discussion.

This patch moves the classes into the namespace 'Imp'.  That way it is
clear that they are internal.

All code outside of dune-istl using those classes will break, but does
such code really exist?

By using the doxygen \internal command.

The implementation for this was hidden in the base classes
before and relied on undefined behaviour by using a downcast.
Now it is explicitly implemented for the derived classes
which also makes it more visible to users.

These constructors and assignments from base class are
all using a downcast which may result in undefined behaviour.
Since this is potentially dangerous and not used anywhere
in the core modules, this patch removes those methods.

This is in fact an _unsafe_ downcast to a derived
class. Accessing members via this pointer is undefined
if it is not guaranteed that the passed pointer
points to an object of the _derived_ class - even
if the memory layout is the same. In this case
this static_cast acts like a reinterpret_cast.

Just as containers from the standard library do.  These types are needed for
proper interface testing of the dune-istl vector interface.  For VariableBlockVector,
in particular, the type used for references is *not* value_type&, and therefore
the more general approach using a separate 'reference' type is needed.

This includes the behaviour of its rows, thus the
CompressedBlockVectorWindow class