We can call static member function through both class name and objects...but we generally use class name to call static member function instead of objects....
Is there any performance benefit in it by using class name or is it just to remove confusion by not calling through object

Dani AI

Generated

A few practical follow-ups that build on , and without repeating the disassembly shown above.

If the question is "is it worth changing calls for speed on my platform", measure it. A tiny microbenchmark or a quick assembly check on your compiler/flags will settle it for your toolchain. A minimal test program to compare the two call forms looks like this:

struct C {
    static void s() {}
    void m() {}
};

int main() {
    C c;
    c.s();     // call via object
    C::s();    // call via class

    void (*pf)() = &C::s;     // plain function pointer for static
    void (C::*pmf)() = &C::m; // pointer-to-member for non-static
}

To inspect what your compiler generates: compile with differing optimization levels and without inlining (for example, -O0 and -O2, and -fno-inline), or use the Compiler Explorer at Godbolt to compare GCC/Clang/MSVC output side-by-side. For runtime microbenchmarks, prevent inlining and other optimizations that remove the call, and repeat long enough to get stable timings.

Useful technical notes not shown above:

  • A static member function has no implicit this and cannot be virtual. See the C++ language reference on member functions for details: C++ member functions.
  • Taking the address of a static member yields a plain function pointer; taking the address of a non-static member yields a pointer-to-member (different type and call syntax).
  • Shadowing/hiding and overload resolution follow normal compile-time lookup rules; the static call chosen depends on the compile-time type used at the call site.

Practical recommendation: prefer Class::func() for clarity and to avoid accidental side effects or name-hiding surprises. If performance is critical, verify on the exact compiler and flags you use rather than assuming one behavior for all toolchains.

Recommended Answers

All 4 Replies

Well my first hunch was no ofcourse there would be no difference calling how you call a static member function, the class / object would only be used by the compiler to mangle the name... Thought I usually ask my compiler for help, a test program says more than a mear answer, anyway... my compiler (gcc 3.4.? ) says something in the lines of t is not a class or namespace (ie you cant use :: operator on a object, it is purely a naming operator)... I'm not a standards following guy, I do what works, and this does not ;) (ie I cant answer to if this should be possible or not)

Since the static method will always be called on the class instead of the instance you might get a tiny performance boost by using it like that, but most likely the compiler will optimise it that way for you.

Well it seem I was wrong...

btw, no it will not be called through the object, it is only used for name resolution, only virtual functions will be called through virtual tables...

(try assembler output with your favorit compiler (gcc -O0 -c -S below)

sample output
(first one is test::t() ; second is t.t())

call	__ZN4test1tEv
	call	__ZN4test1tEv

here is a non static function call, with object on stack

leal	-1(%ebp), %eax
	movl	%eax, (%esp)
	call	__ZN4test2t2Ev

And here are a virtual call, with same object on stack but through pointer ofcourse...

movl	-28(%ebp), %eax
	movl	(%eax), %edx
	movl	-28(%ebp), %eax
	movl	%eax, (%esp)
	movl	(%edx), %eax
	call	*%eax

else it would look like this (trough stack variable)

leal	-24(%ebp), %eax
	movl	%eax, (%esp)
	call	__ZN4test2t3Ev

Or like this (through obscured reference so it can not know the type)

movl	-32(%ebp), %eax
	movl	(%eax), %edx
	movl	-32(%ebp), %eax
	movl	%eax, (%esp)
	movl	(%edx), %eax
	call	*%eax

All compiled unoptimized ofcourse

commented: Thanx +1

Just saw the disassembly code through VC6.0...In case of object it automatically gets optimised to classname::static function call

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.