BookKeeper feList is vector of raw pointers
What
The method getFrontEnd returns an instance of std::unique_ptr<FrontEnd>
, which is good. In most of the cases where getFrontEnd
is called it treats the returned heap-allocated FrontEnd
as intended. However, for scans where we rely mostly on the Bookkeeper
object for handling the list of FrontEnd
objects we more or less do this:
std::vector<FrontEnd*> feList;
...
feList.push_back(getFrontEnd("type").release())
That is, we re-gain access to the raw pointer in order to satisfy Bookkeper
's std::vector<FrontEnd*>
container. We then rely on Bookkeeper
's destructor to clean up the memory/etc. Generally, it's 2017 (at least) and we should avoid using raw pointers where absolutely not necessary. I think this was the intent with getFrontEnd
returning std::unique_ptr
, however scanConsole
did not adapt itself to handle that.
Fixes
We should rethink about the memory access pattern for the FrontEnd
objects that are passed around via Bookkeeper
. As a given FrontEnd
object should only exclusively owned by a single entity at a time (i.e. nobody should be attempting to configure the same chip at once), std::unique_ptr
is probably the correct thing to do (following the intent of getFrontEnd
). This will enforce the intent of single-access to each of the FrontEnd
objects, make concurrency simpler, and simplify the clean-up (calls to new
and delete
don't need to be used anymore :)).