Replies: 4 comments 2 replies
-
To make sure you are overriding the methods with the correct parameters use the override keyword after the method declaration, this will let the compiler you are intending to override a parent classes virtual method, and will emit an compile error if you've got something mismatched. |
Beta Was this translation helpful? Give feedback.
-
It looks like the issue is that
Looking at Inherit, we can't use create here as we can't inherit from
But that caused issues with const conflicts
I've tried a few combinations to get rid of the const problem here without much luck, not sure how to proceed here other than copying the full source of trackball into my project and working on that. |
Beta Was this translation helpful? Give feedback.
-
I think you are conflating different bits of functionality rather than keeping things separate. The vsg::Inherit template class is used as a parent class of the new subclass to provide common RTTI and create functionality that does not exist in C++ itself but is useful for general C++ programming and scene graphs in particular. The template approach is an example of the "Curiously Recurring Template Pattern" or CRTP for short, a C++ idiom that helps solve the problem of implement consistent API implementations in subclasses. It isn't essential to subclass from vsg::Inherit<> when subclassing from VSG classes like vsg::Visitor but for objects that RTTI or ensuring objects are created on the heap with the appropriate ref_ptr<> returned to avoid possible memory leaks it's far more helpful in implementing base class methods for you. The Inherit::create() template method in particular provides a safer and easier to use replacement for new. With new it's possible to assign it to a C pointer and not have the compiler complain, then the developer could start doing unsafe things like deleting an object that is shared with other objects causing dangling pointers, or using it to access a dangling pointer that still points to a object that has already been deleted. Passing back ref_ptr<> makes sure memory manager is safe right from the start of an objects life, even if an exception is thrown everything is still cleaned up correctly. From your description you are mixing up the inheritance, You can implement your own trackball from scratch and so subclass from vsg::Visitor directly as vsg::Trackball does, then implement the apply(..) methods relevant to event handling. This approach for handling events leverages the VSG''s support for the "Visitor Design Pattern." If you want to subclass from vsg::Trackball then simple do: class MyTrackball: public vsg::Inherit<vsg::Trackball, MyTrackball>
{
...
}; In the vsgTutorial online book that I've started writing I cover some of these topics so worth reading: |
Beta Was this translation helpful? Give feedback.
-
Without seeing all your code I can't say what you are doing wrong. Rather than try to guess I quickly threw together a modification of vsgviewer example program in vsgExamples to illustrate how you subclass from Trackball. I have put this in a CiustomTracball branch: vsg-dev/vsgExamples@master...CustomTrackball I don't plan to merge this example as it's really just thrown together with no plan to illustrate what the code looks like. |
Beta Was this translation helpful? Give feedback.
-
I'm looking to write a modified Trackball class to change some default functionality and add some new functionality of my own. However, when I create a a new class derived from Trackball, none of the virtual functions from Trackball are overridden and the debugger doesn't even let me set breakpoints on them. As someone new to vsg coding, I guess I'm missing something very obvious here. A simplified version of my class code is shown below
In my main application the code to instantiate the trackball copied from the example code is;
viewer->addEventHandler(vsg::MyTrackball::create(camera));
Beta Was this translation helpful? Give feedback.
All reactions