Closed rwj11 closed 4 years ago
Heads up @chrispooley @ianhinder @rwj11 - the "BEEPmbp" label was applied to this issue.
Chris, are you happy for robin to make these changes?
Hi, I am fine with this change as long as the code still works! Thanks
Chris has OK'd this, but it needs to be actioned... The simplest workflow for such issues is probably to reassign them to the relevant developer, rather than close them.
OK, thanks! Sorry this entire process of using github is new to me so I make some mistakes...
That's fine -- I've used similar systems, but not this one, and we're all getting used to the workflow. I'm learning too...
This needs the merge to be tidied up a bit and force-pushed over dev.
Unfortunately the merge was very complicated and was taking too much time. I've fixed the memory leak in a simple way. It might be good to avoid the new/delete in future, but other things are more urgent.
Memory allocated in MBP.cc at
is never deallocated. This can be fixed by changing
mbpchain
tovector<MBPCHAIN>
and usingemplace_back()
to construct members. (A more flexible alternative which also avoids having to havedelete
on all code paths is to convert the data structure into avector<unique_ptr<MBPCHAIN>>
and construct usingmake_unique<>
to fill it, but that's not necessary here.) While changing this, it might be useful to move these data structures to be private members of a class object rather than file static. Global & file static storage can lead to a variety of issues, e.g. undefined behaviour due to unspecified order of initialization, which I don't think are a problem at present but seem better avoided for the future.