GoingNative 26: The final* Episode

Download this episode

Download Video

Download captions

Download Captions


*(...look at that weird casing...something punny is going on...)

Join us as we final-ly hear from Patrick Satyanathan about the "keyword" known as "final," introduced in C++11. He provides an excellent amount of detail and insight on the two primary uses of final, as well as related information regarding the compiler and compiler-generated code. Learn how effective use of this feature can lead to better-organized and better-performant code!

This episode is brought to you in part by viewers like you! If you want to see an episode on anything native, let us know in the comments, and we'll do our best to make it happen!

See you next month!



Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image

      Would love to see more on C++14.  Thanks.

    • User profile image

      A good explanation of the benefits of 'final'.

      This inspired me to double-check my C++/CLI code and I see a similar benefit if I use 'sealed' for my C++/CLI classes. Thanks for the nudge to try this Patrick and Gabriel!

    • User profile image

      @schroedl:=) Glad we could help!

    • User profile image

      Still no good reasons given to why would anybody need to declare a class or a virtual function 'final'. The 'final' actually looks like a misfeature in C++11.
      Firstly, from a design perspective, it's a misplaced responsibility. The decision of whether to derive or not from a class (or override a virtual function) resides on the consumers of the class, not the class itself. The class cannot and shouldn't know whether it's final.
      Secondly, there is a question of optimization. Can it actually be helped by 'final'? -- Not really. The proper OO design assumes the call of the derived objects via the base pointer: Liskov Substitution Principle. In which case, for a compiler to eliminate the virtual call it needs to know the dynamic type of the object. Whether compiler is able to that in a particular situation doesn't depend on the 'final'.

    • User profile image
      Patrick Sathyanathan

      With proper use of "final" the developer can tell the compiler that a specific method will be called irrespective of the dynamic type of the object. The analysis to determine the latter is in general complex and expensive. "final" provides a way to get the benefit of that analysis without having to do it and does not violate the Liskov Substitution Principle.
      Whether the keyword "final" is necessary for robust and extensible C++ libraries (and programs) is a matter of discussion in the C++ community.
      The keyword "final" allows programmers to directly express aspects of their design. Like any good language feature, its effective use requires careful analysis and experience. For analysis, please consider this FAQ entry http://www.stroustrup.com/C++11FAQ.html#final

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.