I'm in a bit of a quandary here. I know the preferred method of supplying data to properties is by binding or tying the properties to C++ methods. In order to do this with JSBSim, however, I need to do one of two things:
1) bind the properties in the JSBSim classes themselves. This is not attractive to me (and I'm sure Jon as well) because it introduces a compile time dependency on FG that would have to be ifdef'd out and would, in the long term, touch a lot of classes. (AFAICT, bind() methods *must* be members of the same class that the methods being bound to are) 2) add new data and methods to FGInterface. This is doable, but FGInterface is already quite big and unwieldy and I'm not sure what its future is. Are we just trying to eliminate the direct use of its data methods by code outside of src/FDM or are we trying to eliminate its data entirely? (We'll still need something like FGInterface to abstract the FDM objects themselves, of course) Right now, I'm avoiding the question altogether and using the pointer and copy technique. This is not as efficient as binding and requires a data member for each property in FGJSBSim, so its something I'd like to get away from doing. So, I guess the question is, is 2) a reasonable way to proceed right now or will that get in the way of future plans? -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
