Where to exacly should I pass an array/container of ITexture pointers if you're telling me I should use ITexture::MakeActive() ?
And doesn't that mean again that this container could have ITexture pointers created from another context?
It doesn't really matter; you just have a function in a reasonable place where the container is enumerated, and each ITexture's MakeActive is called in sequence. If you want to batch this to API calls behind the scenes, that's something the concrete implementation of ITexture can handle; it shouldn't leak into your abstracted API.
I'm not really questioning the validity of LSP. I just don't see a way to fully comply with it in this particular problem.
I must add constraints to what is accepted. We don't live in a perfect world, there are exceptions I want to deal with appropriately. Say I give it a texture that is resident in another GPUs memory; I want to return an error from that (instead of invalid rendering or crash), even if in theory it should work, I could document that behaviour.
There's nothing preventing you from doing these checks; I really don't understand what you consider problematic here. That logic just needs to live in the implementation
and not leak into the interface.
As a complete straw-man example, you could have the concrete implementation of a texture check if it belongs to the correct context, and throw an exception if it does not. Or use error code returns, like D3D does; it really makes very little difference.
The *::MakeActive approach would solve this though, but I would like to be able to MakeActive several textures in one call.
As above: you write a wrapper that accepts a container of ITexture* and calls MakeActive on each. If you want to batch texture calls to your back-end graphics API
then that should be hidden from the consumer and done automatically by the concrete implementation of your API interfaces. There's no reason why your API should force the user to think about batching if the implementation can do it transparently.
Again, you misunderstood me. I mean the correctness of the internal state of the objects. I'm not talking about language correctness. In this specific case, by correctness I mean "the texture must belong to the same context you're trying to bind it to for rendering".
Again, I don't see how this is difficult. You just write the check in the appropriate place in the concrete implementation. There's no need for multiple inheritance or any other such cruft.
Well the OpenGL or not problem is not relevant at all to the question I'm asking. They still have interface inheritance to which they must provide implementations somewhere. When I said "how does D3D do it", I meant do they duplicate code for each object that needs to provide an implementation to ID3D11Resource or solve this problem any other way? They still must cast it to an implementation pointer somewhere...
I don't know why you're so fixated on the idea of casting to an implementation pointer. If your interface class is designed correctly, it's almost never necessary, and indeed if it is
necessary to program to a specific implementation type, you've borked your design, period.
Exacly. So do you agree (excluding personal preference) with me that oglGraphicsContext could accept an ITexture and down-cast it there?
Absolutely not. You should not be up
Maybe I should try to put my main question in another way: How can I implement an interface hierarchy and reuse implementation code (without ugly "hacks" like macros) while avoiding multiple inheritance?
Why do you need a hierarchy?