Re: [Flightgear-devel] MSVC6 Build Progress
Bernie Bright wrote: > > You can keep the enum private if you add the following declarations > immediately afterwards: > > struct mouse; > friend struct mouse; > > It seems that MSVC doesn't grant the nested mouse decl. any special > access privileges to its surrounding class. Following up my own reply, I believe that MSVC is correct and that gcc is wrong. According to Stroustrup and the Standard, members of a nested class have no special access to members of the enclosing class, ie a nested class can only access public members of its enclosing class. Cheers, Bernie PS I notice this change has been commited. Thanks. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 Build Progress
> *connects to http://www.uk.research.att.com/vnc/ and downloads VNC for the > PC and Mac* > *installs VNC in both computers* Buys the second license to the appropriate version of Windows > *does the 'happy dance'* ... it's the Microsoft tax dance. Every computer that runs, or remotely controls, a Microsoft Windows system requires a license for that version of Windows. Therefore, your MacOS or Linux system, if used to control a remote MSWin machine, requires a license to be purchased for that chassis. Doesn't need to be installed. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 Build Progress
On Thursday, March 28, 2002, at 06:41 PM, Andy Ross wrote: > Jonathan Polley wrote: > > *trundles downstairs to PC* > > *makes edit* > > *compiles* > > *says dirty words* > > *trundles back upstairs to Mac* > > *ssh's into home machine from 7 miles away at work* > *sips coke* > *cvs update's FlightGear source* > *compiles* > *makes edit* > *debugs* > *sticks out toungue* > *decides to get up and stretch, maybe get more coke* *connects to http://www.uk.research.att.com/vnc/ and downloads VNC for the PC and Mac* *installs VNC in both computers* *does the 'happy dance'* *Make's Bernie's recommended changes* *compiles* *does the 'happy dance' again* *can't live without his GUIs* Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 Build Progress
Bernie,
I just made your change and now input.cxx compiles fine.
/**
* Settings for a mouse.
*/
struct mouse; // This is new code
friend struct mouse; // This is new code
struct mouse {
mouse ();
virtual ~mouse ();
int x;
int y;
SGPropertyNode * mode_node;
SGPropertyNode * mouse_button_nodes[MAX_MOUSE_BUTTONS];
int nModes;
int current_mode;
mouse_mode * modes;
};
Thanks!
Jonathan Polley
On Thursday, March 28, 2002, at 06:23 PM, Bernie Bright wrote:
> David Megginson wrote:
>>
>> Jonathan Polley writes:
>>
>>> I reverted input.hxx back to what was in CVS and moved the enumeration
>>> from being private to public and MSVC now likes using an enumeration
>>> element to define an array. Why the compiler cares about an enum being
>>> private vs. public, I will never know (although I have seen this
>>> behavior
>>> before). I also brought in the newest input.cxx and I can now run
>>> FlightGear again.
>>
>> Does it still work if the enum is protected? I'd like to keep things
>> as well encapsulated as possible.
>>
>
> You can keep the enum private if you add the following declarations
> immediately afterwards:
>
> struct mouse;
> friend struct mouse;
>
> It seems that MSVC doesn't grant the nested mouse decl. any special
> access privileges to its surrounding class.
>
> Bernie
>
> ___
> 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
Re: [Flightgear-devel] MSVC6 Build Progress
Jonathan Polley wrote: > *trundles downstairs to PC* > *makes edit* > *compiles* > *says dirty words* > *trundles back upstairs to Mac* *ssh's into home machine from 7 miles away at work* *sips coke* *cvs update's FlightGear source* *compiles* *makes edit* *debugs* *sticks out toungue* *decides to get up and stretch, maybe get more coke* Andy -- Andrew J. RossNextBus 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
Re: [Flightgear-devel] MSVC6 Build Progress
David Megginson wrote: > > Jonathan Polley writes: > > > I reverted input.hxx back to what was in CVS and moved the enumeration > > from being private to public and MSVC now likes using an enumeration > > element to define an array. Why the compiler cares about an enum being > > private vs. public, I will never know (although I have seen this behavior > > before). I also brought in the newest input.cxx and I can now run > > FlightGear again. > > Does it still work if the enum is protected? I'd like to keep things > as well encapsulated as possible. > You can keep the enum private if you add the following declarations immediately afterwards: struct mouse; friend struct mouse; It seems that MSVC doesn't grant the nested mouse decl. any special access privileges to its surrounding class. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 Build Progress
On Thursday, March 28, 2002, at 04:14 PM, David Megginson wrote: > Does it still work if the enum is protected? I'd like to keep things > as well encapsulated as possible. *trundles downstairs to PC* *makes edit* *compiles* *says dirty words* *trundles back upstairs to Mac* MSVC gives a similar error for protected enumerations as it does for private: .\src\Input/input.hxx(322) : error C2248: 'MAX_MOUSE_BUTTONS' : cannot access protected enumerator declared in class 'FGInput' .\src\Input/input.hxx(249) : see declaration of 'MAX_MOUSE_BUTTONS' Sorry, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 Build Progress
Jonathan Polley writes: > I reverted input.hxx back to what was in CVS and moved the enumeration > from being private to public and MSVC now likes using an enumeration > element to define an array. Why the compiler cares about an enum being > private vs. public, I will never know (although I have seen this behavior > before). I also brought in the newest input.cxx and I can now run > FlightGear again. Does it still work if the enum is protected? I'd like to keep things as well encapsulated as possible. Thanks, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 Build Progress
Its ALIVE!!! I reverted input.hxx back to what was in CVS and moved the enumeration from being private to public and MSVC now likes using an enumeration element to define an array. Why the compiler cares about an enum being private vs. public, I will never know (although I have seen this behavior before). I also brought in the newest input.cxx and I can now run FlightGear again. Let me know when the decision has been made on how FlightGear will be working around MSVC's inability to deal with overloading and I can revert all my files back to CVS. Thanks for the help! Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 Build Progress
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?
Could you try this one:
define the const in the header file:
class foo {
const doube bar;
}
and in the .cxx file:
const double foo::bar = 3.0;
If this works for MSVC I think we can handle the problem.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 Build Progress
Jonathan Polley writes: > This brings about the philosophical question, Is is possible to work > around ALL MSVC bugs? I'm pretty sure that people are successfully building FlightGear already with MSVC 6. > 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. That's interesting. The enum is a declaration, not a definition. > 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. There's another, public enum earlier in input.hxx. I can make the second enum protected if that helps the compiler. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC6 Build Progress
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
Re: [Flightgear-devel] MSVC6 Build Progress
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
re: [Flightgear-devel] MSVC6 Build Progress
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. 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). 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
Re: [Flightgear-devel] MSVC6 Build Progress
Jonathan Polley wrote:
> I am getting closer. I was able to resolve the link-time errors (added
> a slew of new files to the MSVC project) and got an executable! There
> was one build problem in that MSVC did not like an enumeration being
> used to define the size of an array:
>
> .\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.
>
> Once I tried running, I crashed in main.cxx/fgReshape(), line 1166. It
> appears that MSVC does not generate the proper code for:
>
> globals->get_viewmgr()->get_view(i)->
> set_aspect_ratio((float)view_h / (float)width);
>
> and I wound up using a temp variable in order for it to work:
>
> FGViewer *Viewer;
> ...
> Viewer = globals->get_viewmgr()->get_view(i);
> Viewer->set_aspect_ratio((float)view_h / (float)width);
>
> Finally, I was able to run again and crashed in FGInput::_init_mouse(),
> FlightGear died in the call to:
>
> mode_node->getChild("button", k), line 658-ish
>
> Assigning that to a local did not solve the problem, so I am now stuck,
> again. At least the above line was added in version 1.35 of input.cxx,
> rather than it being a problem with MSVC that was awoken as a side
> effect of another change.
>
> Any ideas?
>
> Thanks,
>
> Jonathan Polley
>
>
> p.s. Has a solution been decided upon for the MSVC overloading
> problem? I was able to work around the issue by renaming the vector
> methods to have a suffix of _V, but I don't know if that is what is
> preferred. My vote, if I may have one, is to not overload. This is a
> personal preference from being burned, in the past, by compilers that
> aren't too smart. Granted these were older compilers (c. 1985-97), and
> they weren't C++ compilers (Ada-83 and Ada-95), but I have been made a
> tad gun shy.
Personally, I think I'd like a cast or typedef better than this.
>
>
> ___
> 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
[Flightgear-devel] MSVC6 Build Progress
I am getting closer. I was able to resolve the link-time errors (added a
slew of new files to the MSVC project) and got an executable! There was
one build problem in that MSVC did not like an enumeration being used to
define the size of an array:
.\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.
Once I tried running, I crashed in main.cxx/fgReshape(), line 1166. It
appears that MSVC does not generate the proper code for:
globals->get_viewmgr()->get_view(i)->
set_aspect_ratio((float)view_h / (float)width);
and I wound up using a temp variable in order for it to work:
FGViewer *Viewer;
...
Viewer = globals->get_viewmgr()->get_view(i);
Viewer->set_aspect_ratio((float)view_h / (float)width);
Finally, I was able to run again and crashed in FGInput::_init_mouse(),
FlightGear died in the call to:
mode_node->getChild("button", k), line 658-ish
Assigning that to a local did not solve the problem, so I am now stuck,
again. At least the above line was added in version 1.35 of input.cxx,
rather than it being a problem with MSVC that was awoken as a side effect
of another change.
Any ideas?
Thanks,
Jonathan Polley
p.s. Has a solution been decided upon for the MSVC overloading problem?
I was able to work around the issue by renaming the vector methods to have
a suffix of _V, but I don't know if that is what is preferred. My vote,
if I may have one, is to not overload. This is a personal preference from
being burned, in the past, by compilers that aren't too smart. Granted
these were older compilers (c. 1985-97), and they weren't C++ compilers
(Ada-83 and Ada-95), but I have been made a tad gun shy.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
