- the implicit casts from std::string/char* is part of the design for
the view class so we do not want to disable those.
- intializer list constructors should be implicitly called
Tune the makefile according to new principles, which adds a few bells
and whistles and for clarity.
Synopsis:
* The dependency on opm-common is completely gone. This is reflected in
travis and appveyor as well. No non-kitware cmake modules are used.
* Directories are flattened, quite a bit - source code is located in the
lib/ directory if it belongs to opm-parser, and external/ if third
party.
* The sibling build feature is implemented through cmake's
export(PACKAGE) rather than implicitly looking through source files.
* Targets explicitly set required public and private include
directories, compile options and definitions, which cmake will handle
and propagate
* opm-parser-config.cmake for downstream users is now provided.
* Dependencies are set up using targets. In the future, when cmake 3.x+
can be used, these should be either targets from newer Find modules,
or interface libraries.
* Fewer system specific assumptions are coded in, instead we assume
cmake or users set up system specific details.
* All module wide configuration and looking up libraries is handled in
the root makefile - all sub directories only set up libraries and
compile options for the module in question.
* Targets are defined and links handled transitively because cmake now
is told about them. ${module_LIBRARIES} variables are gone.
This is largely guided by the principles outlined in
https://rix0r.nl/blog/2015/08/13/cmake-guide/
Most source files are just moved - if they have some content change then
it's nothing more than include fixes or similar in order to make them
compile.
Severs the code dependency on opm-commmon. There was no actual
functional dependency here, with the exception of some enable/disable
warning headers. To properly make opm-parser a stand-alone module the
usage of these headers have been removed and the dependency on
opm-common is gone.
By representing string_view as char* instead of
std::string::const_iterator the string_view class bring possibly
slightly lower overhead, but mostly enables some optimisations.
A simple non-mutating view into a string. Implements a shallow reference
to a std::string, replicating its operations to be drop-in replaceable.
Primarily designed for inner loop use, where expensive string
allocations become a performance killer.
Utility/Functional is a lightweight high level functional-oriented sub
library that attempts to abstract some common uses and boilerplate
around the parser code (and later maybe for other modules to use).
This patch introduce only three functions, but they have proven common
enough to warrant some common implementation.
Since the Deck* family of classes have changed their interfaces to no
longer use shared_ptr, a lot of code broke. This patch fixes all
problems in tests, other signatures and accesses to now use the new Deck
interfaces.
Every header is self-contained and includes only what it must to
function, relying on users include what they need in source files,
adopting a pay-what-you-use model (in particular for internal
dependencies).
This is an effort to improve build performance. Several includes
scattered across the project are either unused or partially used (i.e.
just used to import a type name, not depending on the actual contents of
the header file).
Replaces a lot of these includes with forward declarations.
since tables can be tricky, we now enforce that the compiler bails out
if the user tries to instantiate a table class manually.
Note that a bit of trickery is needed to keep the low-level unit
tests working...
it is _strongly_ encuraged to use the properly named methods to access
the respective columns, but opm-core's current endpoint scaling code
makes it hard to use these...
for some kinds of tables this means linear interpolation for some
columns, constant for other columns and some tables do not allow to
specify default. Since there is no clear rule, this patch involved
checking the reference manual for every single f****** table keyword
plus some guess-work if the reference manual is unclear about
monotonicity and/or defaults.
... and constant interpolation at the fringes. this kind of evaluation
in between sampling point only makes sense for tables where the first
column is strictly monotonic, though.
