Virtual inheritance means you have a diamond pattern and haven't separated your components properly. It should have never made it into the language as far as I'm concerned.
I've seen this argument pop out time and again as if it was a mantra of sorts, and more often than not it comes from someone with a background almost exclusively founded on Java.
Their line of reasoning essentially boils down to "Java doesn't support it, the people behind Java said something about it, therefore it's bad".
But C++ isn't Java, nor does Java dictate what is correct or what makes sense.
Particularly when the only assertion you could come up with to criticize multiple inheritance was a comment that had nothing to do with C++ or even OO programming, but only to do with your personal taste regarding your superficial impressions regarding software design.
Here's the issues I take with virtual inheritance:
1. It complicates the vtable and function/member calls leading to another level of indirection, so from a performance perspective it's a negative mark.
2. The more fundamental problem is that you've botched the hasA vs isA association. If you have two classes that share a base class then that base class should be refactored into a component that can then be used as a member without polluting the class hierarchy. This leads to better composability since you can now pass this object around without pulling a whole class hierarchy with it.
You're welcome to use virtual inheritance all you want in your projects but much like knowing what subset of C++ to use(and what not) you'll never see it in code I work on.
No you haven't.
In many senses, C++ inheritance is just shorthand for composition. That's why things like private inheritance are useful. Through this lens, virtual inheritance is automatic composition in which multiple composed objects each have a pointer to some shared object (the virtual base). It doesn't mess with hasA vs. isA at all.
> knowing what subset of C++ to use
This idea that a good coding standard necessarily bans parts of C++ has done massive damage to the C++ community. The correct subset of C++ to use is C++. Turning off parts of the language is just a cheap way to look sagacious while infantilizing developers. Every feature has its place.
There's a been a fair number of projects I've worked on where exceptions and RTTI introduced too much memory/perf overhead so we explicitly didn't use them. I don't feel like we were worse off for not having them.
C++-without-exceptions is a very different and much worse language.
Considering LLVM takes the same stance[1] and they're the ones implementing language features that's good enough for me.
[1] http://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or...
Well, it's a preference, not a hard requirement. I'll hold my nose and work on such a codebase if there are other reasons, like the project itself being very interesting.
> Considering LLVM takes the same stance
IMHO, that's a mistake. But LLVM is an example of a project that's compelling enough to work on despite what I consider a set of poor language choices.