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.

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.

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).

As decided on the developer meeting in Aachen, we support (but do not
rely on) the C++11 keyword constexpr. This patch adds an m4-check for
constexpr and a header (cxx11.hh) defining a macro DUNE_CONSTEXPR either
as constexpr or empty (depending on the compiler support for it). It is
then used in FieldVector and FieldMatrix on size, rows, and cols.

The default constructor of the FieldVector has intentionally avoided calling a
constructor for the contained data to eliminate the potential overhead of that
initialization.
During implementation of a new creation mode of the BCRSMatrix, it was discovered
that this behavior is problematic due to its inconsistency: If the data type
contained in the FieldVector is a non-trivial type, a default-constructed
FieldVector will be fully initialized. On the other hand, with a primitive data
type it will be in an uninitialized state, potentially causing undefined behavior.

As this behavior might be very unintuitive for users and made implementing the new,
more efficient creation method for the BCRS matrix very difficult to implement, this
patch changes the FieldVector default constructor to always default-construct its
contents regardless of its type. While this change does introduce a possible
performance regression (for primitive types, the compiler now has to zero out the
memory), the overhead has been measured to be minimal.

The actual implementation prefers to use the new C++11 unified initialization
syntax and falls back to std::fill for older compilers. The distinction was made
because newer compilers generate much more efficient code when using unified
initialization, and for user-defined types, this approach avoids first calling the
default constructors and then the copy assignment operator.

[[Imported from SVN: r6886]]

[[Imported from SVN: r6801]]

With the exception of mpicollectivecommunication.hh
and propertymap.hh, which I didn't understand.

[[Imported from SVN: r6784]]

[[Imported from SVN: r6683]]

[[Imported from SVN: r6682]]

This patch removes the constructor from the overload set.
Before the constructor was there but failed to compile
due to the static assertion.

If you have methods f(K) and f(FieldVector<K,n>) with
n>1 the overload was ambigous when calling f() with
a FieldVector<K,1> because there is a conversion
from this to FieldVector<K,n> - even if it does not
compile due to the failing static assertion.

Now this is avoided using SFINAE. This fixes fs#1024. 

[[Imported from SVN: r6680]]

[[Imported from SVN: r6559]]

[[Imported from SVN: r6494]]

to FieldVector::size() as a method.

With this patch applied FieldVector::size remains an enum, hence all your
code compiles as before.  However you get a compiler warning explaining
the issue and suggesting to configure with --enable-fieldvector-size-is-method.
If you do so, then FieldVector::size becomes a method, and you may have
to go out and adjust your code.  The configure flag is transitional and
will be removed after dune 2.2 is out.

Remember that there is no smoother way to do the transition, as you can't
have FieldVector::size to be both an enum value and a method at the same
time.

This fixes FlySpray issue 819.


[[Imported from SVN: r6486]]

[[Imported from SVN: r6386]]

[[Imported from SVN: r6385]]

How difficult is this. I just don't get it. 



[[Imported from SVN: r6384]]

[[Imported from SVN: r6377]]

[[Imported from SVN: r6375]]

Merged r6371 from the trunk, that ensures the correct size of the FieldVector given to the copy constructor.


[[Imported from SVN: r6372]]

different size!

[[Imported from SVN: r6371]]

[[Imported from SVN: r6366]]

FieldVector< complex<T> > = FieldVector<T>

[[Imported from SVN: r6324]]

[[Imported from SVN: r6272]]

[[Imported from SVN: r6179]]

  valued data

[[Imported from SVN: r6177]]

[[Imported from SVN: r6175]]

DynamicVector. Inheritance doesn't work for template specialization
lookup... not that this specialization isn't necessary, if you are
using FieldVector<T,n> via the interface class DenseVector< FieldVector<T,n> >

[[Imported from SVN: r6174]]

  few cases, where CRTP really makes sense!)
* type infroamtion is provided via DenseMatVecTraits

[[Imported from SVN: r6171]]

- FielfVector uses int, not unsigned int

[[Imported from SVN: r6168]]

that std::array defines these operators aswell and c++ prefers to
complain about an inaccesible base class, rather than using the cast
operator :-(

[[Imported from SVN: r6167]]

duplicated code, we only have to add the scalar operators.

[[Imported from SVN: r6165]]

[[Imported from SVN: r6157]]

[[Imported from SVN: r6135]]

[[Imported from SVN: r6129]]

vectors using different storage containers

[[Imported from SVN: r6128]]

[[Imported from SVN: r6105]]

[[Imported from SVN: r5926]]

[[Imported from SVN: r5923]]

[[Imported from SVN: r5922]]