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

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

make genericTransformTuple work with constant tuples

This fixes the problem described in #50.

See merge request !150

[dunecontrol] Properly quote arguments, in particular to exec and bexec.

This means the you can now pass more complex scripts to exec/bexec that use
quoting themselves, and you don't get things like this anymore:
```
joe@paranoia:~/Projekte/dune-quote/dune-common$ LC_ALL=C bin/dunecontrol exec 'var="quoted value"; echo "$var"'
--- going to build dune-common  ---
--- calling exec for dune-common ---
bash: value: command not found

--- dune-common done ---
--- done ---
```

Closes: #51

Planned merge date: 2016-11-04 or later.

See merge request !157

[dune.module] Remove half-support for ',' as a dependency list separator.

Also: Improve error message in case dependency list parsing ends up with some
weird module name (e.g. empty or ',') by quoting it in the diagnostic output.

Closes: #31

See merge request !156

Felix Gruber authored 8 years ago and Felix Gruber committed 8 years ago

This makes tupleutilitytest succeed again.

Felix Gruber authored 8 years ago and Felix Gruber committed 8 years ago

This test fails for now, as genericTransformTuple does not work on
const tuples at the moment.

This is needed since master contains fixes for the parametertree, and the CI
fails without those.

This means the you can now pass more complex scripts to exec/bexec that use
quoting themselves, and you don't get things like this anymore:
```
joe@paranoia:~/Projekte/dune-quote/dune-common$ LC_ALL=C bin/dunecontrol exec 'var="quoted value"; echo "$var"'
--- going to build dune-common  ---
--- calling exec for dune-common ---
bash: value: command not found

--- dune-common done ---
--- done ---
```

Closes: #51

Also: Improve error message in case dependency list parsing ends up with some
weird module name (e.g. empty or ',') by quoting it in the diagnostic output.

Fix/modulename end with number



See merge request !149

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

Add implementation of std::is_callable

This is proposed for C++17 and helpful to checking correctness
of predicates supplied to algorithms. This also commes with
a test that checks is the behaviour is correct, especially
with respect to various combinations of r-values, r-value references,
and l-value-references.

See merge request !151

This is proposed for C++17 and helpful to checking correctness
of predicates supplied to algorithms. This also commes with
a test that checks is the behaviour is correct, especially
with respect to various combinations of r-values, r-value references,
and l-value-references.

This was a regression of the CMake build-system
Fixes #48