[bubuga]

> Virtual inheritance means you have a diamond pattern and haven't separated your components properly.

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.

[vvanders]

Ooo, that Java remark burns. I've only touched Java seriously in the last few years of my career, I'm a hardcore C++/native type.

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.

[quotemstr]

> you've botched the hasA vs isA association

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.

[vvanders]

I think we're just going to have to agree to disagree here.

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.

[quotemstr]

I prefer not to work on projects that ban exceptions and RTTI. These features (especially exceptions) are important parts of the language, and without them, you can't reliably use most of the standard library (see bad_alloc) and can't really deliver value semantics, since you need awful hacks like two-phase initialization to communicate failure.

C++-without-exceptions is a very different and much worse language.

[vvanders]

If you're interested in limiting your market, there's a whole embedded and high performance space where this is critical.

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...

[quotemstr]

> If you're interested in limiting your market, there's a whole embedded and high performance space where this is critical.

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.