High performance alternative to MI of virtual bases

[christopher diggins]

Re: High performance alternative to MI of virtual bases


"Claudio Puviani" <puviani@hotmai l.com> wrote in message
news:59jdc.1868 0$Po2.6639652@n ews4.srv.hcvlny .cv.net...[color=blue]
> "christophe r diggins" <cdiggins@video tron.ca> wrote[/color]

<snip>[color=blue][color=green]
> > It seems you might be on a personal vendetta, but I
> > am open to the idea that my idea might be flawed. But
> > please tell me how my idea is flawed first before you
> > accuse me of being hard-headed.[/color]
>
> I can see how you would have read that as refering to you, and I apologize
> for not expressing this more clearly. The "hard-headed" attribute refers[/color]
to[color=blue]
> some people involved in a few prior unrelated "debates", not to you.[/color]
You've[color=blue]
> so far shown yourself to be open to dissenting views, even if you don't
> ascribe to them.[/color]

I am pleased to hear that, and I apologize for having taken offence to
something not aimed at me.

<snip>[color=blue][color=green]
> > Finally something I can discuss with you. What I am presenting
> > is not a solution to mitigate the costs of abusing MI, it is a new
> > way to look at sofwtware designs which promotes multiple
> > implementations of interfaces.[/color]
>
> I have nothing against interfaces in principle, but
>[color=green]
> > Heavy use of MI is only "abuse" because the approach of
> > using ABC's to emulate interfaces is flawed.[/color]
>
> Heavy use of MI is abuse for the same reasons that simple inheritance is
> abused: incorrect modeling. Inheritance -- multiple or otherwise -- is[/color]
meant[color=blue]
> to model an IS-A relationship, not a LOOKS-LIKE or a BEHAVES-LIKE
> relationship, which is what interfaces model.[/color]

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. When you
refer to interfaces here, are you refering to Abstract Base Classes
performing as interfaces?
[color=blue]
> The great irony is that when a
> system is modeled correctly, there is very little need for inheritance and
> almost no need whatsoever for MI.[/color]

This is a very far reaching statement. There is an implication as to what
constitutes correct modeling that could potentially be very contentious. We
may have differing views on writing software. I belive that there are
multiple legitimate ways to write software and that as long as in the end it
accomplishes certain core objectives (i.e. fully satisfies requirements both
implicit and explicit, is correct, fails gracefully, is easily modifiable by
others) then it can be considered to be correct. I may be reading too much
into your statement, but part of the implication is that software which uses
MI is not modeled correctly which I disagree with.
[color=blue]
> Interfaces _are_ an interesting paradigm, but they're not a C++ paradigm,[/color]

Using ABC's like interfaces to model BEHAVES-LIKE cases is a C++ paradigm.
[color=blue]
> which is why this thread is off-topic in a newsgroup that's dedicated to[/color]
the[color=blue]
> use of the core standard C++ language... WITHOUT preprocessors to handle
> language extensions. This applies to CORBA, ODMG, Heron, and any other
> preprocessor, regardless of how useful it may or may not be. For the sake[/color]
of[color=blue]
> argument, let's say C++ would be better with interfaces. This would be the
> wrong newsgroup to discuss that because this newsgroup's chosen topic is[/color]
the[color=blue]
> C++ language AS IT'S DEFINED IN THE STANDARD, not any theoretical
> extensions.[/color]

Any suggestion where a more appropriate place to discuss extensions to the
standard? 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".
[color=blue]
> Clearly, Heron, as a language is completely off-topic.[/color]

Yes Heron definitely is OT, but to be fair I never brought up Heron.

<snip>[color=blue][color=green]
> > I encourage you to give it a chance by imagining what kinds of
> > designs you might be able to write if heavy use of multiple
> > interfaces was not in fact abusive.[/color]
>
> 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.[/color]

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.

<snip>[color=blue]
> Unfortunately for you, you don't own this thread. It's both ironic and
> amusing that you would try to exclude someone from an off-topic thread.[/color]

Okay then, I'm glad I amused you at least.

--
Christopher Diggins

http://www.cdiggins.com

http://www.heron-language.com

[christopher diggins]

Re: High performance alternative to MI of virtual bases


"Claudio Puviani" <puviani@hotmai l.com> wrote in message
news:59jdc.1868 0$Po2.6639652@n ews4.srv.hcvlny .cv.net...[color=blue]
> "christophe r diggins" <cdiggins@video tron.ca> wrote[/color]

<snip>[color=blue][color=green]
> > It seems you might be on a personal vendetta, but I
> > am open to the idea that my idea might be flawed. But
> > please tell me how my idea is flawed first before you
> > accuse me of being hard-headed.[/color]
>
> I can see how you would have read that as refering to you, and I apologize
> for not expressing this more clearly. The "hard-headed" attribute refers[/color]
to[color=blue]
> some people involved in a few prior unrelated "debates", not to you.[/color]
You've[color=blue]
> so far shown yourself to be open to dissenting views, even if you don't
> ascribe to them.[/color]

I am pleased to hear that, and I apologize for having taken offence to
something not aimed at me.

<snip>[color=blue][color=green]
> > Finally something I can discuss with you. What I am presenting
> > is not a solution to mitigate the costs of abusing MI, it is a new
> > way to look at sofwtware designs which promotes multiple
> > implementations of interfaces.[/color]
>
> I have nothing against interfaces in principle, but
>[color=green]
> > Heavy use of MI is only "abuse" because the approach of
> > using ABC's to emulate interfaces is flawed.[/color]
>
> Heavy use of MI is abuse for the same reasons that simple inheritance is
> abused: incorrect modeling. Inheritance -- multiple or otherwise -- is[/color]
meant[color=blue]
> to model an IS-A relationship, not a LOOKS-LIKE or a BEHAVES-LIKE
> relationship, which is what interfaces model.[/color]

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. When you
refer to interfaces here, are you refering to Abstract Base Classes
performing as interfaces?
[color=blue]
> The great irony is that when a
> system is modeled correctly, there is very little need for inheritance and
> almost no need whatsoever for MI.[/color]

This is a very far reaching statement. There is an implication as to what
constitutes correct modeling that could potentially be very contentious. We
may have differing views on writing software. I belive that there are
multiple legitimate ways to write software and that as long as in the end it
accomplishes certain core objectives (i.e. fully satisfies requirements both
implicit and explicit, is correct, fails gracefully, is easily modifiable by
others) then it can be considered to be correct. I may be reading too much
into your statement, but part of the implication is that software which uses
MI is not modeled correctly which I disagree with.
[color=blue]
> Interfaces _are_ an interesting paradigm, but they're not a C++ paradigm,[/color]

Using ABC's like interfaces to model BEHAVES-LIKE cases is a C++ paradigm.
[color=blue]
> which is why this thread is off-topic in a newsgroup that's dedicated to[/color]
the[color=blue]
> use of the core standard C++ language... WITHOUT preprocessors to handle
> language extensions. This applies to CORBA, ODMG, Heron, and any other
> preprocessor, regardless of how useful it may or may not be. For the sake[/color]
of[color=blue]
> argument, let's say C++ would be better with interfaces. This would be the
> wrong newsgroup to discuss that because this newsgroup's chosen topic is[/color]
the[color=blue]
> C++ language AS IT'S DEFINED IN THE STANDARD, not any theoretical
> extensions.[/color]

Any suggestion where a more appropriate place to discuss extensions to the
standard? 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".
[color=blue]
> Clearly, Heron, as a language is completely off-topic.[/color]

Yes Heron definitely is OT, but to be fair I never brought up Heron.

<snip>[color=blue][color=green]
> > I encourage you to give it a chance by imagining what kinds of
> > designs you might be able to write if heavy use of multiple
> > interfaces was not in fact abusive.[/color]
>
> 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.[/color]

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.

<snip>[color=blue]
> Unfortunately for you, you don't own this thread. It's both ironic and
> amusing that you would try to exclude someone from an off-topic thread.[/color]

Okay then, I'm glad I amused you at least.

--
Christopher Diggins

http://www.cdiggins.com

http://www.heron-language.com

[christopher diggins]

Re: High performance alternative to MI of virtual bases

"Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote in message
news:E5CdnT5EW5 DNX-jd4p2dnA@speake asy.net...[color=blue]
> christopher diggins wrote:
>[color=green][color=darkred]
> >> Can you point me to the 'executive summary' describing the alternative?[/color]
> >
> > Could you explain what you mean by that?[/color]
>
> This:
>[color=green]
> > http://www.heron-language.com/abc-iop.html[/color]
>
> Thanks.
>
> Can I assume the only difference between an ABC with all pure virtual[/color]
member[color=blue]
> functions and your interface is the "fat pointer" replacing the vtbl?[/color]

Well that, and the fact that the functions are not virtual. They can not be
overriden in an inheriting class. For instance using interfaces:

Interface I {
void Fu();
};

class Base {
implements I;
void Fu( cout << "base"; };
};

class Super : public Base {
void Fu( cout << "super"; };
};

main() {
Super s;
Base* b = &s;
b->Fu(); // outputs "base"
I x = s;
x.Fu(); // outputs "base"
}

Now here is the same code with a pure ABC:

class I {
virtual void Fu() = 0;
};

class Base : public I {
void Fu( cout << "base"; };
};

class Super : public Base {
void Fu( cout << "super"; };
};

main() {
Super s;
Base* b = &s;
b->Fu(); // outputs "super"
I* x = s;
x->Fu(); // outputs "super"
}

--
Christopher Diggins

http://www.cdiggins.com

http://www.heron-language.com

[christopher diggins]

Re: High performance alternative to MI of virtual bases

"Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote in message
news:E5CdnT5EW5 DNX-jd4p2dnA@speake asy.net...[color=blue]
> christopher diggins wrote:
>[color=green][color=darkred]
> >> Can you point me to the 'executive summary' describing the alternative?[/color]
> >
> > Could you explain what you mean by that?[/color]
>
> This:
>[color=green]
> > http://www.heron-language.com/abc-iop.html[/color]
>
> Thanks.
>
> Can I assume the only difference between an ABC with all pure virtual[/color]
member[color=blue]
> functions and your interface is the "fat pointer" replacing the vtbl?[/color]

Well that, and the fact that the functions are not virtual. They can not be
overriden in an inheriting class. For instance using interfaces:

Interface I {
void Fu();
};

class Base {
implements I;
void Fu( cout << "base"; };
};

class Super : public Base {
void Fu( cout << "super"; };
};

main() {
Super s;
Base* b = &s;
b->Fu(); // outputs "base"
I x = s;
x.Fu(); // outputs "base"
}

Now here is the same code with a pure ABC:

class I {
virtual void Fu() = 0;
};

class Base : public I {
void Fu( cout << "base"; };
};

class Super : public Base {
void Fu( cout << "super"; };
};

main() {
Super s;
Base* b = &s;
b->Fu(); // outputs "super"
I* x = s;
x->Fu(); // outputs "super"
}

--
Christopher Diggins

http://www.cdiggins.com

http://www.heron-language.com

[Claudio Puviani]

Re: High performance alternative to MI of virtual bases

"Julie" <julie@nospam.c om> wrote[color=blue]
> I don't know how I got dragged into this thread...[/color]

I missed you. ;-)
[color=blue]
> Since Godwin's law doesn't yet apply, I guess I'll clarify:
>
> No need to formally restructure the language, it can be kept
> intact. The notion of a translation unit would need to be
> redefined (again, not formally, just within the context of the
> storage subsystem).[/color]

The notion of a translation unit is intrinsic to the language; it's not a
meaningless side-effect. You can't change the concept without radically
changing the way the language is used and invalidating unacceptable amounts
of code. For example -- and not that I would encourage the practice -- one
could have an include file that contained the definition of an exception
class that is then included locally INSIDE other classes, as follows:

class SomeClass {
#include "InnerException .hpp"
// ...
void someFunction() throw (Exception);
};

class SomeOtherClass {
#include "InnerException .hpp"
// ...
void someOtherFuncti on() throw (Exception);
};

// and later...

void xxx()
{
try {
SomeClass sc;
SomeOtherClass soc;

sc.someFunction ();
soc.someOtherFu nction();
}
catch (SomeClass::Exc eption & ex) {
// ...
}
catch (SomeOtherClass ::Exception & ex) {
// ...
}
}

As you can see, the same file ends up meaning and creating different things
because it's included in different contexts. Whether or not one likes it,
this is a feature of the language that would likely disappear if the concept
of translation units were to be changed to fit a "language unit" model.

From a different agnle, like it or not, most programmers have a hefty
toolkit of perl, awk, sed, shell, yacc/lex, etc. scripts that they use to
process their source code because they take ADVANTAGE of the fact that the
source is stored in text files, as opposed to seeing it as a hindrance. This
is part of an existing C++ culture that isn't going away. It may increase
the learning curve for people new to the language, but no one will accept
features that help beginners to the detriment of those who are proficient in
the language and its vast existing base of tools. Saying that "people will
write new tools" just isn't acceptable. Even if the idea had merit, which is
a separate debate, there would me ZERO market for a change that would force
the established base of C++ developers to throw away tools, techniques, and
experience without there being replacements up front.
[color=blue][color=green][color=darkred]
> > > What I found astounding was the extreme reaction you had to
> > > the proposition.[/color]
> >
> > My reaction was proportional to the absurdity of the idea -- however
> > well-intentioned it may have been -- and the tenacity with which she[/color][/color]
clung[color=blue][color=green]
> > to it.
> >[color=darkred]
> > > It's actually not a new idea,[/color]
> >
> > It's an old idea that never took hold because it's a bad idea.[/color]
>
> I know it isn't a new idea -- like I said, I know that IBM was working
> on some form of this a long time ago (i.e. the early 90's).[/color]

I strongly doubt this was for C++.
[color=blue]
> Why it didn't take, I don't know.[/color]

Maybe it was for C++ after all. That would definitely explain its failure.
[color=blue]
> A lot of (good) ideas don't take for various reasons -- that
> doesn't imply that it is a bad idea, though.[/color]

Ideas live in a context. Your idea, in a brand new language, might be
excellent. It could even be perfectly adaptable to some languages like
Pascal or Ada, and maybe even Java. In the context of C++ with its
established practices, tools, and idioms that depend on translation units
being text files, it makes no sense at all.
[color=blue]
> I'd *LOVE* to hear an objective examination of the idea,
> and its outcome (positive or negative), however I've yet to
> run across anything other than what has been 'discussed'
> about it in the ng recently.[/color]

What's been discussed, and what I've repeated here, is objective AND
pragmatic. You can't choose to disregard real-world usage and consequences
to the developer base.
[color=blue]
> I'm not clinging to the idea, I just haven't heard anything
> substantive that explains its inherent shortcomings (excepting
> technological limitations).[/color]

It may not seem substantive to you because you haven't experienced the
environments that others and I have described. There are actually NO
technological limitations to storing source code in databases if the
language supports the model. C++ doesn't support the model. It's that
simple.
[color=blue]
> I'm not going to drop the idea, however, just over some flap
> on a newsgroup.[/color]

Feel free to hang on to it, if you're emotionally attached to it, but that
won't make it any more relevant to C++ in a year, in 10 years or in 20
years. I'm sure that as your experience with C++ grows and you work in more
diverse environments, you'll come to understand it.

Claudio Puviani

[Claudio Puviani]

Re: High performance alternative to MI of virtual bases

"Julie" <julie@nospam.c om> wrote[color=blue]
> I don't know how I got dragged into this thread...[/color]

I missed you. ;-)
[color=blue]
> Since Godwin's law doesn't yet apply, I guess I'll clarify:
>
> No need to formally restructure the language, it can be kept
> intact. The notion of a translation unit would need to be
> redefined (again, not formally, just within the context of the
> storage subsystem).[/color]

The notion of a translation unit is intrinsic to the language; it's not a
meaningless side-effect. You can't change the concept without radically
changing the way the language is used and invalidating unacceptable amounts
of code. For example -- and not that I would encourage the practice -- one
could have an include file that contained the definition of an exception
class that is then included locally INSIDE other classes, as follows:

class SomeClass {
#include "InnerException .hpp"
// ...
void someFunction() throw (Exception);
};

class SomeOtherClass {
#include "InnerException .hpp"
// ...
void someOtherFuncti on() throw (Exception);
};

// and later...

void xxx()
{
try {
SomeClass sc;
SomeOtherClass soc;

sc.someFunction ();
soc.someOtherFu nction();
}
catch (SomeClass::Exc eption & ex) {
// ...
}
catch (SomeOtherClass ::Exception & ex) {
// ...
}
}

As you can see, the same file ends up meaning and creating different things
because it's included in different contexts. Whether or not one likes it,
this is a feature of the language that would likely disappear if the concept
of translation units were to be changed to fit a "language unit" model.

From a different agnle, like it or not, most programmers have a hefty
toolkit of perl, awk, sed, shell, yacc/lex, etc. scripts that they use to
process their source code because they take ADVANTAGE of the fact that the
source is stored in text files, as opposed to seeing it as a hindrance. This
is part of an existing C++ culture that isn't going away. It may increase
the learning curve for people new to the language, but no one will accept
features that help beginners to the detriment of those who are proficient in
the language and its vast existing base of tools. Saying that "people will
write new tools" just isn't acceptable. Even if the idea had merit, which is
a separate debate, there would me ZERO market for a change that would force
the established base of C++ developers to throw away tools, techniques, and
experience without there being replacements up front.
[color=blue][color=green][color=darkred]
> > > What I found astounding was the extreme reaction you had to
> > > the proposition.[/color]
> >
> > My reaction was proportional to the absurdity of the idea -- however
> > well-intentioned it may have been -- and the tenacity with which she[/color][/color]
clung[color=blue][color=green]
> > to it.
> >[color=darkred]
> > > It's actually not a new idea,[/color]
> >
> > It's an old idea that never took hold because it's a bad idea.[/color]
>
> I know it isn't a new idea -- like I said, I know that IBM was working
> on some form of this a long time ago (i.e. the early 90's).[/color]

I strongly doubt this was for C++.
[color=blue]
> Why it didn't take, I don't know.[/color]

Maybe it was for C++ after all. That would definitely explain its failure.
[color=blue]
> A lot of (good) ideas don't take for various reasons -- that
> doesn't imply that it is a bad idea, though.[/color]

Ideas live in a context. Your idea, in a brand new language, might be
excellent. It could even be perfectly adaptable to some languages like
Pascal or Ada, and maybe even Java. In the context of C++ with its
established practices, tools, and idioms that depend on translation units
being text files, it makes no sense at all.
[color=blue]
> I'd *LOVE* to hear an objective examination of the idea,
> and its outcome (positive or negative), however I've yet to
> run across anything other than what has been 'discussed'
> about it in the ng recently.[/color]

What's been discussed, and what I've repeated here, is objective AND
pragmatic. You can't choose to disregard real-world usage and consequences
to the developer base.
[color=blue]
> I'm not clinging to the idea, I just haven't heard anything
> substantive that explains its inherent shortcomings (excepting
> technological limitations).[/color]

It may not seem substantive to you because you haven't experienced the
environments that others and I have described. There are actually NO
technological limitations to storing source code in databases if the
language supports the model. C++ doesn't support the model. It's that
simple.
[color=blue]
> I'm not going to drop the idea, however, just over some flap
> on a newsgroup.[/color]

Feel free to hang on to it, if you're emotionally attached to it, but that
won't make it any more relevant to C++ in a year, in 10 years or in 20
years. I'm sure that as your experience with C++ grows and you work in more
diverse environments, you'll come to understand it.

Claudio Puviani

[Steven T. Hatton]

Re: High performance alternative to MI of virtual bases

christopher diggins wrote:
[color=blue]
>
> "Claudio Puviani" <puviani@hotmai l.com> wrote in message
> news:59jdc.1868 0$Po2.6639652@n ews4.srv.hcvlny .cv.net...[/color]
[snip]
[color=blue]
> 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.[/color]

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.
[color=blue]
> When
> you refer to interfaces here, are you refering to Abstract Base Classes
> performing as interfaces?[/color]

I would really like to know what he intended. It's hard to know how we are
to understand his usage.
[color=blue][color=green]
>> C++ language AS IT'S DEFINED IN THE STANDARD, not any theoretical
>> extensions.[/color]
>
> Any suggestion where a more appropriate place to discuss extensions to the
> standard?[/color]

That is really something of a missunderstandi ng 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.

[color=blue]
> 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".[/color]

Actually, I have the sense these restrictions people try to place on the
content of the newsgroup are rather harmful to C++.
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

"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

[Steven T. Hatton]

Re: High performance alternative to MI of virtual bases

christopher diggins wrote:
[color=blue]
>
> "Claudio Puviani" <puviani@hotmai l.com> wrote in message
> news:59jdc.1868 0$Po2.6639652@n ews4.srv.hcvlny .cv.net...[/color]
[snip]
[color=blue]
> 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.[/color]

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.
[color=blue]
> When
> you refer to interfaces here, are you refering to Abstract Base Classes
> performing as interfaces?[/color]

I would really like to know what he intended. It's hard to know how we are
to understand his usage.
[color=blue][color=green]
>> C++ language AS IT'S DEFINED IN THE STANDARD, not any theoretical
>> extensions.[/color]
>
> Any suggestion where a more appropriate place to discuss extensions to the
> standard?[/color]

That is really something of a missunderstandi ng 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.

[color=blue]
> 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".[/color]

Actually, I have the sense these restrictions people try to place on the
content of the newsgroup are rather harmful to C++.
[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

"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

[Steven T. Hatton]

Re: High performance alternative to MI of virtual bases

Claudio Puviani wrote:
[color=blue]
> Feel free to hang on to it, if you're emotionally attached to it, but that
> won't make it any more relevant to C++ in a year, in 10 years or in 20
> years. I'm sure that as your experience with C++ grows and you work in
> more diverse environments, you'll come to understand it.[/color]

I can refute the entire argument by simply and correctly stating that
implementations of existing XML standards can do that too.
--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Steven T. Hatton]

Re: High performance alternative to MI of virtual bases

Claudio Puviani wrote:
[color=blue]
> Feel free to hang on to it, if you're emotionally attached to it, but that
> won't make it any more relevant to C++ in a year, in 10 years or in 20
> years. I'm sure that as your experience with C++ grows and you work in
> more diverse environments, you'll come to understand it.[/color]

I can refute the entire argument by simply and correctly stating that
implementations of existing XML standards can do that too.
--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Claudio Puviani]

Re: High performance alternative to MI of virtual bases

"Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote[color=blue]
> Claudio Puviani wrote:
>[color=green]
> > Feel free to hang on to it, if you're emotionally attached
> > to it, but that won't make it any more relevant to C++ in
> > a year, in 10 years or in 20 years. I'm sure that as your
> > experience with C++ grows and you work in more diverse
> > environments, you'll come to understand it.[/color]
>
> I can refute the entire argument by simply and correctly
> stating that implementations of existing XML standards
> can do that too.[/color]

At least you're consistently irrelevant. XML is not C++. C++ is orders of
magnitude more complex than XML and regularity was never a design goal for
C++. Comparing the two can most charitably be described as foolish. Any more
absurdities you want to contribute?

Claudio Puviani

[Claudio Puviani]

Re: High performance alternative to MI of virtual bases

"Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote[color=blue]
> Claudio Puviani wrote:
>[color=green]
> > Feel free to hang on to it, if you're emotionally attached
> > to it, but that won't make it any more relevant to C++ in
> > a year, in 10 years or in 20 years. I'm sure that as your
> > experience with C++ grows and you work in more diverse
> > environments, you'll come to understand it.[/color]
>
> I can refute the entire argument by simply and correctly
> stating that implementations of existing XML standards
> can do that too.[/color]

At least you're consistently irrelevant. XML is not C++. C++ is orders of
magnitude more complex than XML and regularity was never a design goal for
C++. Comparing the two can most charitably be described as foolish. Any more
absurdities you want to contribute?

Claudio Puviani

[Steven T. Hatton]

Re: High performance alternative to MI of virtual bases

Claudio Puviani wrote:
[color=blue]
> "Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote[color=green]
>> Claudio Puviani wrote:
>>[color=darkred]
>> > Feel free to hang on to it, if you're emotionally attached
>> > to it, but that won't make it any more relevant to C++ in
>> > a year, in 10 years or in 20 years. I'm sure that as your
>> > experience with C++ grows and you work in more diverse
>> > environments, you'll come to understand it.[/color]
>>
>> I can refute the entire argument by simply and correctly
>> stating that implementations of existing XML standards
>> can do that too.[/color]
>
> At least you're consistently irrelevant. XML is not C++. C++ is orders of
> magnitude more complex than XML and regularity was never a design goal for
> C++. Comparing the two can most charitably be described as foolish. Any
> more absurdities you want to contribute?
>
> Claudio Puviani[/color]
Claudio, Claudio, Claudio, XML is a *M*arkup *L*anguage. In combination with
one of the XML schema fromats such as XMLSchema, Relax, DTD, SOX, etc., it
serves as an extremely powerful and flexible metalanguage that can be used
to formally define other languages. One of its greatest strengths is that
it facilitates the creation of tools for parsing, validating, verifying,
manipulating, displaying, and saving structured text based data. Another
common term for these XML schema instances is *grammars*. That is in the
same sense that EBNF is a metalanguage for defining grammars. AAMOF, I
pretty sure Xerces supports EBNF. But only the Java version.
--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Steven T. Hatton]

Re: High performance alternative to MI of virtual bases

Claudio Puviani wrote:
[color=blue]
> "Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote[color=green]
>> Claudio Puviani wrote:
>>[color=darkred]
>> > Feel free to hang on to it, if you're emotionally attached
>> > to it, but that won't make it any more relevant to C++ in
>> > a year, in 10 years or in 20 years. I'm sure that as your
>> > experience with C++ grows and you work in more diverse
>> > environments, you'll come to understand it.[/color]
>>
>> I can refute the entire argument by simply and correctly
>> stating that implementations of existing XML standards
>> can do that too.[/color]
>
> At least you're consistently irrelevant. XML is not C++. C++ is orders of
> magnitude more complex than XML and regularity was never a design goal for
> C++. Comparing the two can most charitably be described as foolish. Any
> more absurdities you want to contribute?
>
> Claudio Puviani[/color]
Claudio, Claudio, Claudio, XML is a *M*arkup *L*anguage. In combination with
one of the XML schema fromats such as XMLSchema, Relax, DTD, SOX, etc., it
serves as an extremely powerful and flexible metalanguage that can be used
to formally define other languages. One of its greatest strengths is that
it facilitates the creation of tools for parsing, validating, verifying,
manipulating, displaying, and saving structured text based data. Another
common term for these XML schema instances is *grammars*. That is in the
same sense that EBNF is a metalanguage for defining grammars. AAMOF, I
pretty sure Xerces supports EBNF. But only the Java version.
--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Claudio Puviani]

Re: High performance alternative to MI of virtual bases

"Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote[color=blue]
> Claudio, Claudio, Claudio, XML is a *M*arkup *L*anguage.
> In combination with one of the XML schema fromats such as
> XMLSchema, Relax, DTD, SOX, etc., it serves as an
> extremely powerful and flexible metalanguage that can be used
> to formally define other languages. One of its greatest strengths
> is that it facilitates the creation of tools for parsing, validating,
> verifying, manipulating, displaying, and saving structured text
> based data. Another common term for these XML schema
> instances is *grammars*. That is in the same sense that EBNF
> is a metalanguage for defining grammars. AAMOF, I pretty
> sure Xerces supports EBNF. But only the Java version.[/color]

And with this final burst of asinine misinterpretati on and irrelevance
couched in self-important bluster, you finally make the killfile. It's
really my fault for not having done it sooner, since the indications were
there from your first posting.

Claudio Puviani