Investigate alternatives for weak_ptr in coupling manager
The following discussion from !2823 (merged) should be addressed:
is the call to
this->problem()expensive because of the
ifcheck I guess? But compared to the subsequent call to
ifshould be negligible, no? If that's the case, I would be in favor of removing the comment and the if/else block for clearer code.
I'm not sure how expensive the call to
weakPtr.expiredis, but an
ifstatement is generated here as well by checking if the context is empty..
In general the problem interface of the base coupling manager pops up in performance analysis so it's a non-negligible overhear involved with obtaining a reference to a sub-problem. We could switch to a raw pointer which has the only disadvantage that you get a segfault instead of a runtime error in case the you use the coupling manger after the problem is destroyed. I the usual setup that should never occur. But it might occur in some future configurations...
Note that shared_ptr is not an option because that would lead to a cyclic dependency and a memory leak.