Comments on: Virtual inheritance overhead in g++ https://codesynthesis.com/~boris/blog//2008/04/17/virtual-inheritance-overhead-gcc/ Boris Kolpackov's blog about software Wed, 22 Apr 2026 09:11:10 +0000 http://wordpress.org/?v=2.2.2 By: Robert 'Groby' Blum https://codesynthesis.com/~boris/blog//2008/04/17/virtual-inheritance-overhead-gcc/#comment-398 Robert 'Groby' Blum Fri, 18 Apr 2008 18:09:23 +0000 https://codesynthesis.com/~boris/blog//2008/04/17/virtual-inheritance-overhead-gcc/#comment-398 @boris: Absolutely - I'd appreciate a quick e-mail when I can try this myself. I'm doing a bit of research into compilation speeds of C++, so I'd love to have sample cases, @Cam: Even though it's virtual, it's still a diamond. derived_impl still can call either derived::foo() or base_impl::foo(). Yes, derived::foo() is abstract - but at every invokation of foo() the compiler needs to actually find out which one you meant. I do think that memory usage and compile time are excessive, but I'm not surprised the second example is simpler. I'd love to see the gcc team's take on this.... @boris: Absolutely - I’d appreciate a quick e-mail when I can try this myself. I’m doing a bit of research into compilation speeds of C++, so I’d love to have sample cases,

@Cam: Even though it’s virtual, it’s still a diamond. derived_impl still can call either derived::foo() or base_impl::foo(). Yes, derived::foo() is abstract - but at every invokation of foo() the compiler needs to actually find out which one you meant.

I do think that memory usage and compile time are excessive, but I’m not surprised the second example is simpler. I’d love to see the gcc team’s take on this….

]]> By: boris https://codesynthesis.com/~boris/blog//2008/04/17/virtual-inheritance-overhead-gcc/#comment-395 boris Fri, 18 Apr 2008 10:07:21 +0000 https://codesynthesis.com/~boris/blog//2008/04/17/virtual-inheritance-overhead-gcc/#comment-395 Robert, Paolo, It will be hard to come up with a stand-alone test case since the generated code depends on the runtime library. But it is all open-source and the schema is publicly available so you will be able to reproduce this once the next version of XSD/e with support for delegation-based reuse is out. I can also provide makefiles, option files, etc. Let me know if you are interested. Robert, Paolo,

It will be hard to come up with a stand-alone test case since the generated code depends on the runtime library. But it is all open-source and the schema is publicly available so you will be able to reproduce this once the next version of XSD/e with support for delegation-based reuse is out. I can also provide makefiles, option files, etc. Let me know if you are interested.

]]> By: Cam https://codesynthesis.com/~boris/blog//2008/04/17/virtual-inheritance-overhead-gcc/#comment-394 Cam Fri, 18 Apr 2008 04:43:49 +0000 https://codesynthesis.com/~boris/blog//2008/04/17/virtual-inheritance-overhead-gcc/#comment-394 @Groby Isn't the point of the first example using virtual inheritance because something inherits from a base class more than once (aka the dreaded diamond)?. Or am I missing something? @Groby
Isn’t the point of the first example using virtual inheritance because something inherits from a base class more than once (aka the dreaded diamond)?. Or am I missing something?

]]> By: Paolo Bonzini https://codesynthesis.com/~boris/blog//2008/04/17/virtual-inheritance-overhead-gcc/#comment-393 Paolo Bonzini Thu, 17 Apr 2008 19:07:57 +0000 https://codesynthesis.com/~boris/blog//2008/04/17/virtual-inheritance-overhead-gcc/#comment-393 Can you report these two testcases to the GCC bugzilla (and CC me, bonzini@gnu.org on the testcases). Chances are that the build times and memory usages can be improved a lot. Can you report these two testcases to the GCC bugzilla (and CC me, bonzini@gnu.org on the testcases). Chances are that the build times and memory usages can be improved a lot.

]]> By: Robert 'Groby' Blum https://codesynthesis.com/~boris/blog//2008/04/17/virtual-inheritance-overhead-gcc/#comment-387 Robert 'Groby' Blum Thu, 17 Apr 2008 17:59:52 +0000 https://codesynthesis.com/~boris/blog//2008/04/17/virtual-inheritance-overhead-gcc/#comment-387 Hm. That has me curious to play with GCC to see what actually happens. One problem that I can spot right away in your original implementation is that derived_impl is derived *twice* from base. Once through derived, once through base_impl That means whenever you call foo() on a derived_impl, gcc needs to disambiguate between base::foo() and base_impl::foo(). (Which is a tricky problem ) Your second solution does the disambiguation for the compiler - it specfies that a call to derived_impl can only use derived::foo, which will automatically forward to base_impl::foo I'm surprised that the difference in memory usage and compile time is that big, though. If you have a stripped sample project, I'd like to run it on various other compilers.... Hm. That has me curious to play with GCC to see what actually happens. One problem that I can spot right away in your original implementation is that derived_impl is derived *twice* from base. Once through derived, once through base_impl

That means whenever you call foo() on a derived_impl, gcc needs to disambiguate between base::foo() and base_impl::foo(). (Which is a tricky problem )

Your second solution does the disambiguation for the compiler - it specfies that a call to derived_impl can only use derived::foo, which will automatically forward to base_impl::foo

I’m surprised that the difference in memory usage and compile time is that big, though.

If you have a stripped sample project, I’d like to run it on various other compilers….

]]>