Virtual functions

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Virtual functions

      GCG Book use virtual functions heavily. I personally have no problem with them, but I read that they produce a lot of overhead and they should be used carefully. But it is bottleneck on consoles mostly, on PC it is not a big deal.

      So I'm just curious, is it viabale to use them or maybe there is some alternative technique to maintain abstraction?
    • Virtual functions are pretymuch the bane of OOP. You use virtual functions when you want to override a certain behavior (read method) for your derived class rather than the one implemented for the base class and you want to do so at run-time through a pointer to the base class.
      It's a bit of a hassle because you need to have virtual destructors and smart pointers to prevent memory leaks. There's nothing preventing you from just writing a new object instead of inheriting one, if you think that would be easier :)
    • but I read that they produce a lot of overhead and they should be used carefully


      You should generally keep any inheritance trees as flat as possible, but don't be afraid to make use of virtual functions when they make sense, sometimes they are used extensively where a different approach would make sense, for example if you are abstracting a system to allow for different implementations ie. rendering with OpenGL or Direct3D, the PIMPL idiom may make more sense, and also remove the cost of the virtual function call, use them where they make sense, such as in a base class such as the Component class.

      So I'm just curious, is it viabale to use them or maybe there is some alternative technique to maintain abstraction?


      Absolutely, as I mentioned before use them where they fit, some alternatives (but keep in mind not replacement).
      • The PIMPL Idiom as I mentioned before.
      • Static Polymporphism (a little scroll down the page), I have never seen this used in a project, only in experiments, but it is another option albeit with its own limitations.
      • Coercion Polymorphism, If you REALLY need to avoid virtual function calls, and have an internal identifier you can check, you could actually static_cast to specific sub-classes and call the method directly. If you end up using RTTI than you really aren't saving any overhead compared to virtual function calls anyway.

      With this being said, I would say that both points 2 & 3 are more hassle than they are worth. I generally make use of the PIMPL idiom & virtual functions when I need any sort of abstraction. I work with libraries and game code which make heavy use (sometimes excessively but none the less) and many games have been shipped with them, so they are certainly viable (and almost definitely unavoidable).

      It's a bit of a hassle because you need to have virtual destructors


      You get used to it and it becomes habit, also most compilers such as g++ will give you a nice warning on the class in question ie. 'Has virtual method 'func' but non-virtual destructor'.

      smart pointers to prevent memory leaks


      I disagree, you don't need smart pointers just because you have a polymorphic class, so long as the base class has a virtual destructor and you delete the memory your good, however smart pointers are great and I really encourage using them.

      References
      en.wikipedia.org/wiki/Curiously_recurring_template_pattern
      catonmat.net/blog/cpp-polymorphism/
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • Virtual functions are heavily used in the games industry to provide abstraction between multiple systems. They make your code much more versatile and reusable, allowing systems to talk to each other without caring what the underlying implementation is.

      Virtual functions do have an overhead. You have an extra table lookup (very small), but the big thing is that the computer can't predict the code-line, so it can't fetch the instructions it thinks it'll need and load them into the CPU cache. This will cause a cache miss. This cache miss doesn't really matter on larger systems that might only get called a few times a frame, but it can bring your game to a screeching halt on really tight inner loops. For this reason, a lot of graphics systems I've worked with avoid virtual functions (some are written in straight-C). Gameplay systems make heavy use of OOP.

      -Rez