I was reading some C++ object-oriented programming notes that mentioned that we should avoid wrapping functions in classes if it is not required, since wrapping 'things' in classes would reduce efficiency.
Is it true that wrapping functions in classes reduces efficiency? What other 'things' could reduce efficiency when wrapped in classes?
This statement is either wrong or incomplete:
Calling a non-virtual member function requires exactly the same code as calling a free function with one additional pointer argument. That's peanuts.
For a fair comparison: writing a free function equivalent to the member function would require exactly this additional argument to access to the object's state (or pass the pointer to another function that would need to access the object state): in this case, the same code is generated so that there is no real overhead.
If the object state is not at all relevant, you could spare this extra paramater. But you could then as well make the function a static member function, which leads to exactly the same assembly code as a free function.
Calling a virtual member function requires an additional overhead: for each call, the right function to call must first be found. This is usually done with a virtual table. It's a couple of extra nanoseconds (some more nanoseconds in case of multiple inheritance combined with virtual inheritance, but this is quire rare in practice since it can be avoided with composition over inheritance). In most cases (i.e. if you're not working on a rendered in major game), there is no need to worry about real performance issues.
For a fair comparison, if you need polymorphic behavior and would write the same functionality with a free function, you'd have to add a couple of extra if-else or switch-case-default to achieve the same result, and these would also cost a couple of nanoseconds more at each call and perhap's several times. So the cost-benefit in terms of performance is not necessarily in favor of the free function. (not to speak of the more difficult maintenance)
Conclusion: write your code with a proper design. Use member function when needed. Make the function virtual if polymorphism is required. At a later stage, if you really encounter performance issues, use a profiler to see where tthe real bottleneck is.
Quote of the day:
Don't diddle code to make it faster — find a better algorithm.
Do you have an application where you need to squeeze out the last bit of performance from the user’s computer? Chances are that you don’t. For 99.9% of your code the nanoseconds that you might waste by wrapping things in a class don’t matter.
And when it matters, you will likely find that optimisation is a lot easier if something is wrapped in a class and you have just one place to optimise.
What you really should think about: Development time. If you want speed, then writing code that is easier to maintain and develop saves you time, which you can use to find places where you can save milliseconds instead of nanoseconds.
"At so-many billion operations per second," these days, *it probably just doesn't matter anymore."
We've gotten really good at "throwing silicon at it," maybe because these days we've got so much silicon to throw.
What does still matter, however, is clarity, and maintainability. Please focus only upon these things, not [theoretical worries about ...] "efficiency."
