@goetzinger to use the new code, call the following command:

In R20:43f9eab482727f3584abb669e33a29e01a5df9e4#9491, @btutzer wrote:

In R20:43f9eab482727f3584abb669e33a29e01a5df9e4#9039, @dschnoell wrote:

Moved it to std::unique_ptr .
Internally it still uses the raw pointers by using std::unique_ptr::release() to get the pointer and removing it from the unique_ptr .

It is updatet in Functionality_Reliability Branch

Any reason why you are opposed to use smart pointers? As they are used throughout the library, I would suggest to use them everywhere.
@juhasz what do you think?

In R20:43f9eab482727f3584abb669e33a29e01a5df9e4#9529, @juhasz wrote:

In R20:43f9eab482727f3584abb669e33a29e01a5df9e4#9526, @dschnoell wrote:

I already changed it to shared pointers to hold the lib consistent. Or did I misunderstand something and abstractions are meant to be shared ?

So David you decide shared or unique pointers ? [Concerning the consistency]

About consistency: we should use smart pointers.

Whether to use shared or unique pointer is to be decided for each usage separately. If one object is shared and needs to be referenced from multiple places at the same time, then shared pointer must be used; unique pointer otherwise.

Abstractions in this case are uniquely owned and not shared -- as far as I remember. So std::unique_ptr should be used here.

@btutzer, how do you see this?

In R20:bb607dfb87d8a548844c3241ed5d148db7243be5#9498, @dschnoell wrote:

The only static asserts in RelibilityConfidenceCombinator.h are at lines 193 195 197 and in CrossCombinator.h at lines 80 82 besides them I can't find any.

In R20:43f9eab482727f3584abb669e33a29e01a5df9e4#9039, @dschnoell wrote:

Moved it to std::unique_ptr .
Internally it still uses the raw pointers by using std::unique_ptr::release() to get the pointer and removing it from the unique_ptr .

It is updatet in Functionality_Reliability Branch

In R20:bb607dfb87d8a548844c3241ed5d148db7243be5#9036, @dschnoell wrote:

I changed this inside the functionality_Reliability branch

Your probably going to hate me after reading all my inline comments...
Lots of them are just spell-checks. I don't care about comments, but please try to keep the documentation correct. I myself am now looking into installing a spell-checker plugin for my IDE.

I guess it makes no sense auditing this commit, as it is work in progress (my fault, I added myself...). Could you please add me as an auditor once everything is ready?

Sorry for the delay. I'll check my open audits more often in the future.

Hi Maxi,
Commits 26ef3a3b5032, 90875aa7e993, 41ddbdc23746 and this one (e2b668b5985a) are about the issues we talked about yesterday.
You can now define LinearFunctions by providing two points (either as two std::pair's containing the coordinates or as x1, y1, x2, y2). These can be changed by setter methods.

Looks good to me, although I am wondering what the acronyms MFP, MOTMFP and SFP stand for.

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8925, @juhasz wrote:

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8922, @btutzer wrote:

I still can't build though.

I've seen this kind of problem with Clang 6 in another project... Warning suppressed in R20:04dbc622e75c.

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8845, @juhasz wrote:

Replaced with std::is_same in R20:06e9cd4317c1.

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8796, @juhasz wrote:

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8636, @btutzer wrote:

This commit introduces some doxygen warnings during the build:
[...]

I have no problem building documentation with doxygen 1.8.13. Maybe you use an older version?

Unfortunately, I had to wipe my computer clean as after updating libstdc++ from debian experimental to be able to build ROSA I was unable to boot.
I am now using clang-6 from the backports repo, which builds rosa fine, but breaks my build with this particular branch, due to 'std::is_same_v' missing.
I searched around and found no fix for that other than installing libstdc++ from testing, and I am not doing that again... Is there a way to work around std::is_same_v? If not, please tell me what distribution you are using so I can set up a virtual machine, but I would like to avoid that very much.

I guess you are planning to implement the match() and noMatch() fuzzy functions in this class, right? So in the State detector you would call them for each known state and then when StateDetector gets a new Sample you would push the new sample to the State that it matches best to, or creating a new State if no State fits?

In R20:0b66a6941c008121ff2f8f0f65abe87b7f625dc7#8753, @juhasz wrote:

I had a quick look, and it seems OK except for my inline comment about History::~History().

I also wonder why History::lengthOfHistory and History::policyOfHistory? I think simply History::length() and History::policy() would be just as understandable and much less characters.

Fixed in 383554aef975

In R20:0b66a6941c008121ff2f8f0f65abe87b7f625dc7#8753, @juhasz wrote:

In T130#2047, @juhasz wrote:

I agree.
Let's keep the possibility to have a lightweight but statically sized History with std::array and add a dynamic version with std::vector.

I suggest to keep History as an interface that declares the public functions of the current implementation. StaticHistory and DynamicHistory would be two implementations of that interface based on std:array and std::vector, respectively; and DynamicHistory adds the resize feature of course.

Hi.
I think your fix makes sense.
As Pi is not needed by RoSA itself but only by apps and examples, the necessity to use the proposed include order is not a big restriction in my opinion.
Please push the fix.

In R20:a94537b537bbdabf920b23f61c00f10e8b2d0388#8710, @goetzinger wrote:

The only questions I have:

1. With which rule did you give these typename names? For example, "template <typename T, typename A> class LinearFunction :". Why not something more descriptive instead of "T" and "A"?

T and A are very common for Type names. I agree that they are not very descriptive though. For the RangeConfidence i switched to D (Domain-Type), I (Id-Type) and R (Range-Type). I agree that it might be better to use descriptive names for types and I think I will do so in the future!

2. Why did you use all the time this operator overloading function. Could it not by also done with a simple function that can be called and returns the result?

That is a design choice by @juhasz. It could be done by a simple function, and it actually is nothing more that a function. You could actually call it by obj->operator()(arg_list). I have actually done that in include/rosa/agent/FunctionAbstractions.hpp:218.
For me, the choice to override the ()-operator makes sense here, as it is intuitive that a functionality is executable.