Due to its desgin of using one static memory pool. The allocator
could not be used in different threads at the same time without
side effects. With this revision each instance will hold its own private
instance of the pool.

There should be no issues with this patch and poolallocator seems to be
mostly used in AMG anyway.

when we try to send data, it might happen, that for some reason we don't want to any data.
This happens, when the dynamic size of our CommPolicy is 0. In that case we must not add a
MessageInformation, otherwise we get an MPI error.

Somehow, the vector version of CollectiveCommunication< MPI_Comm >::prod
passed std::plus to allreduce (instead of std::multiplies). This patch
corrects this flaw.

Make type of std::site_t an additional template parameter to avoid the
warning. While this is conceptually redunant its OK since we only use
it in a helper struct.

VariableSizeCommunicator now appears in doxyen and the parallel
index sets are a subsection of the parallel section.

There entries in doxyerror.log about undocumented function
parameters and parameters that had a wrong name in the documentation.
This patch fixes this.

This patch introduces a new macro DUNE_UNUSED_PARAMETER(parm) for marking
unused parameters that are there for a purpose (e.g. the prescribed interfac
The macro simply performs a cast to void. In addition all unused parameter w
that I found were removed.

Thanks, Oliver!

The new YaspGrid constructors require an array with the number of cells
in each direction. Unfortunately, there is no array constructor that
takes a single element and copies it to all array elements.

This patch adds a simple function Dune::fill_array() to do just that.

With this patch VariableSizeCommunicator now really supports a varying number of data entries
per index during communication.

[parallel,release] Adds a new buffered communicator that does not need to know the data amount per index when receiving.

During communication of data with a parallel DUNE grid the amount of data items
received at an index is not known at the receiving side. With this communicator
it is possible to build such a communication based on index lists at the sending
and receiving side. With this patch only fixed size of data items per index is
supported.

This fixes a Clang warning.

Make more precise statement to the user if no template specialization
of DenseMatrixAssigner is found. Also use dune_static_assert instead of
static_assert.

This implementation of an IdentityMatrix does not hold any data. It
implements a reduced version of the DenseMatrix interface including a
standard C++ cast operator to a Dune::FieldMatrix. This code illustrates
the new forward capabilities of DenseMatrixAssigner.

The default implementation of DenseMatrixAssigner replaces redundant
code in dense matrix constructors taking a primitive data type.

[DenseMatrix] Introduce DenseMatrixAssigner for initializing dense matrices from arbitrary right hand sides

In order to overcome the deficiencies of istl_assign_to_fmatrix() we
propose to always use a struct DenseMatrixAssigner for initializing a
dense matrix. This class can be specialized by users for any right hand
side to be used in an assignment.  The new mechanism can bei default
implemented using existing implementations of istl_assign_to_fmatrix()
as well.

There was one line of diff missing in that patch. Sorry!

Previously, copying a RemoteIndexListModifier resulted in a double
free of a pointer to a list of global indices. There was no need to
use a pointer to this, though. After this patch we store the list directly
by value. Thus the default copy constructor works but makes a rather cheap copy
of a (most often empty) singly linked list and we get rid off the non-default
destructor.

At least Clang 3.2 complains.

DenseVector is the base class of a CRTP. This is kind of an abstract
class that works only if it can be casted into a derived type. Copying
the base class is pointless.

This patch marks the copy constructor of DenseVector private (not even
implementing it), so that it cannot be called anymore. Once we have a
DUNE_DELETE macro, we should use it, here.

At the same time, the default constructor is marked protected, so that only
derived classes can instantiate a DenseVector. Notice that this does not
prevent the user from building a derivced class which does not pass
itself as implementation to DenseVector. It is (to my knowledge) not possible
to make CRTPs completely fail-safe.

As Carsten pointed out, the hash combining algorithms doesn't work
correctly for 32-bit platforms because it uses a multiplication with
a 64-bit constant.

This patch adds a switch for picking different algorithms based on the
size of std::size_t using a new struct hash_combiner that is templated
on the size of std::size_t.

Right now, there are implementations for 64-bit and 32-bit platforms,
both based on CityHash.

Thanks to Tobias Malkmus for the heads-up.

This patch adds a new header visibility.hh with macros DUNE_EXPORT and DUNE_PRIVATE
to mark symbols as exported or private at the ABI level.

While we do not explicitly mark any symbols as hidden, there are certain situations
in which the compiler creates symbols with incorrect linkage, especially for singleton
accessor methods for templated types and their embedded static variables, which involve
the creation of weak symbols.

The linker is then unable to merge those weak definitions, causing either a link-time
failure (when building static libraries) or undefined runtime behaviour (dynamic libraries).

This problem can be avoided by explicitly marking the singleton accessor methods as
DUNE_EXPORT. For symmetry, there is also a DUNE_PRIVATE macro, but while it works, I don't
see it used very much in the short term.

This patch removes an extra header install command for tests. It
originally came when copying dune/common/CMakeLists.txt to
dune/common/std/CMakeLists.txt. Sorry for the noise.

The majority of developers favor individual headers for (emulation of) C++11
features over collecting them in a single header cxx11.hh. This patch
renames cxx11.hh to constexpr.hh and moves it into the subdirectory std.
This is the place most developers would like these headers in (see
http://users.dune-project.org/doodles/4).