use of shared_ptr<const ProjData> etc still unsafe

We've tried to avoid giving access to internals of ProjData etc by only accepting shared_ptr<const ProjData> etc, see #470 #484 etc. However, this is still unsafe due to https://github.com/UCL/STIR/blob/b79bb323c1f1abab02f397f04ea8a13995b133c2/src/buildblock/ProjData.cxx#L400 and similar lines elsewhere.

Example

shared_ptr<ProjDataInfo>proj_data_info_sptr = initialise_somehow()
ProjDataInMemory p(proj_data_info_sptr, ....);
proj_data_info_sptr ->set_whatever();

Result: we've now modified a member inp, which is surprising to say the least, and will probably break use of p later on.

There isn't anything in ProjData that we can do against this, except for always cloning the proj_data_info object:

ProjData::ProjData(const shared_ptr<ExamInfo>& exam_info_sptr,
		   const shared_ptr<const ProjDataInfo>& proj_data_info_sptr)
  :ExamData(exam_info_sptr), proj_data_info_sptr(proj_data_info_sptr->create_shared_clone())
{}

Of course, this is the same for other classes, see e.g.
https://github.com/UCL/STIR/blob/b79bb323c1f1abab02f397f04ea8a13995b133c2/src/include/stir/Sinogram.inl#L98-L105

Always cloning is however memory inefficient. It also means there's little or no point anymore in using shared_ptr at all.

Anyone any bright ideas? @rijobro?

Start by reading the ownership and constructor behavior in src/buildblock/ProjData.cxx around line 400 and the related code in src/include/stir/Sinogram.inl around lines 98-105. Compare how shared_ptr<const ...> inputs can still expose mutable internals, then define and apply a consistent safe ownership strategy for the affected classes. Done means the reported mutation scenario no longer changes object state unexpectedly without imposing an unacceptable memory cost.