Jon Berndt wrote:
>
> > > Adding an ugly cast fixes the problem:
> > >
> > > PropertyManager->Tie("forces/fbx-aero-lbs", this,1,
> > > (double (FGAerodynamics::*)(int) const) &FGAerodynamics::GetForces);
> >
> > I'll roll that change into my copy until it gets made permanently. While
>
> We'll do a little investigating, first. I want to understand why MSVC is
> having problems, first, when no other compiler appears to be complaining. We
> want to remain as cross-platform/cross-compiler compatible as possible, but
> as a matter of policy, I am extremely hesitant to make crutches in our code
> to fix a crippled compiler - if, indeed, it turns out to be a problem with
> MSVC. Do you have any explanatory backup for why MSVC isn't working with
> this? I know this sounds rude of me, but I hope you can see where I am
> coming from.
I'm not sure if it is actually a problem with MSVC or if other compilers
have different rules when it comes to taking the address of an
overloaded function. I have encountered this exact same problem before,
with even gcc requiring a cast to disambiguate pointers to overloaded
member functions. Note that the cast is portable, I've tested with gcc
2.95.3 at least.
The only explanation I can offer is that &FGAerodynamics::GetForces is
ambiguous given the declaration
class FGAerodynamics : public FGModel {
FGColumnVector3& GetForces(void);
double GetForces(int n) const;
...
The cast is a hint to the compiler which of the two GetForces() member
functions we are taking the address of. I have no idea why MSVC can't
deduce the correct member while other compilers can but that is the
essence of the problem as I understand it.
Cheers,
Bernie
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
