Joacim Persson writes: > I'm curious about the choice of language/linkage for the implementation: > Why have a specific vendor model hard-coded in c++? Seems more like task > for xml/nasal scripts to me. ?:-P Nothing wrong with the language (c++) > but isn't it a little out of place in the fgfs /core/. >
That's a fair point. I used c++ because that's what I'm used to, and that's what I *know* can get the job done without running into major obstacles, whereas nasal, and adding the 'C' code function hooks for it, is an unknown quantity to me. Additionally, the c++ code could concievably be used as the basis for a standalone KLN unit simulation where nasal is not available, for instance as an X-Plane or MSFS plugin. Not on my TODO list, I hasten to add! > Another way to go (in the future) could be implementing specific instrument > models as "plug-ins" -- dynamic objects. Then the model designer can choose > implementation language freely. (If for instance one is well familiar with > c++ and find nasal et.al. awkward to work with.) It could also be > easier to debug in that manner. (using stubs) I agree, a plugin architecture would be ideal, since then complex avionics UIs wouldn't have to add weight to the core code in terms of compilation time, compiled code size and so forth. However, a plugin architecture would have to be well thought out, and crucially, stable, to avoid plugins that by definition aren't compiled by all developers having the interface shift from beneath them. I have no experience of plugin architectures, and don't feel competent to attempt it at the moment. I'd happily alter the kln89 code to make use of one if available though. Cheers - Dave _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
