Jump to content
  • Advertisement
Sign in to follow this  
Geometrian

Unity *Want* Multiple Base Objects

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
It's possible, but a really bad idea. One way:
template <int i> struct BaseHelper : FBO2D {
  // add appropriate forwarding functions
};

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

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites

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

template <int i> struct BaseHelper : FBO2D {
  // add appropriate forwarding functions
};

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 this post


Link to post
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 this post


Link to post
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 {};
Forget the dreaded diamond.

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

Share this post


Link to post
Share on other sites

Forget the dreaded diamond.

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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!