[Request] Please remove multiple inheritance from interfaces

[Ident]

Can you give any sources for why MI would have anything to do with multiple inheritance?

Also who the hell does not use the STL?

[Max]

Not sure about the question, MI stands for multiple inheritance.
If you meant about binary incompatibility then I can just quote the spec:

1.7
A memory location is either an object of scalar type or a maximal sequence of adjacent bit-fields all having
non-zero width. [Note: Various features of the language, such as references and virtual functions, might
involve additional memory locations that are not accessible to programs but are managed by the imple-mentation.—end note]

As for STL, everyone uses it (or almost everyone?), but not everyone puts it in an interface. There are alternatives for passing parameters which preserve binary compatibly.

[Ident]

Sorry I meant to say:

Can you give any sources or actual reasons why MI would break binary compatibility?

You gave a quote now, where is that taken from? I asked for a source not a quote.

As for STL, everyone uses it (or almost everyone?), but not everyone puts it in an interface. There are alternatives for passing parameters which preserve binary compatibly.

What would the alternative be? Pimpl idiom? I strongly oppose using pimpl for such purposes, or using any other inconvenient implementation with a similar effect.
Everyone would have to use it, just because some few people are using different compilers for their libraries. The real problem is that you...
• ...are trying to combine debug and release libraries
• ...are trying to combine different compilers/VC toolsets

Fixing this on our ends is the wrong approach. The right approach is just to not mix compilers and toolsets. Clearly, you are not supposed to mix them. The costs on our side would be too high to cater to such specific requests. We have to base CEGUI's features on certain presumption so that we do not overcomplicate things. One assumption is that users do not mix debug and release or different compiler versions.

If you have a really simple fix for the STD stuff in interfaces then we might think about it. Pimpl however just seems blocky and in the end it might even decrease performance. Feel free to make a good suggestion!

[Max]

The quote is from C++ spec (latest draft, n3242.pdf).

As I said before, mixing compiler versions wasn't the purpose of this post (yes, it's not the best of habits!), mixing debug/release was (which is really helpful).
I don't think it's really that specific request, at least not anymore specific than supporting a DLL build. I think _most_ people would like to have a static library in their final product, but still the dynamic library is invaluable during development.

Unfortunately I don't have a trivial "fix" for this.
Pimpl is a rather drastic approach which was aimed to solve a quite more general case of binary compatibility, and it'll definitely hurt performance.
Implementing the basics is another possibility, generally it ends up with implementing some basic, binary compatible, functionality of string. So it's not really a big deal. Though the harder part will be restructuring the whole interface to not contain STL stuff in it, I'm not 100% sure about your case, but I think that adding another layer of inheritance will solve this. One thing which definitely softens this, is that you already use virtual functions. Again, things could be more complicated and I might've missed something.

[Kulik]

I still have the impression that you don't really understand how this works. What you quoted is very generic and applies to a wide variety of C++ features. We use many of those. Again, there was nothing specific to multiple inheritance. I believe there really is nothing special about it in vtable layouts between debug and release and you are likely just confusing something else. Just the fact that the vtable is there (at least one member is virtual) is enough to potentially break the ABI between different compiler versions. Furthermore, the C++ spec is definitely not the best resource when it comes to ABI compatibility, it doesn't even specify the mangling scheme.

I will reiterate, we will NOT even consider it because we do realise how futile an attempt to do that would be. We HAVE experience maintaining libraries.

PS: Not even Qt4 is compatible between debug and release library.
PS2: I do think that most people are better off using dynamic builds even for released products. Wanting static builds because of """DLL hell""" is a typical sign of a C++ newcomer.