Re: [Flightgear-users] Fedora Core 4 x86-64 and FlightGear

[Pete]

Yeah, sorry, I was mucking about and did a few test runs with some 
int->long changes. That's one of them. However, I can't believed I 
missed the template int in there. Dumb, but maybe that will help.

As for the int,long,string, whatever. There should be a somewhat 
portable way to do this. When I did this for a 32 to 64 bit port at 
work, we just changed them all to long's because we knew the Intel and 
GCC compilers both treated longs == pointers. I find it odd that the Win 
compiler will treat long == int because that provides no standard C/C++ 
64 integer. If that's the case, then do they have a new type to store a 
64 bit integer, or do they use some other magic?

Anyway, the lesson is to never assume a pointer size cause it will bite 
you eventually. Thanks.

Mathias Fröhlich wrote:

Hi,

strange:
my recent checkout contains a FGAIBase::_getID() function returning an int not 
a long. Have you modified that?
And with that, the constructor

SGRawValueMethods<FGAIBase,int>(*this, &FGAIBase::_getID)

should exist.
If you want to make _getID return a long, you have to change that to:

SGRawValueMethods<FGAIBase,long>(*this, &FGAIBase::_getID)

else you will get that error you told.

Anyway, under all 64 bit platforms an int is not sufficient to store all the 
bits we have in a pointer. Consequently the id we return here might not be 
unique.
But using long for that will not even be sufficient for 64 bit Windows since 
Microsoft has decided to define sizeof(long) = sizeof(int) = 4 even on 64 bit 
platforms!

May be we should stringify that id and return a hex number as a string here.

   Greetings

       Mathias

On Samstag 25 Juni 2005 02:51, Pete Buelow wrote:
 

Hello, short time lurker, first time poster. I have a question and I
hope someone has an answer. BTW, I couldn't find a dev maillist, so
please don't flame me if this isn't the right forum.

I'm trying to build FlightGear for FC4 on an nifty new amd64 game
machine. I used to fly on a slightly slower Athlon, but want to step up
to the plate and see if things are that much better with my new video
card and 64 bit processor. Here's the issue.

I'm building the CVS version of both SG and FG and there a a bunch of
int->long conversion errors. Most are pretty trivial to fix. However, I
haven't really done much OO or C++ since college (embedded C for years,
Java this summer!). There's a tricky pointer conversion mixed with class
decl issue that is split between SimGear and FlightGear. The problem is
with two files so far, but I'm sure it's worse than that. I discovered
this when building FlightGear after SimGear in the file AIBase.cxx. The
code as follows won't build natively on a 64 bit box.

long FGAIBase::_getID() const {
return (int)(this);
}
void FGAIBase::bind() {
props->tie("id", SGRawValueMethods<FGAIBase,int>(*this,
&FGAIBase::_getID)); ...

The problem shows up when casting this to an int in such a way. I
crossed my fingers hoping that simply removing the int cast would solve
my problem (that every other bit of code would understand and avoid
conversion), but no such joy. The following decl in the file
simgear/props/props.hxx causes the compile to then choke.

template <class C, class T>
class SGRawValueMethods : public SGRawValue<T>
{
public:
typedef T (C::*getter_t)() const;
typedef void (C::*setter_t)(T);
SGRawValueMethods (C &obj, getter_t getter = 0, setter_t setter = 0)

: _obj(obj), _getter(getter), _setter(setter) {}

virtual ~SGRawValueMethods () {}

with the following compiler error

AIBase.cxx: In member function ‘virtual void FGAIBase::bind()’:
AIBase.cxx:173: error: no matching function for call to
‘SGRawValueMethods<FGAIBase, int>::SGRawValueMethods(FGAIBase&, long int
(FGAIBase::*)()const)’
/opt/fg/include/simgear/props/props.hxx:395: note: candidates are:
SGRawValueMethods<C, T>::SGRawValueMethods(C&, T (C::*)()const, void
(C::*)(T)) [with C = FGAIBase, T = int]
/opt/fg/include/simgear/props/props.hxx:391: note:
SGRawValueMethods<FGAIBase, int>::SGRawValueMethods(const
SGRawValueMethods<FGAIBase, int>&)
AIBase.cxx: In member function ‘long int FGAIBase::_getID() const’:
AIBase.cxx:364: error: invalid conversion from ‘const FGAIBase* const’
to ‘long int’

So, the question is, how is getter_t/setter_t defined and where and why
is T an int? I see lots of references to getter (tons of grep work
here), and it looks to me like C::*getter_t() should either be a long or
char*, not int, but for some reason, I'm missing the obvious. I'll
gladly provide patches and fixes when I finally make them, but I'm
having trouble tracking down the source of the "no matching function
call" error 'cause I ain't so good with C++. I'll work on it more
tonight though.

Also, there are a few GL cast issues where some values are again
explicitly cast to int from double or long and then passed into GL
functions. Sorry, those have long passed by, but I can probably find
them if anyone is interested.

Any help would be appreciated. Thanks

-Pete


_______________________________________________
Flightgear-users mailing list
Flightgear-users@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d
   


 



_______________________________________________
Flightgear-users mailing list
Flightgear-users@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d