Re: High performance alternative to MI of virtual bases
From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 04/09/04
- Next message: Claudio Jolowicz: "unique objects and stl containers"
- Previous message: Andreas Schmidt: "Automatically separate method implementations from their declarations?"
- In reply to: christopher diggins: "Re: High performance alternative to MI of virtual bases"
- Next in thread: christopher diggins: "Re: High performance alternative to MI of virtual bases"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 08 Apr 2004 22:40:37 -0400
christopher diggins wrote:
>
> "Claudio Puviani" <puviani@hotmail.com> wrote in message
> news:59jdc.18680$Po2.6639652@news4.srv.hcvlny.cv.net...
[snip]
> It is perhaps narrow to suggest that any usage of inheritance beyond
> modeling IS-A relationships is incorrect. I will grant you that being
> rigorous in this manner has advantages of consistency which can be
> preferable in many scenarios. I believe there are valid scenarios when
> inheritance is not just about modeling, sometimes it is just a practical
> technique used to save coding and factor out common functionality.
Stroustrup certainly doesn't limit classes to strictly 'is-a'
representations. In general it is reasonable to abstract out abilities such
as runable, serializable, resizeable, etc. These abstractions are good
candidates for interfaces, in either the pure ABC or HFront sense. Some
things that are treated as interfaces in Java are implemented using
templates in the STL. Of course much of STL can be diagrammed as an
inheritance hierarchy, at least conceptually.
Another significant role of an interface is to act as a contract.
> When
> you refer to interfaces here, are you refering to Abstract Base Classes
> performing as interfaces?
I would really like to know what he intended. It's hard to know how we are
to understand his usage.
>> C++ language AS IT'S DEFINED IN THE STANDARD, not any theoretical
>> extensions.
>
> Any suggestion where a more appropriate place to discuss extensions to the
> standard?
That is really something of a missunderstanding of the FAQ. People tend to
only read a few choice sections that are immediately appearant and neglect
to consider what the broader picture it represents is.
> At the same time, the output of HeronFront could be argued to be
> on-topic, because it is C++ as defined in the standard. I think really if
> people like myself were silenced here, then you would be left with nothing
> but a lot of "how do I do my homework posts".
Actually, I have the sense these restrictions people try to place on the
content of the newsgroup are rather harmful to C++.
>> This presumes two things: (1) that I -- or anyone else -- would be
>> willing to add yet another preprocessor to the build chain, which in my
>> case is absolutely false, and (2) that heavy use of multiple inheritance
>> is desirable, which almost every author and practitioner agrees is not
>> the case.
>
> I don't honestly expect many people to use (1), as I mentioned before it's
> more of a proof of concept. Though interestingly enough, I could build a
> very interesting library in standard C++ using HeronFront. So what are the
> reasons behind (2)? Is it because heavy use of MI is inefficient? When
> modeling behaves-like cases using ABC's, it makes sense that we use MI as
> much as we need to, any limit on us using it would be purely
> implementation imposed.
"People quite correctly say that you don't need multiple inheritance,
because anything you can do with multiple inheritance you can also do with
single inheritance. You just use the delegation trick I mentioned.
Furthermore, you don't need any inheritance at all, because anything you do
with single inheritance you can also do without inheritance by forwarding
through a class. Actually, you don't need any classes either, because you
can do it all with pointers and data structures." - Bjarne Stroustrup
-- p->m == (*p).m == p[0].m http://www.kdevelop.org http://www.suse.com http://www.mozilla.org
- Next message: Claudio Jolowicz: "unique objects and stl containers"
- Previous message: Andreas Schmidt: "Automatically separate method implementations from their declarations?"
- In reply to: christopher diggins: "Re: High performance alternative to MI of virtual bases"
- Next in thread: christopher diggins: "Re: High performance alternative to MI of virtual bases"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
