CollectiveCommunication serves as a fallback implementation, when
code that is written for parallel computations is executed in sequential.
The template parameters BinaryFunctions are no-op then, but they are
still there to define the interface. However, in a generic (parallel)
implementation these will be given. Including binaryfunctions.hh here
avoids error messages due to no-op template parameters whose names
could not be found by the compiler.

C++14 will introduce integer/index sequences in the header <utility>.
This patch introduces a backwards compatible implementation similar in
use. However, the implementation differs in the following technical
details:

  - index_sequence is not a template alias for integer_sequence but
  inherits from it

  - make_{integer, index}_sequence are not a template aliases but free
  standing functions

Both differences stem from the absence of template aliases introduced in
GCC aa late as gcc-4.7. This implementation will work in gcc-4.4 and
later.

dunecontrol is capable of doing out of source builds, that are
not nested within the source directory by giving an absolute path
to the --builddir option. Unfortuantely, this (nice) feature was
not documented.

When using DUNE_EXPORT, you need to include visibility.hh. This was
omitted when adding this flag to the Singleton class in singleton.hh.
This patch adds the missing include.

for details see FS#1398

nullptr-test.cc: Move semicolon to own line to prevent
Clang warning.
typetraitstest.cc: Exclude use of deprecated types
PointeeType and ReferredType with
DISABLE_DEPRECATED_METHOD_CHECKS defined.

funnily enough, this usually worked (i.e. it returned some garbage
which was not recognized by the switch statement that followed), and
was not detected by valgrind (on my machine at least, I suppose this
was because the address to which the string pointed was still a valid
memory location created by some previous user). The libstdc++ debug
mode (-D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1) did find it
though...

There is no need to limit it to 2 min. For larger modules
like DuMuX this is not enough. Increased timeout to 5 min.

Remove checks and fall-back code for hashing,
type_traits, and the remaining tr1 stuff.

Test (almost) all methods requested by the STL
(as documented on http://www.cplusplus.com/reference/iterator/ForwardIterator/ )

Test whether std::iterator_traits is properly specialized.

There is more macro magic to be removed.

Maybe we can deprecate the complete header type_traits.hh.

With GCC 4.4 or newer HAVE_INTEGRL_CONSTANT, HAVE_STD_HASH, and
HAVE_TYPE_TRAITS is always 1, no further testing necessary.
The test defines will be removed after the next Dune release.

Andreas Nüßing authored 10 years ago and Christoph Grüninger committed 10 years ago

When creating a project and generating the config.h.cmake file, duneproject
surrounds the inserted text with {begin,end} $NAME. $NAME is set to $PROJECT
without a leading "dune[-_]" and $PROJECT is the module name specified by the
user (e.g. $PROJECT==dune-grid, $NAME==grid).
When DuneMacro.cmake generates the config.h.cmake for the created project in
the build-directory, it searches the config.h.cmake file in the source
directory of the project for {begin,end} $ProjectName which is set to
DUNE_MOD_NAME, which is the module name specified in the corresponding
dune.module file (e.g. dune-grid).
This leads to DuneMacro not finding and therefore ignoring the block in the
source config.h.cmake of the new project.

Gcc 4.6 cannot generate default move constructor for classes containing a
DynamicVector because there is no move constructor and the copy constructor
is non-trivial.
This patch fixes this, by adding move semantics.

If duncontrol detects an installed dune-common module, then it always
assumed that it contains a lib/dunecontrol
subdirectory. Unfortunately, this does not hold for older dune-common
modules and dunecontrol will error out later with a message like

/usr/local/lib/dunecontrol: file not found
Execution of dunecontrol terminated due to errors!

With this commit we fix this by actually checking whether the
lib/dunecontrol subdirectoy exists before adding it to
DUNE_CONTROL_PATH.

Thanks a lot to wuhao sife for reporting this problem.

NDEBUG is undefined (allows to tests asserts without doubling call to all
interface methods).

NDEBUG needs to be undefined and DUNE_INTERFACECHECK needs to be defined
to check the correct implementation of CRT interface methods.

Steffen Persvold authored 10 years ago and Markus Blatt committed 10 years ago

getrusage() is a very expensive system call and involves several
kernel locks. This prevents multithreaded applications from scaling
effectively. Using std:chrono::high_resolution_clock is portable
and very low cost in most cases.

This avoids compiler warning about implicitly rounded to zero

This reverts commit cf4bf4d8.

The epxlicit cast isn't needed anymore as we have a fix for the
ambiguous operator overload.

The bug affected operators: +=, -=, *=, /=. It has been fixed by using:
enable_if<is_convertible<ParamType, FieldVector::valueType>, ...>

This was used for backwards compatibility only.

Complained by autoconf 1.14, cf. FS#1462.
Thanks to Claus for the heads-up.

Like 2a4965d9 for autotools.
Cf. FS#1445

Cf. FS#1461.

The variable is was set and used by dunecontrol but not by duneproject.