because it's the way Irrlicht was created and all functions are declared so in Irrlicht (well, at least most of them)...
open any header file from an Irrlicht class and you'll see...
Well thats only bc Irrlicht is build out of interface classes. but since i will probably directly use your scenenode and don't want to overwrite your code u can make them non virtual.
If u would have made a interface class with virtual function then inherit your implementation with non virtual that would make sense but only making all function virtual doesn't make any sense at all.
We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by renovation:tinkering,improving,planting flower beds.
Sudi wrote:Well thats only bc Irrlicht is build out of interface classes. but since i will probably directly use your scenenode and don't want to overwrite your code u can make them non virtual.
If u would have made a interface class with virtual function then inherit your implementation with non virtual that would make sense but only making all function virtual doesn't make any sense at all.
I see your point...
well, you know the code was made for my IrrExtensions to implement it into the Irrlicht core,
that's why I made them virtual...
now, just for you I made them all non virtual for this demo...
and a note to all: I just added the final version to my IrrExtensions and released it !!!
because I'm still working on the update system and I don't know when it'll be finished I decided to release it now...
Actually, I'd say Irr declares class virtual to a fault. Look at all the CGUI implementations, alll of which can only be derived from *within* Irrlicht or by using things like dllexport (giving lots of warning), copying the class file and all dependencies (redundency, possible incoherence), etc. And even IF you use them within irr, they often use private instead of protected member making their derivating classes STRONGLY disadvantaged, often needing to keep their own copies, calling the original CGUI funtion to retrieve a value that should be part of the class or changing irr's code to make it protected.
Of course, someone can argue that you shouldn't derive from those classes. But putting even a single virtual function inside a class is a sign it is a class that embodies a group and that needs to be specialized. Even if you don't abide by that view, it still means it should be derivable, as non derivable classes gain nothing from virtual functions. Furthermore, they prevent some of the compiler's optimizations. And let's not talk about virtual functions present in the class and not the interface. Those incur the virtual penalty of a redirection without any gain whatsoever, since they are not meant to be derived from. That also applies to base class meant to be derived, but having functions that should stay identic for all children. Not declaring it virtual speeds up it's call and I'm tired of seeing false claims to "no early optimizations" that really mean "no effort to do design and optimization as we go".
Considering this is a world-wide attack to any one doing that, don't think it's targeted at you or irr's devs. I always liked your style Acki and am grateful for Irr's devs, even working with some of them in a project or another. But this mentality and design process has got to go. It brings nothing and provide disminishing returns. Anyway, thx for sharing code ^^
yes, I see...
well, I for myself never used virtuals in my own projects, and probably never will...
I just do it for Irrlicht classes as Irrlicht was designed this way and I won't break it up...
if Irrlicht was designed in another style I'd use that for it...
Dorth wrote:Considering this is a world-wide attack to any one doing that, don't think it's targeted at you or irr's devs.
well, I take this as a personal attack on my person !!!
no, just kidding !!!
this is a constructive critism and no one was insulted, so it's welcome...
Well, abstract interfaces work like that and this approach is used for Irrlicht. This is also enforced by the minimal symbol export made by the library. All classes inherting from irrlicht's interfaces will also require virtuals. But external extension wouldn't require this, nor would purely internal stuff.
All this is of course aside from the polymorphism used in several places...
Yeah, polymorphism is fine. BUT virtual in the last derived class is bad, it doesn't bring anything. It sends a wrong message about the class. And that's not talking about functions that are exclusive to that class which incur a vtable storage and sometime look-up for no gain.
You only need (and should put) virtual in interfaces and classes that are derived from (where that function is redefined, mind you)
Wiki wrote:
If the function in question is designated "virtual" in the base class then the derived class's function would be called (if it exists). If it is not virtual, the base class's function would be called.
Virtual functions overcome the problems with the type-field solution by allowing the programmer to declare functions in a base class that can be redefined in each derived class.
So from the 2nd sentence, what Dorth says is true.
Dorth wrote:
You only need (and should put) virtual in interfaces and classes that are derived from (where that function is redefined, mind you)
