Hi Phil, It's not actually a compiler bug, it's a quirk in the language itself. See this entry in the C++ FAQ, which explains the method hiding problem better than I can, and also gives a workaround: http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.9
-Mike > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Philip Taylor > Sent: Friday, March 30, 2007 7:15 PM > To: osg users > Subject: RE: [osg-users] build break... > > I am surprised that you get the error since the code looks legal. The > whole > point of polymorphism is to allow exactly this case - a null method in the > base class that a derived class is then free to overload. It is not just a > null method, it is also default functionality. > > Unless I am missing something here, it suggests to me that you have hit a > C++ compiler bug. b.bar(FOO2) should be calling the base class method, > otherwise what's the point of inherited methods. You could try putting a > semi-colon within the curly braces - not necessary but it may help the > compiler to understand just what it has got. > > PhilT > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Mike Wittman > Sent: 30 March 2007 22:37 > To: osg users > Subject: RE: [osg-users] build break... > > > > >Yes, that would definitely work. The other alternative which is > cleaner > > >is to detect when I'm invoking a virtual method defined in a base class > > >and generate code that casts the object pointer to the base class type > > >before invoking the method. I've got sufficient type information to do > > >that, it's just a matter of putting in the effort to implement it... > > > > > >-Mike > > > > Speaking strictly as a C++ guy wouldn't what you're proposing be a giant > > no-op? Isn't the whole point of virtual methods to give you the ability > to > > call derived class methods when using a base class 'this' pointer? So > > wouldn't casting from a derived type 'this' pointer to a base type > 'this' > > pointer and then calling a virtual method be the same as just using the > > derived type? > > > > J. > > Yep, it's a no-op from a run-time perspective. But the problem I'm > trying to solve actually manifests as a compile-time error, since C++ > overload resolution does not take inherited virtual methods into > account. Basically, if you invoke an overloaded virtual method on a > derived type pointer, and that derived type does not override all of the > overloaded instances of that virtual function in the base class, you can > get a compilation error. > Here's a simple example: > > enum T1 { FOO1 }; > enum T2 { FOO2 }; > > struct A { > virtual void bar(T1) { } > virtual void bar(T2) { } > }; > > struct B : public A { > virtual void bar(T1) { } > }; > > void error() > { > B b; > b.bar(FOO2); // gives error since compiler cannot find void bar(T2) in > B. > } > > > There are several subclasses in OSG that satisfy this property. It's > caused a minor headache when generating code to invoke the virtual > functions in those classes. > > -Mike > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > > > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
