That “this”-reference is passed in the ECX register every time you perform a member function call to a class, while the register is already set if you make the call from an instance method of the same class. This means switching between different class instances at a high frequency (like in games) is a very CPU intens operation compared to have pure static and/or global functions.

Thats all well and good, except that I just showed you a link to compiler-explorer, showing that the exact same asm is generated for both cases. Including used registeres. Maybe its a matter of calling convention? Maybe you can try to put together some short codesample on godbolt to emphasise what your point is (so that we can eigther see what you mean, or you'll see for yourself that you are wrong).

Shaarigan said:
I don't know about static functions but as soon as you are referencing any static member variable of the class, there will also be some kind of overhead to populate the pointer to the static class memory in heap I guess

I'm pretty sure static class member are just like regular static variables. Again, look at the generated assembly: https://godbolt.org/z/kb9Shp

Foo::X(int):                            # @Foo::X(int)
        add     dword ptr [rip + Foo::z], edi
        ret
(anonymous namespace)::x(int):                  # @(anonymous namespace)::x(int)
        add     dword ptr [rip + (anonymous namespace)::z], 10
        ret

(there is a minor difference which I think is a bug in clang, where the compiler inlines the “10” on the global function, even though I specify noinline).

So yeah. Unless you can prove otherwise, your statement are just plainly wrong. Sorry, but thats an important point not to scare people by making them think that just by using a class they get performance degradation.

Juliean said:

That “this”-reference is passed in the ECX register every time you perform a member function call to a class, while the register is already set if you make the call from an instance method of the same class. This means switching between different class instances at a high frequency (like in games) is a very CPU intens operation compared to have pure static and/or global functions.

Thats all well and good, except that I just showed you a link to compiler-explorer, showing that the exact same asm is generated for both cases. Including used registeres. Maybe its a matter of calling convention? Maybe you can try to put together some short codesample on godbolt to emphasise what your point is (so that we can eigther see what you mean, or you'll see for yourself that you are wrong).

Shaarigan said:
I don't know about static functions but as soon as you are referencing any static member variable of the class, there will also be some kind of overhead to populate the pointer to the static class memory in heap I guess

I'm pretty sure static class member are just like regular static variables. Again, look at the generated assembly: https://godbolt.org/z/kb9Shp

Foo::X(int):                            # @Foo::X(int)
        add     dword ptr [rip + Foo::z], edi
        ret
(anonymous namespace)::x(int):                  # @(anonymous namespace)::x(int)
        add     dword ptr [rip + (anonymous namespace)::z], 10
        ret

(there is a minor difference which I think is a bug in clang, where the compiler inlines the “10” on the global function, even though I specify noinline).

So yeah. Unless you can prove otherwise, your statement are just plainly wrong. Sorry, but thats an important point not to scare people by making them think that just by using a class they get performance degradation.

Very well said.

Simitus said:

I would be curious to see any benchmarks supporting this assertion? - it would really call into question the entire purpose of using C++. Without OOP you simply are not going to be using that language at anything near its potential and it would be very difficult to meaningfully encapsulate your data or to maintain and expand upon it.

Not to mention most major 3d game engines were built on top of C++, one of them being Unreal Engine and because of that, features high portability across platforms. This is usually the kind of feedback that disorients the learner, with out providing proper benchmarks of this, it is nothing but speculation.

I have coded games in just C using nothing but global functions back in the day of DOS and when your project starts to become very large, it is very hard and almost confusing to keep track of everything. My hats off to all those brave C programmers, we all had it hard.

Simitus said:

@rafaelsantana I can't even imagine it. Just the added work of manually selecting your sound card in the pre Direct-X era..

Heck, you should of seen the code to just load VESA drivers, we had to write TSR programs for those!