| 117 | 117 | </pre></div><p>The whole point is that a resolved link (class member <a class="el" href="classbdm_1_1SettingResolver.html#aadfcd0a81d025c52c8335b6aea07b498" title="Reference to a resolved link or to the original Setting in the case it does not contain...">result</a>, i.e., "link.result" in the previous example) could point into a different configuration file. In that case there has to be an <a class="el" href="classbdm_1_1UIFile.html" title="This class serves to load and/or save user-infos into/from configuration files stored...">UIFile</a> instance managing reading from this file. As the libconfig::Config deletes all its Settings when dealocated, <a class="el" href="classbdm_1_1UIFile.html" title="This class serves to load and/or save user-infos into/from configuration files stored...">UIFile</a> must not be dealocated until all the necessary operation on the linked Setting are finished (otherwise, the link <a class="el" href="classbdm_1_1SettingResolver.html#aadfcd0a81d025c52c8335b6aea07b498" title="Reference to a resolved link or to the original Setting in the case it does not contain...">result</a> would be invalid just after the <a class="el" href="classbdm_1_1UIFile.html" title="This class serves to load and/or save user-infos into/from configuration files stored...">UIFile</a> dealocation). And that is exactly the mechanism implemented within <a class="el" href="classbdm_1_1SettingResolver.html" title="This class serves to expand links used within configuration files.">SettingResolver</a> class. It assures, that the <a class="el" href="classbdm_1_1SettingResolver.html#aadfcd0a81d025c52c8335b6aea07b498" title="Reference to a resolved link or to the original Setting in the case it does not contain...">result</a> Setting reference is valid within the scope of <a class="el" href="classbdm_1_1SettingResolver.html" title="This class serves to expand links used within configuration files.">SettingResolver</a> instance.</p> |
