|
From: James T. <ja...@fl...> - 2022-10-03 08:18:05
|
> On 3 Oct 2022, at 09:11, Portree Kid <mid...@gm...> wrote:
>
> I'm getting on pretty well, but can someone explain this construct?
>
> // Register the subsystem.
> SGSubsystemMgr::Registrant<FGScenery> registrantFGScenery(
> SGSubsystemMgr::DISPLAY,
> {{"FGRenderer", SGSubsystemMgr::Dependency::NONSUBSYSTEM_HARD},
> {"SGSky", SGSubsystemMgr::Dependency::NONSUBSYSTEM_HARD}});
>
>
> Obviously it registers the FGScenery, but where/how is it triggered? On load of the module?
>
>
It’s a scheme done by Edward (I think) a few years ago to ultimately replace the hard-coded subsystem creation and dependency code with a formal definition driven by data. (Which is the names / flags you see). This would allow ‘correct’ automated unload/reload of subsystems with any dependant ones cascaded correctly.
*But* we did not hit the point where this principle can be used generically yet, because quite a few subsystems have weird edge cases, so for now the main startup still uses the manual fgCreateSubsytems code path. Also touching subsytem creation order is unfortunately one of the prime ways to find subtle bugs because it can change the order properties are created in / bound to listeners.
Kind regards,
James
|