20,741
edits
FlightGear Headless: Difference between revisions
Jump to navigation
Jump to search
m
→FlightGear Headless: https://sourceforge.net/p/flightgear/mailman/message/37716391/
No edit summary |
m (→FlightGear Headless: https://sourceforge.net/p/flightgear/mailman/message/37716391/) |
||
| Line 44: | Line 44: | ||
= Scenery = | |||
t’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.<ref>https://sourceforge.net/p/flightgear/mailman/message/37716229/</ref> | |||
From my previous expirience with systems like Osgi here some ideas : | |||
* Each subsystem must directly inherit from SGSubSystem. (required by | |||
the registrar) | |||
* The staticSubsystemClassId() must reside in a abstract base class | |||
for all implementations of said subsystem otherwise | |||
getSubsystem<Subsystem>() will pull in a certain Impl | |||
* This superclass will also include the public interface of said subsystem<ref>https://sourceforge.net/p/flightgear/mailman/message/37716391/</ref> | |||
for any subsystem we want to mock, that’s what we need to do. | |||
Except … actually there is another approach I’ve used sometimes, which is to use the pimpl idiom, and have real- and mock- versions of the pimpl, i.e a single FGScenery containing a std::unique_ptr<FGScenery::Impl> which is an interface, and then FGScenery::RealImpl and FGScenery::MockImpl. This keeps the outside view clear, but tends to make the internals a bit less clear than a ‘normal’ pimpl pattern. | |||
I would say for FGScenery the original approach we discussed is better, because switching to a pimpl style is just as disruptive as switching to an abstract superclass, but for some other systems which already use pimpls the opposite would be true.<ref>https://sourceforge.net/p/flightgear/mailman/message/37716402/</ref> | |||
= FlightGear Headless = | = FlightGear Headless = | ||
<!-- | <!-- | ||