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.

And fix all spelling errors that codespell currently finds.

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

Several members of `std::allocator` were already deprecated in C++17
and have now been removed in C++20. This patch uses the appropriate
members of `std::allocator_traits` instead.

It was deprecated in C++17.

Tunnel size access of the CreateIterator through a proxy to work around interface limitations in the window type

See issue #56.

The class VariableBlockVector::CreateIterator behaves basically
like an STL output iterator, but it didn't quite implement the
required interface.  This patch adds the missing methods and
extends the unit test.

The main benefit of this (besides interface beauty) is that you can
now use std::fill etc. to set the block sizes of a VariableBlockVector.

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?

I had removed it by accident in one of the previous commits.

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.

Yes, strictly speaking this is an API change.  But the VariableBlockVector code
has been so buggy until the last few patches that I doubt anyone actually used it.

Previously, a method of the same name was inherited from the base class, which
however returned bogus results.

- much shorter code
- makes the iterators pass the test suite

Previously, they were inherited from the base class, resulting in the wrong types.

[[Imported from SVN: r1594]]

[[Imported from SVN: r1570]]

[[Imported from SVN: r1495]]

rbegin -> beforeEnd
rend   -> beforeBegin

[[Imported from SVN: r1414]]

original comment:
Fixed bug in memory management.
Memory was allocated with allocator.allocate(n) and always freed with
allocator.allocate(1). This might have resulted in memory leaks that
are not noticed by valgrind.

[[Imported from SVN: r1242]]

[[Imported from SVN: r1205]]

[[Imported from SVN: r1200]]

[[Imported from SVN: r1190]]

* update configure and Makefiles

[[Imported from SVN: r1100]]

Otherwise 

VariableBlockVector v=0

implicitly calls

VariableBlockVector v(0)

which constructsa a vector with 0 elements.

[[Imported from SVN: r913]]

[[Imported from SVN: r887]]

[[Imported from SVN: r802]]

[[Imported from SVN: r783]]

[[Imported from SVN: r751]]

different values are documented.

[[Imported from SVN: r218]]