[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
On C++ multiple inheritance
- To: linuxgames@xxxxxxxxxx
- Subject: On C++ multiple inheritance
- From: "Miguel A. Osorio" <mao@xxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 14 Apr 2005 16:12:02 -0300
- Delivered-to: email@example.com
- Delivered-to: mailing list firstname.lastname@example.org
- Delivery-date: Thu, 14 Apr 2005 15:11:10 -0400
- Mailing-list: contact email@example.com; run by ezmlm
- Reply-to: linuxgames@xxxxxxxxxx
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
I'm currently in the process of doing some changes to my renderer and
I'll probably adding some new classes into the existing hierarchy. At
this time, I do make some *light* use of multiple inheritance and
haven't had any problems with it yet, nor do I detect any problems
arising from changes or additions I'll be making to the hierarchy.
*But*, I have noticed that quite a large number of programmers declare
multiple inheritance as something to be "avoided like the plague", and
although I can relate to that if I imagine a badly designed hierarchy
using that mechanism, I'm not really sure of the reasons behind negative
arguments like that.
I'd like to know your opinions on this, since at this point I can still
re-design my current hierarchy to make use of single inheritance only,
though I still fear that possibly weak decisions on the revised
architechture might jump up in the future and bite me :P.
I'd like to make it clear that the current implementation makes only
slight use of multiple inheritance, and the future one, with
modifications and additions, and which is already planned, still uses
the mechanism only slightly. So, would that be acceptable, or should I
just go ahead and use single inheritance exclusively?
Thing is, the switch to exclusive-single-inheritance-mode can be made,
as I said, but it'll break some of the semantics for some existing
classes, which kind of annoys me. I'm afaid that in doing that I might
have to settle for "strange" things such as for example: a class that
defines the concept of a positionable and orientable object deriving
from a class that defines a rendering primitive which has a material ID.
That relation is not necessarily true in some cases, which kind of puts
the whole architechture in perspective, huh?
Thanks for your time,