1. 15 Jan, 2019 3 commits
    • Carsten Gräser's avatar
      [!604] [bugfix] Various fixes for Std::optional · 06445ddc
      Carsten Gräser authored
      Merge branch 'feature/fix-optional' into 'master'
      
      ref:core/dune-common
      
      -   Centralize call of placement new
      -   Cast away constness of &value_ in placement new. Otherwise placement new
          is not allowed. Since this only happens in non-const member functions,
          we're still const correct at the Std::optional level
      -   Avoid that the greedy eat-anything-constructor
          `template<class U> optional(U&&)` is considered in place of the explicitly
          given ones by fixing the enable_if guards.
      -   Disable assignment for const types. Before the overload existed for these
          cases but was broken. Now it's properly disabled allowing to check for
          assignability.
      
      This fixes [#139].
      
      See merge request [!604]
      
        [#139]: gitlab.dune-project.org/NoneNone/issues/139
        [!604]: gitlab.dune-project.org/core/dune-common/merge_requests/604
      
      
      Closes #139
      06445ddc
    • Carsten Gräser's avatar
    • Carsten Gräser's avatar
      [bugfix] Various fixes for Std::optional · 93e7d878
      Carsten Gräser authored
      * Centralize call of placement `new`
      * Cast away constness of `&value_` in placement `new`.
        Otherwise placement new is not allowed. Since this
        only happens in non-const member functions, we're
        still const correct at the `Std::optional` level
      * Avoid that the greedy eat-anything-constructor `template<class U> optional(U&&)`
        is considered in place of the explicitly given ones by fixing the
        `enable_if` guards.
      * Disable assignment for const types. Before the overload
        existed for these cases but was broken. Now it's properly
        disabled allowing to check for assignability.
      
      This fixes #139.
      93e7d878
  2. 14 Jan, 2019 1 commit
    • Jö Fahlke's avatar
      [!602] bin/duneproject: Fix, modernize and document check for existing modules · 39d202a4
      Jö Fahlke authored
      Merge branch 'duneproject-check-deps' into 'master'
      
      ref:core/dune-common Fixes:
      
      -   Use unambiguous truth values (Closes: [#134])
      -   When checking with pkg-config, look for the dependency rather than the
          last module from the list of found modules
      
      Modernizations:
      
      -   Scope variables
      -   Use a simple if rather than a loop to check for presence of a depency in
          list of existing modules
      -   Make sure the function does not depend on the status of the -e option, or
          whether it is called from within the condition of an if or a || or &&.
      
      Documentation:
      
      -   Document calling convention for the function and assumptions on the
          parameters.
      
      See merge request [!602]
      
        [#134]: gitlab.dune-project.org/NoneNone/issues/134
        [!602]: gitlab.dune-project.org/core/dune-common/merge_requests/602
      
      
      Closes #134
      39d202a4
  3. 12 Jan, 2019 5 commits
    • Carsten Gräser's avatar
      [!599] Add a TransformedRangeView class · 5968f11b
      Carsten Gräser authored
      Merge branch 'feature/add-transformedrangeview' into 'master'
      
      ref:core/dune-common This adds a TransformedRangeView and a helper function
      transformedRangeView() creating it.
      
      This behaves like a range providing begin() and end(). The iterators over this
      range internally iterate over the wrapped range. When dereferencing the
      iterator, the value is transformed on-the-fly using a given transformation
      function leaving the underlying range unchanged.
      
      The transformation may either return temorary values or l-value references. In
      the former case the range behaves like a proxy-container. In the latter case
      it forwards these references allowing, e.g., to sort a subset of some
      container by applying a transformation to an index-range for those values.
      
      The iterators of the TransformedRangeView have the same iterator_category as
      the ones of the wrapped container.
      
      If the wrapped range is an r-value, then the TransformedRangeView stores it by
      value, if the wrapped range is an l-value, then the TransformedRangeView
      stores it by reference.
      
      See merge request [!599]
      
        [!599]: gitlab.dune-project.org/core/dune-common/merge_requests/599
      5968f11b
    • Carsten Gräser's avatar
      [bugfix] Fix member functions returning iterators · 9f013eba
      Carsten Gräser authored
      Member functions returning iterators need to be overwritten
      in the derived interator class. Otherwise they would return
      base class iterators.
      
      Here we duplicate the implementations. This could be avoided
      using CRTP and/or mixins. However, this would lead to more
      complicated and even longer code.
      9f013eba
    • Carsten Gräser's avatar
      0e6242ed
    • Carsten Gräser's avatar
      [test] Check transformedRangeView() · 027f7cb0
      Carsten Gräser authored
      027f7cb0
    • Carsten Gräser's avatar
      Add TransformedRangeView · 8436c90a
      Carsten Gräser authored
      This behaves like a range providing `begin()` and `end()`.
      The iterators over this range internally iterate over
      the wrapped range. When dereferencing the iterator,
      the value is transformed on-the-fly using a given
      transformation function leaving the underlying range
      unchanged.
      
      The transformation may either return temorary values
      or l-value references. In the former case the range behaves
      like a proxy-container. In the latter case it forwards these
      references allowing, e.g., to sort a subset of some container
      by applying a transformation to an index-range for those values.
      
      The iterators of the `TransformedRangeView` have the same
      `iterator_category` as the ones of the wrapped container.
      
      If the wrapped range is an r-value, then the TransformedRangeView stores it by value,
      if the wrapped range is an l-value, then the TransformedRangeView stores it by reference.
      8436c90a
  4. 09 Jan, 2019 7 commits
    • Steffen Müthing's avatar
      [!603] Fix compilation of varianttest when compiling with libc++ · 50ce8439
      Steffen Müthing authored
      Merge branch 'bugfix/fix-varianttest-with-libc++' into 'master'
      
      ref:core/dune-common When using clang with libc++, the vector header does not
      get pulled in implicitly by some part of the standard library, causing
      compilation of varianttest to fail.
      
      See merge request [!603]
      
        [!603]: gitlab.dune-project.org/core/dune-common/merge_requests/603
      50ce8439
    • Steffen Müthing's avatar
      [varianttest] Fix compilation with libc++ · cac91989
      Steffen Müthing authored
      When using clang with libc++, the vector header does not get pulled in implicitly
      by some part of the standard library, causing compilation of varianttest to fail.
      cac91989
    • Jö Fahlke's avatar
      Fix, modernize and document check for existing modules · a40a591b
      Jö Fahlke authored
      Fixes:
      - Use unambiguous truth values (Closes: #134)
      - When checking with pkg-config, look for the dependency rather than the last
        module from the list of found modules
      
      Modernizations:
      - Scope variables
      - Use a simple `if` rather than a loop to check for presence of a depency in
        list of existing modules
      - Make sure the function does not depend on the status of the `-e` option, or
        whether it is called from within the condition of an `if` or a `||` or `&&`.
      
      Documentation:
      - Document calling convention for the function and assumptions on the
        parameters.
      a40a591b
    • Carsten Gräser's avatar
      [!601] Add UniqueTypes_t helper template alias · c947cebb
      Carsten Gräser authored
      Merge branch 'feature/add-uniquetypes-helper' into 'master'
      
      ref:core/dune-common For a given `template<class...> Target` and list of types
      T... the alias `UniqueTypes_t<Target, T...>` refers the instatiated template
      Target<S...>, where S... is generated from T... by removing duplicate types.
      
      This is useful for std::variant, because duplicate types are not fully
      supported by some implementations. If your type list is generated by whatever
      mechanism where you don't have control over uniqueness, then
      `UniqueTypes_t<std::variant, T...>` is what std::variant<T...> should have
      been.
      
      See merge request [!601]
      
        [!601]: gitlab.dune-project.org/core/dune-common/merge_requests/601
      c947cebb
    • Carsten Gräser's avatar
      Add UniqueTypes_t helper template alias · 1763ef97
      Carsten Gräser authored
      For a given `template<class...> Target` and list of types `T...`
      the alias `UniqueTypes_t<Target, T...>`  refers the instatiated
      template `Target<S...>`, where `S...` is generated from `T...`
      by removing duplicate types.
      
      This is useful for `std::variant`, because duplicate types
      are not fully supported by some implementations. If your
      type list is generated by whatever mechanism where you don't
      have control over uniqueness, then `UniqueTypes_t<std::variant, T...>`
      is what `std::variant<T...>` should have been.
      
      This would fit into `typetraits.hh`. However, this would lead
      to a cyclic dependency of `typetraits.hh` and `std/type_traits.hh`.
      Hence I've put it into `typelist.hh` which conceptually also
      deals with type list, altough no `TypeList<...>` shows up
      in the interface of `UniqueTypes_t`.
      1763ef97
    • Jö Fahlke's avatar
      [!600] bin/duneproject: Expand tabs and fix indentation · a0912abe
      Jö Fahlke authored
      Merge branch 'duneproject-fix-indent' into 'master'
      
      ref:core/dune-common As a shell script, duneproject is not covered by the
      scripts preventing tabs in indentation (or simply was exempt from the Great
      Reformatting). Also, the tab width was inconsistent.
      
      This expands all tabs and uses a consistent indentation of 2. It also
      instructs both emacs and vi to use these settings, since their default
      indentation for shell scripts seems to differ.
      
      See merge request [!600]
      
        [!600]: gitlab.dune-project.org/core/dune-common/merge_requests/600
      a0912abe
    • Jö Fahlke's avatar
      bin/duneproject: Expand tabs and fix indentation · 4a045958
      Jö Fahlke authored
      As a shell script, duneproject is not covered by the scripts preventing tabs
      in indentation (or simply was exempt from the Great Reformatting).  Also, the
      tab width was inconsistent.
      
      This expands all tabs and uses a consistent indentation of 2.  It also
      instructs both emacs and vi to use these settings, since their default
      indentation for shell scripts seems to differ.
      4a045958
  5. 08 Jan, 2019 2 commits
    • Carsten Gräser's avatar
      [!598] [bugfix] Fix iteratortest · b26c7063
      Carsten Gräser authored
      Merge branch 'feature/fix-iteratortest' into 'master'
      
      ref:core/dune-common
      
      -   While testForwardIterator() prints to std::cerr its result was ignored in
          testBidirectionalIterator() such that a failure in the former would still
          lead to a passed test. Now we also capture errors in
          testForwardIterator().
      -   testBidirectionalIterator() returned on the first error. Now we continue
          the test to potentially find more errors at once.
      -   Fix requirements on forward iterators. C++14 does *not* require that two
          iterators compare equal if they are default-initialized, but only if they
          are value-initialized. This makes a difference for POD types: Raw pointers
          are valid forward iterators (used e.g. in std::array) since
          value-initialization zero-initializes them, altough default-initialization
          would leave them uninitialized.
      
      See merge request [!598]
      
        [!598]: gitlab.dune-project.org/core/dune-common/merge_requests/598
      b26c7063
    • Carsten Gräser's avatar
      [bugfix] Fix iteratortest · ad6ae76b
      Carsten Gräser authored
      * While testForwardIterator() prints to std::cerr its result
        was ignored in testBidirectionalIterator() such that a failure
        in the former would still lead to a passed test. Now we also
        capture errors in testForwardIterator().
      * testBidirectionalIterator() returned on the first error. Now we
        continue the test to potentially find more errors at once.
      * Fix requirements on forward iterators. C++14 does _not_ require
        that two iterators compare equal if they are default-initialized,
        but only if they are value-initialized. This makes a difference
        for POD types: Raw pointers are valid forward iterators (used e.g.
        in std::aray) since value-initialization zero-initializes them,
        altough default-initialization would leave them uninitialized.
      ad6ae76b
  6. 07 Jan, 2019 6 commits
    • Carsten Gräser's avatar
      [!597] Fix default constructor of IntegralRangeInterator · 119cc637
      Carsten Gräser authored
      Merge branch 'feature/fix-integralrangeiterator-default-constructor' into 'master'
      
      ref:core/dune-common In c++-14 all value-initilized forward iterators should
      behave like the end-iterator of a hypothetic empty container and furthermore
      should all compare equal. Here, this would lead to undefined behaviour since
      the value_ member is not initialized.
      
      To avoid this we no initilize it by 0 which mimics 'past end of empty range'.
      With this patch we can check IntegralRangeInterator using the
      testConstIterator() test suite.
      
      See merge request [!597]
      
        [!597]: gitlab.dune-project.org/core/dune-common/merge_requests/597
      119cc637
    • Carsten Gräser's avatar
      [bugfix] Fix default constructor of IntegralRangeInterator · a1b66cb6
      Carsten Gräser authored
      In c++-14 all value-initilized forward iterators
      should behave like the end-iterator of a hypothetic
      empty container and furthermore should all compare equal.
      Here, this would lead to undefined behaviour since
      the `value_` member is not initialized.
      
      To avoid this we no initilize it by 0 which mimics
      'past end of empty range'
      a1b66cb6
    • Carsten Gräser's avatar
      [test] Perform iterator test for IntegralRangeIterator · a71b4f87
      Carsten Gräser authored
      This currently leads to undefined behaviour because
      comparison of default constructed iterators uses
      uninitialized values.
      a71b4f87
    • Carsten Gräser's avatar
      [!596] Feature/improve variant · 06fc7b23
      Carsten Gräser authored
      Merge branch 'feature/improve-variant' into 'master'
      
      ref:core/dune-common
      
      -   Implement and use a cmake check instead of __has_include(<variant>)
          because `g++-7 -std=c++14` defines the header but not std::variant
      -   Pull std::monostate into the Dune::Std:: namespace and provide a fallback
          implementation.
      
      See merge request [!596]
      
        [!596]: gitlab.dune-project.org/core/dune-common/merge_requests/596
      06fc7b23
    • Carsten Gräser's avatar
      Improve Dune::Std::variant · 9b0e18fc
      Carsten Gräser authored
      * Use cmake check instead of `__has_include(<variant>)`
        because `g++-7 -std=c++14` defines the header but not `std::variant`
      * Pull `std::monostate` into the Dune::Std:: namespace
        and provide a fallback implementation.
      9b0e18fc
    • Carsten Gräser's avatar
      [cmake] Add cmake check for std::variant · 71d22d5d
      Carsten Gräser authored
      Using `__has_include(<variant>)` unfortunately does not
      work as expected, because for `g++-7 -std=c++14` the
      `variant` header exists but does not define `std::variant`
      71d22d5d
  7. 21 Dec, 2018 3 commits
    • Oliver Sander's avatar
      [!595] Mention Std::variant in the changelog · 5f2c4f3c
      Oliver Sander authored
      Merge branch 'document-std-variant' into 'master'
      
      See merge request [!595]
      
        [!595]: Nonecore/dune-common/merge_requests/595
      5f2c4f3c
    • Oliver Sander's avatar
      Mention Std::variant in the changelog · 1b59d0e0
      Oliver Sander authored
      1b59d0e0
    • Oliver Sander's avatar
      [!342] Add a C++14 implementation of C++17's std::variant · 5237c2c4
      Oliver Sander authored
      Merge branch 'feature/stdvariant' into 'master'
      
      ref:core/dune-common In dune-subgrid we wanted to use std::variant which is
      part of C++17's STL ([see e.g. here]). Since the corresponding compilers (or
      rather STL implementations) aren't too widespread by now and also out of pure
      curiosity, I reimplemented std::variant myself using only C++14 and some of
      Dune::Hybrid. In the end I ended up with a implementation that covers most of
      the STL functionality and behaves more or less the same way (though it
      probably won't be as safe, fast or complete as e.g. the gcc implementation, of
      course). If this might be of any value for the Dune project, I'd be happy to
      contribute this to dune-common.
      
      See merge request [!342]
      
        [see e.g. here]: http://en.cppreference.com/w/cpp/utility/variant
        [!342]: gitlab.dune-project.org/core/dune-common/merge_requests/342
      5237c2c4
  8. 12 Dec, 2018 3 commits
  9. 08 Dec, 2018 2 commits
  10. 07 Dec, 2018 3 commits
  11. 06 Dec, 2018 4 commits
  12. 05 Dec, 2018 1 commit