Closes #58

`v` is a const reference, so we can only return a const reference.

Add correct offset for end of chunk

Using `&current->chunk_ + x` will add `x * sizeof(current->chunk_)` to
the pointer, but we only want to add `x`.

Adding a much larger number still "works" on 64bit systems (although it
does not perform the intended check). However on 32bit platforms this
wraps (at least in the way used by sllisttest.cc) and the "end" of the
chunk is suddenly before the beginning.

Closes #57

See merge request !181

Using `&current->chunk_ + x` will add `x * sizeof(current->chunk_)` to
the pointer, but we only want to add `x`.

Adding a much larger number still "works" on 64bit systems (although it
does not perform the intended check). However on 32bit platforms this
wraps (at least in the way used by sllisttest.cc) and the "end" of the
chunk is suddenly before the beginning.

Closes #57

[bugfix] Fix possible memory corruption in ForLoop

The reason for perfect forwarding is to also forward r-values as
r-value references such that the called function can do a move
on such values.
As a consequence you should never call `std::forward` on the same
object twice because the second function may get a moved from
object since the first one has already stolen the data. E.g.
for the following operation
```cpp
  template<int i>
  struct Operation
  {
    static void apply(std::vector<int> v)
    {}
  };
```
a call to
```cpp
  Dune::ForLoop<Operation, 0, 1>::apply(std::vector<int>{1,2,3});
```
will pass a moved from vector in an undefined state on the second call.

BTW: The same error existed in the old implementation of `ForLoop`

See merge request !177

The reason for perfect forwarding is to also forward r-values as
r-value references such that the called function can do a move
on such values.

As a consequence you should never call std::forward on the same
object twice because the second function may get a moved from
object since the first one has already stolen the data. E.g.
for the following operation

  template<int i>
  struct Operation
  {
    static void apply(std::vector<int> v)
    {}
  };

a call to

  Dune::ForLoop<Operation, 0, 1>::apply(std::vector<int>{1,2,3});

will pass a moved from vector in an undefined state on the second call.

BTW: The same error existed in the old implementation of ForLoop

[cleanup] fix warning: extra ‘;’ [-Wpedantic]

This removes the extra ‘;’ warnings when compiling with -Wpedantic.

See merge request !176

Update man page of dunecontrol

Closes #52

See merge request !159

Vectorize FieldMatrix

Vectorize enough of `FieldMatrix` to make dune-geometry!13 work.

- [DONE] Fix buildsystem.
- [DONE] Ensure no performance regression.
- [DONE] Investigate anti-speedup in vectorized 1×1 `solve()`. (The effect disappeared in later benchmarks)
- [DONE] Merge with current master.
- [DONE] Wait for comments until at least 2016-11-17.

See merge request !121

[test] Check Std::apply() by implementing a tuple transformation

This checks with a real application example: An implementation
of a tuple transformation.

Maybe we also want to implement our real tuple tranformation
that way, because its easier to read and much shorter.

See merge request !171

Feature/add integersequenceentry

The traits class `IntegerSequenceEntry` computes the i-th entry
of an `std::integer_sequence`. The `integerSequenceEntry` helper
function does the same with function syntax.
    
 This allows to avoid the hight template instantiation depth
 of `std::make_tuple` when using the "natural" implementation

```cpp    
std::get<index>(std::make_tuple(t...));
```
    
The latter adds 15 instantiation levels per argument whereas
the still recursive implementation in this MR adds only one.

See merge request !170

MPIHelper should only finalize MPI if it called init

MPIHelper only calls MPI if it was not already called before MPIHelper is constructed. Finalize is however always called on destruction leading to
problems with other packages calling init/finalize before/after MPIHelper
is setup. Added a bool storing the information if MPIInit was called by the
MPIHelper so that finalize is only called in that case.

See merge request !58

This checks with a real application example: An implementation
of a tuple transformation.

Maybe we also want to implement our real tuple tranformation
that way, because its easier to read and much shorter.

Now the template instantiation depth for an integer_sequence
of length n is ~n instead of ~15n (for gcc 6).

The traits class IntegerSequenceEntry computes the i-th entry
of an std::integer_sequence. The integerSequenceEntry helper
function does the same with function syntax.

This allows to avoid the hight template instantiation depth
of std::make_tuple when using the "natural" implementation

  std::get<index>(std::make_tuple(t...))

The letter adds 15 instantiation levels per argument whereas
the still recursive implementation in this commit adds only one.

Deprecate ForLoop, ForEachValue and ForEachValuePair

Deprecate `ForLoop`, `ForEachValue` and `ForEachValuePair` since they are only a useless wrapper around the generic `Hybrid::forEach`.

See merge request !169

deprecate ForLoop, ForEachValue and ForEachValuePair since they are only a useless wrapper around the generic Hybrid::forEach

Add the TupleVector class

The `TupleVector` class is a multitype container without
algebraic operations. It relates to `Dune::MultiTypeBlockVector`
like `std::vector` relates to `Dune::BlockVector`. This is achived
by augmenting `std::tuple` by the following:
* `operator[]` for `Dune::index_constant` arguments
* `static size()`
    
You can now write code like this which will work for multitype
and classic vector like containers:

```c++    
    using namespace Dune::Hybrid;
    forEach(integralRange(size(v)), [&](auto i) {
        v[i] = i;
    });
 ```

Notice that `TupleVector` was already present as implementation detail
of two tests in dune-common and that dune-functions and dune-solvers
also both contained their own variants

See merge request !134

Carsten Gräser authored 8 years ago and Christoph Grüninger committed 8 years ago

The TupleVector class is a multitype container without
algebraic operations. It relates to Dune::MultiTypeBlockVector
like std::vector relates to Dune::BlockVector. This is achived
by augmenting std::tuple by the following:
* operator[] for Dune::index_constant aruments
* static size()

You can now write code like this which will work for multitype
and classic vector like containers:

using namespace Dune::Hybrid;
forEach(integralRange(size(v)), [&](auto i) {
    v[i] = i;
});

Notice that TupleVector was already present as implementation detail
of two tests in dune-common and that dune-functions and dune-solvers
also both contained their own variants

make dunecontrol compatible with git worktrees

I currently have my dune directory where all the git repositories for the Dune modules reside with checked-out master branches.
To simplify testing the Dune 2.5 branches, I created a new dune-2.5 directory where I created linked worktrees for the releases/2.5 branch of each Dune module with `git worktree`.
Unfortunately, `dunecontrol` doesn't recognize these linked worktrees as git repositories. When I call e.g. `dunecontrol update` it gives me warnings like
```
--- calling update for dune-common ---
WARNING: dune_common is not under a known version control system.
         We support svn, git and cvs.
--- dune-common done ---
```
This is caused by the fact that `dunecontrol` only checks whether .git exists as a directory, but in linked worktrees .git is a regular file containing the path of the main worktree.
This merge request fixes this problem by additionally checking if .git exists as a regular file.

See merge request !161

Felix Gruber authored 8 years ago and Christoph Grüninger committed 8 years ago

In linked worktrees generated with `git worktree`, .git is a file
instead of a directory.

Since dunecontrol was only checking whether .git exists as a directory,
it didn't recognize linked worktrees as git repositories. This problem
can simply be fixed by additionally checking if .git exists as a regular
file.

Allow using object libraries in conjunction with shared libs.

CMake's object libraries cannot judge whether they will be used
in shared libraries. To allow ease of in core and downstream modules
we resort to compiling position independent code whenever shared DUNE
libraries are requested. This is done by setting CMAKE_POSITION_INDEPENDENT_CODE
to ON. Please not that the can be overriding manually by setting the target
property POSITION_INDEPENDENT_CODE to something else where needed.

Closes staging/dune-uggrid#16

See merge request !160

Markus Blatt authored 8 years ago and Christoph Grüninger committed 8 years ago

CMake's object libraries cannot judge whether they will be used
in shared libraries. To allow ease of in core and downstream modules
we resort to compiling position independent code whenever shared DUNE
libraries are requested. This is done by setting CMAKE_POSITION_INDEPENDENT_CODE
to ON. Please not that the can be overriding manually by setting the target
property POSITION_INDEPENDENT_CODE to something else where needed.

Deprecate header tuples.hh

See merge request !89

Short circuit Hybrid::forEach for integer_sequence

This reduced the template instanciation depth drastically.
E.g., for range=`integer_sequence<21>` is changed from 319 to 84.

This is especially important for clang, because this has a default max-depth of 256 in contrast to gcc (900).

See merge request !162

This reduced the template instanciation depth drastically.
For range=integer_sequence<21> is changes from 319 to 84.

This is necessary to resolve merge conflicts, and to make sure
parametertreetest passes on the branch.

Conflicts:
	dune/common/densematrix.hh

Add overload() and orderedOverload()

These helper functions allow to create overload sets from lambdas.
E.g. one can merge to lambdas for different argument types into
one overload set in order to easily implement type-specific behaviour
when looping over a tuple.

While the result of overload(f1, f2,...) will pick the best match
for a given set of arguments, orderedOverload(f1,f2,...) will pick
the first match which allows to prevent ambiguity.

This functionality is proposed for the standard in P0051R2
(open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0051r2.pdf).
There overload(...) is proposed and an upcomming proposal
with the functionality of orderedOverload(...) is announced.
Since the former is not accepted and the latter is not even written
I did explicitly implement this in Dune:: instead of Dune::Std::.

See merge request !153