For single build-type generators such as unix make files check
CMAKE_CXX_FLAGS_<CONFIG> in addition CMAKE_CXX_FLAGS.  This is equivalent to
just CMAKE_CXX_FLAGS if not build-type is selected.  For multi-configuration
generators, check each configuration, and skip the test is any of them is bad.

I'd like to skip it only for the bad configs, but that would require generator
expression support in dune_add_test(CMAKE_GUARD ...).

We now only skip if
- The compiler is gcc 8.2.*
- The compile options include -ftree-loop-vectorize (possibly implicitly due
  to -O3)

We also complain loudly during cmake configure run, as this issue might
miscompile other code than just the test.

Closes: #19, #21

Merge branch 'feature/update-changelog' into 'master'

See merge request [core/dune-geometry!116]

  [core/dune-geometry!116]: Nonecore/dune-geometry/merge_requests/116

Merge branch 'feature/re-subentities-range' into 'master'

For a reference element re the call

      re.subEntity(i,codim,j,c);

returns the index (wrt re) of the j-th sub-subentity of codim (wrt re) c of
the subentity (i,codim). This allows e.g. to access all vertices of a face.
However, there's a big problem with this method:

It is often misinterpreted by users that the passed index j is the index of
one grid-subentity within another grid-subentity. To be more precise it is
assumed that the subEntity() methods of the reference element and a grid
element are consistent with each other. Unfortunately this is in general not
true because it is impossible to construct such an consistent subentity
embedding for any grid. As a consequence both may provide a different
embedding and the index j is essentially useless despite allowing to iterate
over all such subentities using

    // Don't use j directly in such a loop, it's very likely that
    // your assumptions on the meaning of j don't hold true!
    for(std::size_t j=0; j<re.size(i,codim,c); ++j)
      foo(re.subEntity(i,codim,j,c));

While the behaviour is documented, users repeatedly fall into this trap and
the issue is discussed on the list once in a while.

As a remedy this introduces a new method ReferenceElement::subEntities()
returning all the subentities as an iterable range. The actual type of this
range is implementation defined. Using this the above loop turns into:

    // No j here!
    for(auto k : re.subEntities(i,codim,c))
      foo(k);

This is not only more readable, but it especially avoids misinterpreting the
'index' j. You can still run into the trap on purpose by assuming a special
ordering of the range. But this is very unlikely and you have to take special
action to construct the index j.

This MR is based on [!93] (contains) because it consistently tests for all
codim/c combinations. But one could also restrict the allowed cases to
c>=codim here. In a later stage we may want to deprecate the error prone
subEntity() method.

Side note: Thanks to the implementer (@martin.nolte?) of the reference
elements for caching those numbers in a consecutive way. Implementing this
feature just amounts into wrapping pointers into the cache in a
Dune::IteratorRange. However, I'd even more like to put them into gsl:span.

See merge request [!94]

  [!93]: gitlab.dune-project.org/NoneNone/merge_requests/93
  [!94]: gitlab.dune-project.org/core/dune-geometry/merge_requests/94

While I'm not aware of an explicit formular (feel free to
provide/prove one), a constexpr function computing the
max works nicely here.

Merge branch 'ci/centralize-config' into 'master'

See merge request [!115]

  [!115]: Nonecore/dune-geometry/merge_requests/115

Now the index range returned from referenceElement.subEntities(i,codim,c)
is not just iterable but also provides the methods size() and contains().
This is not just for convenience:

It's a common use case of this method (e.g. when determining boundary DOFs),
to check if a faced contains the subentities associated to DOFs. Until know
you always had to loop over the range provided by referenceelement.subEntity()
and compare resulting indices. Now you can use the contains() method
which just looks up the result in a table.

Design decision:
The per-codim look-up is implemented using a std::bitset<K> with
K=3^dim as upper bound for the per-codim subentity count. While
this is pessipistic, it's much cheaper than any dynamic version
for dim<=4. Feel free to add a better upper bound for larger dimensions.

Merge branch 'skip-test-on-buggy-g++' into 'master'

ref:core/dune-geometry Closes: [#19].

See: [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288]

See merge request [!114]

  [#19]: gitlab.dune-project.org/NoneNone/issues/19
  [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288
  [!114]: gitlab.dune-project.org/core/dune-geometry/merge_requests/114


Closes #19

Closes: #19.

See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288

Merge branch 'deprecated-geometrytype-dim' into 'master'

ref:core/dune-geometry As decided at the 2018 dev meeting in Stuttgart.

This constructor (and its cousin GeometryType(uint)) are not really needed
with the new way to construct GeometryType objects.

See merge request [!111]

  [!111]: gitlab.dune-project.org/core/dune-geometry/merge_requests/111

As decided at the 2018 dev meeting in Stuttgart.

This constructor (and its cousin GeometryType(uint)) are not
really needed with the new way to construct GeometryType objects.

Merge branch 'cleanup/remove-NoCopyVector' into 'master'

ref:core/dune-geometry NoCopyVector is a very limited vector type for items
missing a copy constructor. This was required in the past as vector's template
parameter T "must meet the requirements of CopyAssignable and
CopyConstructible", however since C++11 this was weakened to "The requirements
that are imposed on the elements depend on the actual operations performed on
the container" which should allow use with non-CopyAssignable and
non-CopyConstructible types.

See merge request [!110]

  [!110]: gitlab.dune-project.org/core/dune-geometry/merge_requests/110

`NoCopyVector` is a very limited vector type for items missing a copy
constructor.  This was required in the past as `vector`'s template
parameter `T` "must meet the requirements of CopyAssignable and
CopyConstructible", however since C++11 this was weakened to "The
requirements that are imposed on the elements depend on the actual
operations performed on the container" which should allow use with
non-CopyAssignable and non-CopyConstructible types.

Merge branch 'feature/missing-include-in-simplex-cc' into 'master'

See merge request [!107]

  [!107]: Nonecore/dune-geometry/merge_requests/107

Merge branch 'issue/maxima_script' into 'master'

### Summary

Resolves a bug in gausslobatto.mac script where coefficients are generated
only with double precision instead of high-precision.

Closes [#18]

See merge request [!104]

  [#18]: gitlab.dune-project.org/core/dune-geometry/issues/18
  [!104]: gitlab.dune-project.org/core/dune-geometry/merge_requests/104


Closes #18

issue related to generation of gauss-lobatto quadrature rule from maxima script resolved. Closes #18

Allow `ReferenceElement::size(i,c,cc)` for `cc<c`

See merge request !93

See merge request !101

do not catch polymorphic type by value

See merge request !99

This silences a warning from GCC 8:

    dune/geometry/virtualrefinement.cc:496:5: warning:
    catching polymorphic type ‘class std::bad_cast’ by value [-Wcatch-value=]

[c++] Remove bind2nd

See merge request !97

std::bind2nd has been removed in C++17, and libc++ as shipped in LLVM 6 does not contain it anymore,
causing compile errors.

Instead of replacing it with std::bind, this fix removes it entirely and goes down the much simpler
path of using a generic lambda.

[test-nontype] Ignore warning when testing deprecated functionality.

See merge request !96

doc/refinement/*: remove executable bit from file permissions [ci skip]

See merge request !95

This essentially tests some special cases and consistency of
`subEntity()`, `subEntities()`, and `size()`.

For a reference element re the call

```cpp
  re.subEntity(i,codim,j,c);
```

returns the index (wrt re) of the j-th sub-subentity
of codim (wrt re) c of the subentity (i,codim). This allows
e.g. to access all vertices of a face. However, there's
a big problem with this method:

It is often misinterpreted by users that the passed index j is
the index of one grid-subentity within another grid-subentity.
To be more precise it is assumed that the `subEntity()` methods
of the reference element and a grid element are consistent with
each other. Unfortunately this is in general not true because
it is impossible to construct such an consistent subentity
embedding for any grid. As a consequence both may provide a
different embedding and the index j is essentially useless
despite allowing to iterate over all such subentities using

```cpp
// Do use j directly in this loop, it's very likely that
// your assumptions on the meaning of j don't hold true.
for(std::size_t j=0; j<re.size(i,codim,c); ++j)
  foo(re.subEntity(i,codim,j,c));
```

While the behaviour is documented, users repeatedly fall into
this trap and the issue is discussed on the list once in a while.

As a remedy this introduces a new method ReferenceElement::subEntities()
returning all the subentities as an iterable range. Using this the
above loop turns into:

```cpp
// No j here!
for(auto k : re.subEntity(i,codim,c))
  foo(k);
```

This is not only more readable, but it especially avoids misinterpreting
the 'index' j. You can still fall into the trap be assuming a special
ordering in the range. But this is very unlikely and you have to take
special action to construct the index j.

In a later stage we may want to deprecate the error prone `subEntity()` method.

While subEntity(i,c,j,cc) is surely not allowed for
cc<c because there's no viable j, there's no reason
to not allow this case for size(i,c,cc). Actually the
implementation works nicely in this case and returns
the correct number size zero. Any grid-specific
ReferenceElement implementation should simply return
zero in this case.

Allowing this case gives the possibility to seamlessly test
for(int j=0; j < re.size(i,c,cc); ++j)
for all 0<=c<=dim and 0<=cc<=dim.

[cleanup] Canonicalize SFINAE in referenceElements()

See merge request !91

[doc] Fix documentation of ReferenceElement::subEntity

See merge request !92

The codimension of the sub-subentity wrt to the ReferenceElement
was not correct.

The used version of SFINAE by enable_if has the advantage
of not adding additional template-parameters. However, it
has the disadvantage of making the generated doxygen documentation
hard to read.

This commit changes this to SFINAE/enable_if by defaulted
int template parameter. This additional parameter also
shows up in doxygen but its much easier to identify as
SFINAE dummy because it follows a simple idomatic pattern.
More importantly it does not mess up the documentation
for the other parameters.

[GeometryType] Clean up storage

See merge request !86

Steffen Müthing authored 7 years ago and Martin Nolte committed 7 years ago

This patch removes the packed bitfield used to store both the dimension and the none flag in a
single byte. This optimization does not change anything about the size of GeometryType as a whole,
because it would be 5 bytes even with the optimization and the C++ ABI (at least on 64-bit
platforms) automatically rounds that up to 8 bytes, so we can just as easily let both the flag and
the dimension have a full byte of their own.

This also improves the code generated by both GCC and Clang quite a bit. In order to further improve
matters, I reordered the member variables and put the topologyId_ variable last.