[Request] Please remove multiple inheritance from interfaces

[Max]

It breaks binary compatibility when building with MSVC.

Very little point in having a dynamic library if the release version won't work for debug builds, or when the dll was compiled with different compiler.
On the other hand, single inheritance doesn't break ABI.

I know it's not an easy thing to do, as changes would have to be quite big. And yet I think it's very beneficial for QOL purposes.

[kornerr]

How does multiple inheritance break MSVC ABI?

[Max]

With MI, VTables are incompatible between debug and release builds. I've also seen discrepancy when building with different compiler versions (for instance exe with VS11 and dll with VS10).

[Kulik]

Provide references to these claims please.

I know for a fact that we can't rely on ABI compatibility between different MSVC runtimes. I would love to be proven wrong. Multiple inheritance has nothing to do with it.

WTF are QOL purposes?

[Max]

It's not about runtimes, but rather about interface between dynamic libraries.
Interface which is exposed by MI is binary incompatible, unless it was built in exactly the same way as the project that uses it.

Not sure about references, but I can give examples.
D3D uses single inheritance in its interface, and it's binary compatible.
CEGUI uses multiple inheritance in its interface, and it's binary incompatible (again, unless it was built in exactly the same way).

Also, QOL is quality of life. D3D could've been (theoretically) interfaced through MI, but then using it would become a chore.

[kornerr]

Do you mean that CEGUI classes that use single inheritance are ABI compatible between MSVC versions. And those that don't use it are not?

[Max]

Yes. And furthermore, in case of MI, first base class's vtable is recognized correctly, others are not however.

[Kulik]

What if I give you examples of all the combinations and show you that multiple inheritance really has nothing to do with it? Do you think DirectX is compatible BECAUSE it has no multiple inheritance? Are you aware of https://en.wikipedia.org/wiki/Component_Object_Model ?

What do you think happens when you pass std::string from one runtime version to another. Do you think debug std::string is ABI compatible with release std::string even in the same MSVC runtime version?

I have a lot of trouble believing your claims. Please do your due diligence and come back with references.

EDIT: MSVC broke C++ ABI between 2005 and 2008, 2008 and 2010. No idea about later versions. As a rule of thumb I assume breakage with MSVC version upgrades.
EDIT2: http://www.tylervigen.com/

[Max]

Isn't using STL in an interface is a questionable design decision in its own right? I assumed that you don't do it though.

I didn't say that MI is the sole reason for binary incompatibility, and yet it's a reason, which incidentally was the first one I noticed (because of incompatible vtables). If you use STL in the interface then it's yet another reason for broken binary compatibility.
While D3D is a set of COM objects, you don't see it in the code, as you never call CoCreateInstance. Closest that gets to it is CreateDeviceAndSwapChain, later on it's just a set of objects which are interfaced by simple C++ methods.
Also, ABI isn't completely broken between version, because if it would've been then things like D3D would stop working, which is clearly not the case. Some things get changed (usually STL), and some remain the same.

[Kulik]

OK, to answer your question:

We do not assume any binary compatibility between different MSVC runtimes. We do use STL, you'd be crazy not to use STL in modern C++ code (IMO). Even if you do not use STL in public interfaces your ABI can break (private std::vector member variable in a class can get bigger / smaller and thus affect the size of the class). We will not get rid of multiple inheritance just because MSVC breaks it between releases. If MSVC breaks something else (exception unroll for example) we will also continue using it.

Exception unrolling got broken between MSVC 2005 and 2008 at least. Probably broken between other versions as well.

I like to live in a world where I have control over whether things work or not. This is why I prefer to use the same runtime because I am guaranteed to succeed. I do not like guessing what Microsoft did or did not break this time. We do promise ABI and API stability for stable branches if you use the same tools for building the library as you use for building your application.

I hope I have made myself clear. I am pretty sure this stance is shared by all CEGUI team members but if not, I would like them to chime in

PS: I don't see any value in building CEGUI with MSVC 2005 and your app with MSVC 2013. I do see some value in building CEGUI with release runtime and your app with debug runtime but sadly we can't fix that on Windows. This does work on Linux and MacOSX.

[Max]

I see. Thanks for the detailed reply.
No need to call in other members as your word is enough for me.

My main goal was to mix debug/release builds, because I really don't like when I'm debugging some code (performance as well) and some dynamic library responds differently than it would in release mode, and less importantly keeping both, release and debug dlls/libs. The latter is because when I tweak code in the library I need to remember to update both builds, which I sometimes forget and it leads to debugging disasters. That MSVC cross version mixing is something that I'm just used to (main project is built with VS10, while many small things I compile in VS11), it's not crucial by any means.
I do use STL (quite a lot), but I never put it in an interface. I'm a firm believer in exposing only pure abstract classes. I mean, if it's private/protected and in an interface, then why it's even there? And if it's public then that's just asking for trouble. And as for function parameters, yes I use only pure C types (or data only structs) in interfaces. Yet, it's my own view, not forcing anyone to do the same

PS: You can count on exception unrolling being incompatible between releases.

[Kulik]

It is quite likely that your VS10 VS11 cross usage will bite you in unexpected ways in the future. However I do agree that STL in public interfaces is a bad practice and I think we should accept pull requests that get rid of it in the "default" branch. STL very likely will stay in private interfaces and we will not pimpl everything because of performance concerns. One exception I can think of is std::string which will have to stay in public interface if people chose to use it instead of CEGUI::String. Both are often passed by value so there is no way around breakage.

We are a C++ library which makes it very difficult for us to maintain ABI compatibility. Yet we try to do our best since 0.8. A good example on how to do C++ ABI compat is the Qt library. Take a look to see what kind of atrocities they have to do to maintain compatibility for their stable branches.

The main reason why DX is ABI compatible is the COM interface and you make it sound as if it's not really important. All Microsoft stable interfaces are either good ol' C (no mangling, no exceptions, no vtables), .NET or COM. There is a reason for that pattern

[Ident]

I completely agree with what Kulik said in one of his previous posts: We cannot rely on Microsoft NOT breaking things. That the developer using our library uses the same toolset for building CEGUI is something that I personally would expect. Everything else is unlikely and seems like a very special special-case, and in the sense of maintainability of this library we should not, can not, and will not relate to every special case, especially if it is one that can be prevented by not switching toolsets.

Furthermore, could you elaborate on the multiple inheritance criticism you brought up? Multiple inheritance is completely fine in C++ and it makes logically a lot of sense in many practical cases related to implementations of a object in a way they relate to actual objects and their relationships (is-a relationship) in real world. As opposed to that, some other major programming languages do not offer multiple inheritance due to diamond inheritance issues that can arise. Even for this case C++ is prepared. Again, how would this be an issue for ABI or API compatibility anyways? I do not see any connection. And all you said as a response to that question is that you used two different toolsets. Dont you think that this is your actual issue?

My main goal was to mix debug/release builds, because I really don't like when I'm debugging some code (performance as well) and some dynamic library responds differently than it would in release mode, and less importantly keeping both, release and debug dlls/libs.

In general it is not a good idea to mix debug libraries into a release project, imho, and don't they even use different microsoft runtimes?
You can use CEGUI's "Release with Debug symbols" to get a release build that has the symbols present. It will be fast and debuggable.

[Ident]

Excerpt from today, #cegui channel on IRC (pauldt = CrazyEddie):

Code: Select all

[11:30:49]   kornerr   have you noticed the multiple inheritance talk yesterday?
[11:31:04]   pauldt   no, because i wasn't here
[11:31:06]   pauldt   lol
[11:44:27]   kornerr   http://cegui.org.uk/forum/viewtopic.php?f=3&t=6762
[11:46:16]   pauldt   you guys pretty much covered it i think :)
[11:47:27]   pauldt   there has never been debug/release compatibility, and there never will be

[Max]

Sorry for not getting back earlier.

I don't have any general criticism towards MI, I think it's a great C++ feature. My only problem with it is that it doesn't ensure binary compatibility when used in an exposed interface. As noted before, I entirely missed the point that CEGUI has STL in its exposed interface (whether private, public members or function parameters), which is a far more glaring issue if you were aiming for binary compatibility. But since you don't (at least not now), there's no point in changing only MI to be non exposed if STL is there to stay.

Thank you very much for the time and attention for answering my question.

EDIT: Just wanted to clear something up. Single inheritance is not binary compatible by the spec as well (since C++ spec clearly leaves it up for the implementation to decide on this), but there's a gentleman's agreement between implementations that single inheritance is simple enough to always implement it identically. So de-facto it's binary compatible. This is not the case with MI, and especially not with virtual inheritance.