! In R20:a94537b537bbdabf920b23f61c00f10e8b2d0388#8669, @goetzinger wrote:
Hello Benedikt, I checked Abstraction.hpp, agent-functionalities.cpp and functionAbstraction.hpp. I haven't seen any errors but I don't understand the whole code. If you have time to skype with me a bit in the next days, it would be nice. Br Maxi

Also, please note that I updated some comments yesterday (after our call), so make sure you pulled the latest commit from the feature/linear_functions branch (1d3bf7fe7a40), maybe the new comments clear some things up.

In R20:a94537b537bbdabf920b23f61c00f10e8b2d0388#8669, @goetzinger wrote:

Hello Benedikt, I checked Abstraction.hpp, agent-functionalities.cpp and functionAbstraction.hpp. I haven't seen any errors but I don't understand the whole code. If you have time to skype with me a bit in the next days, it would be nice. Br Maxi

In R20:cb3a24c0eeae370bda4839f7748c8ce7933576e9#8619, @juhasz wrote:

783f8c48d55e looks good!
Could you please complete the documentation comments for the new function before I accept this commit?

On another note: I tried to stick to your coding-style as much as possible. This included your naming convention of template typenames (T, A, ...). As RangeConfidence requires three such typenames, this get's a little out of hand. I'd rather call them DomainType (T), IdType (A) and RangeType (B), would you be ok with that @juhasz?

Ah audit's are registered per-person. So I can accept my part.

Looks good to me. I'll leave it up to Maxi to accept the commit.

This commit introduces some doxygen warnings during the build:

Addressed in 7d93f54bc66c

Addressed in 783f8c48d55e

Thanks!

Addressed in e5af743a80c7

Addressed in R20:d46823eed74d894f03c0311971b2187463e16c84

In R20:3e6fe06d97aa877219c1be05f1e54d69b49f01d3#8571, @juhasz wrote:

What do you think about shouldProcess? I find it a good descriptive function name: it tells whether processing should be done with respect to the parameters.

shouldProcess sounds good! Thanks!

Nitpick, but I do not like the doExecute function name. I would expect that such a function would really do something (have a side-effect). I think check or checkPending or something like that would me more appropriate.

@goetzinger RangeConfidence now returns Maps as agreed upon in todays meeting.

Everything works fine with clang 5.

clang 5 is also not available from most current repositories though.

In R20:10223b8026b16d1bc9782805956318dba7e00a0b#8480, @juhasz wrote:

@btutzer, why did you change the required C++ standard to C++14?

Please have a look at the whole branch. More or less it's just copied and pasted from T108#1906 though.
I added some lines in modules/CMakeLists.txt to make sure the submodule is initialized before the build. If not, not even cmake itself would successfully configure since there is no CMakeLists.txt in modules/cxxopts/ before submodule initialization.
If you approve, I will merge this into master.

I see that you are accepting raw pointers as input to addCrossReliabilityProfile and expect them to be uniquely owned by the module. I made the same mistake (actually mine was a lot worse since I did not delete them in the destructor), but agree with @juhasz that it is bad practice. Can you move to std::uniqe_ptr's/std::shared_ptr's?

Hi,
I saw that you are doing many sanity checks on the template types inside methods, like

static_assert(std::is_arithmetic<Type>::value); // sanitny check

I think it would be better to do this once per template instead to improve readability.

@dschnoell When we talked yesterday I noticed you are using some of these new functionalities. I think you were only using LinearFunction's, but in case you are using PartialFuncion or RangeConfidence as well, please note that the interface changed.

In R20:a94537b537bbdabf920b23f61c00f10e8b2d0388#8364, @juhasz wrote:

Raw pointers are used in PartialFunction::RA, but RangeAbstraction destructs the stored values directly (i.e., the pointers only in this case). This causes memory leak.

I do not see immediately if there is a need for using pointers there... I would consider storing the values directly instead of pointers.
If using pointers is motivated, some kind of smart pointer would work better (e.g., std::shared_ptr).

I noticed I cannot build anymore due to this change.
Since no C++17 features are actually used I do not think it is a good strategy to require it. Many linux distributions do not have clang-7 available from repositories, so support for C++17 is still scarse. Is there no other way to achieve VS compatibility with c++14?
If I build with c++17 and clang-7, I run into the following error:
/usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/tuple:115:17: error: reference member '_M_head_impl' binds to a temporary object whose lifetime would be shorter than the lifetime of the constructed object
The same source builds fine with C++14 and clang-4.0