# Unity *Want* Multiple Base Objects

This topic is 1847 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi,

I had come across an . . . unusual programming situation.

I have a FBO2D base class, which implements a 2D framebuffer object, and I wanted to implement a FBOCube class derived from it, implementing a cubemap framebuffer object. The point is that FBOCube is essentially six FBO2D classes, but it still kinda makes sense to derive from it. In effect, I want six FBO2D parents for a single object. The language is C++.

I realize this is awful, and I'm redesigning it, but I thought it was an interesting thing. I'm pretty sure it's not possible in C++. I'm curious: what does the programming community think?

-G

##### Share on other sites
It's possible, but a really bad idea. One way:
template <int i> struct BaseHelper : FBO2D {
};

struct FBOCube : BaseHelper<0>, BaseHelper<1>, BaseHelper<2>, BaseHelper<3>, BaseHelper<4>, BaseHelper<5> {
};


##### Share on other sites
That doesn't really make sense to me.

Inheretence means "is a". It means the object is completely interchangeable. It's like asking for a generic and getting a name brand.

For example, the code may say to the engine, "Give me a game object with this ID", and it returns a game object. The object may be more than a generic game object, but it IS A game object.

Or my code may say to the engine, "Give me an animation script matching this key", and it gives me a script. It may be more a specific class of script, but it IS A script.

Or in real life, I may ask for an ice cream treat, and the result may be a cone, a sundae, or a sandwich, or something else entirely. Any one of them IS A ice cream treat.

To suggest that the code may ask for an 2D frame buffer object and get six of them back, that doesn't really make much sense.

##### Share on other sites

Well, in C++ you actually *can* derive from multiple base objects, but I'm all but certain that they have to be different types (casting aside potential template specialization tricks as a [probably] laughably bad idea). Even though C++ allows multiple-inheritance, its still generally considered to be a poor idea, both in theory and in practice, even when the types you're deriving from actually are different.

The exception to it being a bad idea is when all but one on the types you are deriving from are purely-virtual -- that is, they are interfaces which delegate to the deriving class to define what the interface function means to that class. The trouble with using multiple-inheritance in any other way is that there can be competing definitions of functions, and unexpected interactions between them (which is to say nothing of the dreaded diamond). When all but one of the derived-from classes is virtual, there's no such problem. Languages which disallow free-form multiple-inheritance (like Java and C#) even codify and encourage this "correct" way of multiple-inheritance and distinguish between classes and interfaces formally -- their forms of inheritance allows only one class, but as many interfaces as you like.

For your problem, though, it sounds more likely that you want composition, rather than inheritance. Inheritance is used to express an "is-a" relationship between classes -- a car is-a vehicles and a bicycle is-a vehicle in every sense, the question you need to ask yourself is whether an FBOCube class really is-a FBO2D in every sense too; that is, wherever in your code that you take an FBO2D object, can you do something sensible with an FBOCube? If not, you want composition -- an FBOCube implemented as having 6 separate FBO2D members (or an array of 6 FBO2D instances) -- or perhaps to not leverage the FBO2D code at all. Composition does not express an is-a relationship, but a 'has-a' relationship -- an FBOCube has 6 FBO2D instances. You use inheritence only when you can substitute a deriver for the derivee, you should use composition when you just want to leverage the code you've already written for another object.

##### Share on other sites

It's possible, but a really bad idea. One way:

template <int i> struct BaseHelper : FBO2D {
};

struct FBOCube : BaseHelper<0>, BaseHelper<1>, BaseHelper<2>, BaseHelper<3>, BaseHelper<4>, BaseHelper<5> {
};


SiCrane, here I go being all thorough and don't get to be the clever guy who first anti-mentions some kind of terrible template specialization hack!

##### Share on other sites

To clarify, it has already been redesigned to something completely different. I can design it myself thank you much. I'm just thinking this is an interesting problem, and it's the first solution I thought of.

SiCrane's template hack looks neat. If it were virtual inheritance of FBO2D, then one could override the relevant methods of FBO2D if you just needed it to act like multiple objects without actually duplicating the data.

##### Share on other sites

It's possible, but a really bad idea. One way:

template  struct BaseHelper : FBO2D {  // add appropriate forwarding functions};struct FBOCube : BaseHelper, BaseHelper, BaseHelper, BaseHelper, BaseHelper, BaseHelper {};

I, for one, welcome our new dreaded dodecahedron bipyramidal overlords.

##### Share on other sites

I, for one, welcome our new dreaded dodecahedron bipyramidal overlords.

Hehe, sounds so bad, it might just be awesome again. Unlike usually, the author actually wants duplicated base classes. Edited by kloffy

1. 1
2. 2
3. 3
4. 4
Rutin
18
5. 5

• 11
• 22
• 12
• 12
• 11
• ### Forum Statistics

• Total Topics
631406
• Total Posts
2999905
×