Curt Olson wrote:
> 2) As you know, accessing property manager values via static
> propertynode pointers is more efficient because you only have to do
> the expensive string name hash lookup once the first time the routine
> runs.
This is true, but I think the "expense" of the string lookup step is
wildly overestimated. Compared to the cost of rendering a single
frame, it's noise. YASim doesn't even bother with the node stuff yet;
it does sprintf/fgSet for every property every frame, and I haven't
noticed any performance issues.
Clearly there are limitations, and for some things efficiency *does*
matter. But those are the exceptions, not the common case.
> It would be nice to have a set of static property node accessors set
> up that any code could use, rather than having each routine
> duplicate the static propertynode element it needs.
I haven't looked at the code, but how big can a property node be?
It's just a wrapped pointer, maybe with some typing info, right?
> Perhaps it would make sense to put all these static accessors into
> FGInterface and creat accessor functions for them? <stepping back
> out of swinging distance> :-)
Nothing wrong with that. I can't speak for David, but my problem with
FGInterface isn't that it exists, but that it's required. I don't see
anything wrong with wrapping the "commonly used" FDM output variables
inside a utility class for other C++ developers to use as they like.
I mean, no one would ask you to write an autopilot via
fgGetFloat(). :)
The problem is when FGInterface it's the *only* way to get stuff out
of the FDM. Now, my hypothetical gun ammunition counter, or David's
water tank capacity becomes much harder to add. Instead of doing:
fgSetFloat("/yasim/consumables/gun[0]/rounds, 400);
I have to add a new method to FGInterface, stub it out with some
default value (easy to forget, which is how we ended up in this
discusion), decide on whether it's gets a variable in the interface
class or just a virtual function, implement it in my own class, map it
to a property, and (worst of all) get the people responsible for all
that code to accept the changes. All of that before *anyone* doing
panel XML can use the thing.
Andy
--
Andrew J. Ross NextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
