Doh! I just had a thought. Could MSVC be having a problem because the enum containing MAX_MOUSE_BUTTONS is *private* rather than public? I have seen some compilers apply different rules to private vs. public data in that they take an 'ignorance is bliss' approach to private data (i.e., since this is private, I can not know anything about its representation at compile time so I will treat it all as dynamic). I have seen this behavior with const's since, although they are static, they get allocated in data space.
Just a thought, Jonathan Polley On Thursday, March 28, 2002, at 07:26 AM, Jonathan Polley wrote: > > On Thursday, March 28, 2002, at 06:12 AM, David Megginson wrote: > >> Jonathan Polley writes: >> >>> .\src\Input/input.hxx(321) : error C2248: 'MAX_MOUSE_BUTTONS' : cannot >>> access private enumerator declared in class 'FGInput' >>> .\src\Input/input.hxx(250) : see declaration of >>> 'MAX_MOUSE_BUTTONS' >>> >>> Changing the enumeration to a series of #defines solved that problem. >> >> [expletive deleted] The only reason I use enums instead of constants >> is to work around earlier MSVC bug reports, since MSVC barfed on >> constants. > > This brings about the philosophical question, Is is possible to work > around ALL MSVC bugs? > >> Using defines for constants or macros in a header file is >> out of the question -- on a project this size, they create serious >> management problems (i.e. no other class can use a variable, constant, >> or method with the same name). > > I also don't like the name space problems that #defines cause, especially > when it forces the programmer to mangle the names in order to avoid > conflicts. My guess as to what is happening here is that MSVC is > deciding to make the enum dynamic rather than static. Since it is > dynamic, the compiler does not believe that it can know the value of > MAX_MOUSE_BUTTONS at compile time and will make a function call to > determine its value instead. I am use to seeing this behavior with brain > dead Ada compilers. > > I suppose I could check myself, but do you know of any other instances of > this construct in the code? Since this is the only complaint I got from > the compiler, it would be interesting to see where MSVC liked the > construct to see if I could find out why. > >> Thanks for looking into these problems. >> >> >> All the best, >> >> >> David >> >> -- >> David Megginson >> [EMAIL PROTECTED] >> >> >> _______________________________________________ >> Flightgear-devel mailing list >> [EMAIL PROTECTED] >> http://mail.flightgear.org/mailman/listinfo/flightgear-devel >> > > Jonathan Polley > > > _______________________________________________ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
