xparq
commented
10 months ago Closing this, as with #400 (config chaining) done, the rest can be delegated/postponed to further issues.
Open xparq opened 10 months ago
xparq
commented
10 months ago Closing this, as with #400 (config chaining) done, the rest can be delegated/postponed to further issues.
241 (distinct app dir) reminded me of this one, too... That apparently superfluous, almost pointless (but in fact just subtle) dir change has indeed been doing its job of being an architectural beacon, as I had hoped! And now, separating the config files might do even more "beaconing", e.g. for the runtime dirs, deployment etc.
[x] Separate the cfg. files
-> #397... (Well, didn't take long after an earlier note in some other issue stating that this riddle will come back. :) ) -> #368
[x] This also implies separating the cfg member! -> It can't be just a simple derivation of SimAppConfig though, for the usual lame inheritance/polymorphism limitations: data members can't (sanely) be made polymorphic, and it won't be available at all when constructing the SimApp layer!
-> #402: separate cmdline options for the app and the engine!
[x] Aaaargh... And also needs repaying this tech debt in Config.cpp! (I didn't even remember it! :-o I just noticed that the Help HUD started appearing by default, despite disabled in the config, and followed it up...)
static toml::table _config; //!! Get rid of this! :-o //!! There was a reason I made it static, but failed to document it, and now //!! I have no idea, of course... :-/ //!! Hopefully it was just a quick hack for the old architecture with a less //!! controlled config init sequence, so stuff can at least grab things from... //!! Wait a sec, that doen't make any sense... The cfg. instance itself was //!! already not-static! Whatever... Just get rid of this! :) //!! //!! Aaargh!... OK, got it! :) No, it was for a completely different reason: //!! this is a simple, hamfisted, but effective kludge to isolate the rest of //!! the system from whatever actual config file format/parser is used! //!! So... Not so fast with getting rid of it... //!! //!! (It could still be replaced with a dynamically allocated buffer though, //!! by only forward-declaring the object type in the header. And maybe //!! using unique_prt, if someone pays for it... But for such a simple //!! task there's absolutely no need for that.)
-> Pimpl with unique_ptr does indeed work, but a bit finicky: https://www.fluentcpp.com/2017/09/22/make-pimpl-using-unique_ptr/
<memory>dependency on everything that includes the config interface?! (It's almost as bad as just letting the original config mechanics dependency fall through uncontrolled without pimpling!...)