Investigate alternatives for weak_ptr in coupling manager
The following discussion from !2823 (merged) should be addressed:
-
@DennisGlaeser started a discussion: (+4 comments) is the call to
this->problem()
expensive because of theif
check I guess? But compared to the subsequent call tobindCouplingContext
thatif
should 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.expired
is, but anif
statement 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.