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: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#9491, @btutzer wrote:

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?

Agree. Also, R20:4f72bb7aa735#inline-105.

I'm normally against using shared pointers when the resources aren't explicitly meant to be shared
, but I don't mind.

done

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

I'm normally against using shared pointers when the resources aren't explicitly meant to be shared

I agree with that! :)
Don't use shared pointer if something is not shared. Use a unique pointer in that case.

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]

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: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?

Sounds good to me, although I did not think about unique/shared in this case. I agree that unique_ptr would be the way to go, unless, @dschnoell can think about a case where the abstractions may be passed around and not solely owned by a ReliableAgent object.
E.g. for the *StateDetector classes, shared_ptrs to abstractions are passed to the constructor so that the abstractions can be changed from outside, because at some point we are going to change them during runtime. If that applies to your classes as well, I think you should stick with the shared_ptrs, since overhead is not much more compared to unique_ptrs (I think).

As discussed with @btutzer currently there isn't a case, but at some point it could be beneficial to be able to adapt the the abstractions during run time.

So it will stay a shared pointer.