Otherwise the compiler will probably give us a warning that these
pragmas are unknown. By default that warning is disabled with our
own build system, but we also want to be able to link to our library
without incorporating the entire build system too.
If a function is used by a template but this template is not
instantiated, the function will still be defined in the header
of a module but it won't be callable because it is in an anonymous
namespace and thus we get a warning.
This only happens in Clang; GCC consider functions referenced from
templates as used.
fixup! Don't warn about functions not emitted
for some of these files this is needed to make to keep it compiling
after the next patch because the new ErrorMacros.hpp file will no
longer implicitly includes <iostream>. for the remaining files it is
just good style.
While at it, the includes for most of these files have been ordered in
order of decreasing abstraction level.
our policy is that we only use boost if necessary, i.e., if the oldest
supported compiler does not support a given feature but boost
does. since we recently switched to GCC 4.4 or newer, std::shared_ptr
is available unconditionally.
The attic are the place where files which we don't use right now, but
which we acknowledge some amount of valuable time has been spent on and
which may be usable some day in the future, so we don't have the
conscience to right out delete them.
These files are not expected to compile, and certainly not to run and
produce sensible results, anymore. However, with some work they can
possibly be converted into proper unit tests or examples.
Although they don't use Boost::UnitTest, they can at least pass, so we
can use them to detect simple compilation and runtime errors, although
we miss the semantic check.
(If you have time, please make them proper unit tests)
The current implementations of IncompPropertiesInterface are very
all-or-nothing. In some situations, you want to read rock and fluid
properties from an Eclipse file, but use analytical functions for
the unsaturated properties. Or you want to update properties based
on a marching filter.
This patch provides a way to mix various property objects, or to
"shadow" the properties with a raw array of data, so you don't have
to reimplement the entire interface just to make a small change.
The <have_boost_redef.hpp> header was introduced (commit 82369f9) as
a work-around for a particular interaction in the Autotools-based
setup of OPM-Core and the Dune core modules. Notably, Dune's
"Enable" trick for Boost failed on some older Autoconf systems. Now
that we're using CMake, however, that kluge is no longer needed
because we (OPM-Core) always
#define HAVE_BOOST 1
i.e., as an explict true/false value.
Therefore, we need no longer include <have_boost_redef.hpp> . The
header will be removed at a later time.
Variably-sized arrays of the form
int n = 6;
double a[n];
are an extension to the language that will illicit a suitably
persnickety diagnostic from GCC when invoked with "-pedantic".
The numbers in the deck are more indicative of FIELD unit conventions
than METRIC unit conventions, so allow the input parser to interpret
the data in that manner.
The collections have been checked for equal size, we then only need the
size of one of them to iterate. The other boundary pointer is never used
and only generate needless compiler warnings that pollutes the output.
