> > However, I do think we could clean it up a bit with a pre-processor
> > #define AEROINTFUNC double (FGAerodynamics::*)(int) const
>>> or typedef ...
>> ... renaming ... to remove the ambiguity any better?
As someone - i think - mentioned, IMHO it would be
better to have single getter functions, like -
*** added to FGAircraft.h
// test - grm
inline double GetXYZep1() const { return vXYZep(1); }
inline double GetXYZep2() const { return vXYZep(2); }
inline double GetXYZep3() const { return vXYZep(3); }
Then the lines that give msvc heart failure can be changed
to - perhaps a more readable, and consistent form of ...
*** changed in FGAircraft.cpp
PropertyManager->Tie("metrics/eyepoint-x-ft", this,
&FGAircraft::GetXYZep1);
PropertyManager->Tie("metrics/eyepoint-y-ft", this,
&FGAircraft::GetXYZep2);
PropertyManager->Tie("metrics/eyepoint-z-ft", this,
&FGAircraft::GetXYZep3);
This change compiles great for me. Will zip and send
completed cpp/h pairs i have done if told where ...
Remember, there are about 5/6 FGxxxxxxxx::* (pointers)
to be 'fixed' likewise, so it is more than one define in one
module pair (cpp/h) ...
And this would also then apply to the 'setter(ind)' when they
are added to the mix ...
I must say, in passing, this addition gives a great BOOST
to the developing FGFS 'property tree' ... and remember
the tree can now be output (timed/delimited) thru logger ...
--config...xml, although i have not tried it yet ... this is
in addition to JSBSim's own extensive (csv) debug
capabilities ...
Also, such function additions gives the compiler/linker a
chance to really make this 'inline', since the double value
could be 'addressed' in simple lines, when loaded, like
mov eax, [0x12345678] ; get that double
mov edx,[0x12345678+4]
or in 64-bits
lod reg1, [0x1234567812345678] ; load double
which is all we can ask for 'inline' ...
> ... MSVC is wrong but we can help it by providing
> a "hint" in the form
I also agree msvc 'should' have been able to resolve
it as it was. It had the choice of 2 getter's. Why
choose one, d g(), and then decide 'no fit', when
the 'next' definition is there, d g(i)? go figure ...
Hmmm - where to post this 'bug' so MS will see it?
but i hope we can get on with this great sim ...
>> Hehe me too. It sure explains those feet/meter problems.
Still to do another cvs update to check these ...
rgds,
Geoff.
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
