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:WRfdc.1468 0$Po2.6045500@n ews4.srv.hcvlny .cv.net...[color=blue]
> "Steven T. Hatton" <susudata@setid ava.kushan.aa> wrote[color=green]
> >
> > I'm not really sure how to persuade people to reexamine
> > their accepted notions.[/color]
>
> You still don't realize that people DO reexamine their accepted notions.
> Your problem is that they don't do it on your schedule and on your terms.[/color]
I[color=blue]
> haven't seen a single new idea on this newsgroup regarding language design
> and every one of those ideas that have been presented as mind-blowing
> innovations has been discussed many times long, long ago and rejected for
> very valid reasons. Understand that it's phenomenally boring to have to
> rehash old (and off-topic) news every time some self-styled visionary[/color]
makes[color=blue]
> a triumphant entrance and announces that he looked at a circle and claims[/color]
to[color=blue]
> be the genius who invented the wheel. It's even worse when this luminary
> bases his/her wheel on a square and is too hard-headed to accept that the
> idea is flawed, if not completely useless.[/color]

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=blue]
> The other thing that you don't realize is that this is behavior that[/color]
people[color=blue]
> usually outgrow at or around puberty, so when we see it in this forum, we
> eventually conclude that the person is either an opinionated child or
> someone with a "slowed" social development. Either way, trying to reason
> with such a person is essentially a waste of time, though we sometimes[/color]
give[color=blue]
> the benefit of the doubt and try anyway.[/color]

I am not one of these people.
[color=blue][color=green]
> > One factor is probably important in any such endeavor. People
> > have to believe there is a significant problem that your proposal
> > addresses.[/color]
>
> This is partly true, but it's also necessary for the problem to not have[/color]
an[color=blue]
> existing trivial solution. Very often, the best answer to "Doc, it hurts
> when I do this" _is_ "then, don't do it." In the case of this particular
> thread, changing the language or adding Yet Another Preprocessor Pass to
> mitigate the costs of abusing MI is NOT an intelligent solution to the
> problem. The solution is: don't abuse MI.[/color]

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.
Heavy use of MI is only "abuse" because the approach of using ABC's to
emulate interfaces is flawed. I wrote a bit more about this at:

http://www.heron-language.com/abc-iop.html

[color=blue]
>It's what experienced programmers
> eventually figure out for themselves and it's why you don't see hordes of
> people falling to their knees worshipping this monstrosity.[/color]

I assume the monstrosity you refer to is the HeronFront idea. 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=blue]
> The same applied
> when you proposed adding IDE functionality to the language standard or[/color]
when[color=blue]
> Julie proposed turning C++ source code into a database.[/color]

Please don't take this thread as an oportunity to launch an attack against
another of our colleagues.
[color=blue]
>It's not the world
> that's oblivious to your genius or that refuses to open its collective[/color]
mind[color=blue]
> to new ideas, it's the idea that sucks. The trick is to accept it and use
> one's intellect to come up with better ideas rather than waste it fixated[/color]
on[color=blue]
> defending a bad one. I've seen exceptionally bright people lose their jobs
> because they couldn't let go of a losing crusade.
>
> Claudio Puviani[/color]

It seems that you are more on a crusade than interested in any real
discussion. I would ask that you please try to keep to the discussion at
hand or not post to this thread. Thank you.

--
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:n5hdc.1590 2$Po2.6255148@n ews4.srv.hcvlny .cv.net...[color=blue]
> "christophe r diggins" <cdiggins@video tron.ca> wrote[color=green]
> >
> > I understand that it can be difficult to sift through the huge
> > amount of "mind blowing revelations", but I have put an
> > enormous amount of work into testing and demonstrating
> > my work.[/color]
>
> Maybe, but you failed to make the premise interesting. Someone else might
> have a fantastic solution for dereferencing NULL pointers, but what's the
> interest when all one has to do is avoid the dubious practice?[/color]

I am trying to make the point that it is a dubious practice only because of
the way it is implemented, not because of some other design problem.
[color=blue][color=green]
> > I am just afraid that somehow what I have been doing is
> > being dismissed without even being looked at seriously.[/color]
>
> I've gone through your web site and looked at the examples and the[/color]
proposed[color=blue]
> solutions. It doesn't take a very detailed analysis to realize that what
> you're proposing is overkill for a simple problem that's already being
> solved by careful software design.[/color]

I assume you mean the solution that we should not use multiple base classes
in lightweight classes?
[color=blue][color=green]
> > How can I make my work stand out from the other
> > unresearched, untested and undemonstrated crud that
> > other people flood the newgroups with?[/color]
>
> The first step is to tone down your presentation. You'll be taken more
> seriously if you present a complex or serious problem in a subdued light
> than if you take something simple and blow it out of proportion.[/color]

That is a very good point.
[color=blue]
> The same
> applies to the solution. People may take an interest in ideas and tricks
> that are presented in an off-handed manner, but you set people's
> expectations way too high when you propose changes to the language or talk
> about new paradigms or new standards. If the idea really is good, others
> will jump on the bandwagon even without you making a fanfare. If the idea[/color]
is[color=blue]
> bad, the fanfare is just a nail in its coffin.[/color]

Noted.
[color=blue][color=green]
> > My proposal is relevant if you have ever tried to
> > inherit from an abstract base class. I demonstrate
> > that an Int class can be implemented using interfaces
> > in the same amount of code but requires 1/8th the
> > size and performs 4x faster.[/color]
>
> You've just illustrated one reason why your work is being ignored. To even
> suggest that an Int class is a valid candidate for MI casts doubt on your
> judgment and consequently, on all of your work. If you want to demonstrate
> the value of your work, do so with an example that doesn't put your work[/color]
in[color=blue]
> a bad light. For example, show how IOStreams (or a similar set of classes)
> would benefit from this and cite benchmarks on more than one platform.[/color]
This[color=blue]
> would have value and would elicit interest, if not necessarily agreement.[/color]
A[color=blue]
> ridiculous example isn't worth anyone's time.
>
> Claudio Puviani[/color]

This presents a strange sort of paradox for me. The solution I am proposing
represents a kind of MI but isn't really. The truth is that MI is the
closest you can come in C++ to an interface based example (at least without
writing reams and reams of complex scaffolding code). So the paradox is that
the C++ example seems ridiculous compared to the example using interfaces
because the HeronFront idea represents a separate paradigm. No one in their
right mind would consider writing code like I did in C++ because it is slow
and bloated. My point is that if it wasn't inefficient to have multiple
bases for lightweight classes, this would represent a new way to approach
their software designs that is no longer ridiculous.

Perhaps I need to demonstrate more fully the advantages of multiple base
inheritance?

--
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:n5hdc.1590 2$Po2.6255148@n ews4.srv.hcvlny .cv.net...[color=blue]
> "christophe r diggins" <cdiggins@video tron.ca> wrote[color=green]
> >
> > I understand that it can be difficult to sift through the huge
> > amount of "mind blowing revelations", but I have put an
> > enormous amount of work into testing and demonstrating
> > my work.[/color]
>
> Maybe, but you failed to make the premise interesting. Someone else might
> have a fantastic solution for dereferencing NULL pointers, but what's the
> interest when all one has to do is avoid the dubious practice?[/color]

I am trying to make the point that it is a dubious practice only because of
the way it is implemented, not because of some other design problem.
[color=blue][color=green]
> > I am just afraid that somehow what I have been doing is
> > being dismissed without even being looked at seriously.[/color]
>
> I've gone through your web site and looked at the examples and the[/color]
proposed[color=blue]
> solutions. It doesn't take a very detailed analysis to realize that what
> you're proposing is overkill for a simple problem that's already being
> solved by careful software design.[/color]

I assume you mean the solution that we should not use multiple base classes
in lightweight classes?
[color=blue][color=green]
> > How can I make my work stand out from the other
> > unresearched, untested and undemonstrated crud that
> > other people flood the newgroups with?[/color]
>
> The first step is to tone down your presentation. You'll be taken more
> seriously if you present a complex or serious problem in a subdued light
> than if you take something simple and blow it out of proportion.[/color]

That is a very good point.
[color=blue]
> The same
> applies to the solution. People may take an interest in ideas and tricks
> that are presented in an off-handed manner, but you set people's
> expectations way too high when you propose changes to the language or talk
> about new paradigms or new standards. If the idea really is good, others
> will jump on the bandwagon even without you making a fanfare. If the idea[/color]
is[color=blue]
> bad, the fanfare is just a nail in its coffin.[/color]

Noted.
[color=blue][color=green]
> > My proposal is relevant if you have ever tried to
> > inherit from an abstract base class. I demonstrate
> > that an Int class can be implemented using interfaces
> > in the same amount of code but requires 1/8th the
> > size and performs 4x faster.[/color]
>
> You've just illustrated one reason why your work is being ignored. To even
> suggest that an Int class is a valid candidate for MI casts doubt on your
> judgment and consequently, on all of your work. If you want to demonstrate
> the value of your work, do so with an example that doesn't put your work[/color]
in[color=blue]
> a bad light. For example, show how IOStreams (or a similar set of classes)
> would benefit from this and cite benchmarks on more than one platform.[/color]
This[color=blue]
> would have value and would elicit interest, if not necessarily agreement.[/color]
A[color=blue]
> ridiculous example isn't worth anyone's time.
>
> Claudio Puviani[/color]

This presents a strange sort of paradox for me. The solution I am proposing
represents a kind of MI but isn't really. The truth is that MI is the
closest you can come in C++ to an interface based example (at least without
writing reams and reams of complex scaffolding code). So the paradox is that
the C++ example seems ridiculous compared to the example using interfaces
because the HeronFront idea represents a separate paradigm. No one in their
right mind would consider writing code like I did in C++ because it is slow
and bloated. My point is that if it wasn't inefficient to have multiple
bases for lightweight classes, this would represent a new way to approach
their software designs that is no longer ridiculous.

Perhaps I need to demonstrate more fully the advantages of multiple base
inheritance?

--
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:bI6dnQe44L PG4-jdRVn_iw@speake asy.net...[color=blue]
> christopher diggins wrote:
>[color=green]
> > Thank you bringing this newgroup to my attention. I was actually unaware
> > of its existance. I will give it a whirl. Still blown away that no-one
> > else has commented on my posts. I wonder what would be required to bring
> > this to people's attention?[/color]
>
> I'm not really sure how to persuade people to reexamine their accepted
> notions. One factor is probably important in any such endeavor. People[/color]
have[color=blue]
> to believe there is a significant problem that your proposal addresses.
> I'm not well versed enough on the relevant issues to evaluate the[/color]
competing[color=blue]
> assertions regarding the cost of using (pure) virtual functions. I see[/color]
you[color=blue]
> assert:
>
> "When multiply inheriting pure virtual (abstract) base classes, a class
> obviously bloats quickly for each new vtable needed. Execution slows down
> considerably as well."
>
> Arnold, Gosling and Holmes, in their _The Java Programming Language_3rd[/color]
Ed.[color=blue]
> suggest that the cost of indirect function calls is significant enough to
> take measures to avoid it. Of course that applies to Java, and not
> directly to C++. Nonetheless, I suspect the mechanisms are similar enough
> to make their observations relevant for consideration in this context.
>
> I know of one other author who described the cost as "a great deal of
> runtime overhead", but I don't consider his book to be a definitive C++
> work. http://www.rea.com/display_prod.cfm?...9&g=0878916849
>
> Stroustrup seems to think the cost is minimal:
> http://www.research.att.com/~bs/crc.pdf
> "A function declared in a derived class is said to override a virtual
> function with the same name and type in a base class. It is the language s
> job to ensure that calls of Character_ device s virtual functions, such[/color]
as[color=blue]
> write() invoke the appropriate overriding function for the derived class
> actually used. The overhead of doing that in C++ is minimal and perfectly
> predictable. The extra run-time overhead of a virtual function is a
> fraction of the cost of an ordinary function call."
>
> So, perhaps your first challenge is to provide some convincing metrics.[/color]
I'm[color=blue]
> not trying to shoot your ideas down. I'm just giving you the few relevant
> facts I am aware of regarding this topic. I just read the paragraph from
> Stroustrup's article. That explains why I hadn't mentioned it in my
> previous replies.[/color]

The cost of making virtual costs are indeed negligble in programs that use
virtual functions judiciously. I am trying to demonstrate an example that
uses polymorphism heavily, and how we need not be concerned with runttime
performance when using interfaces. I have placed my test program online in
html format at C:\dev\hrn\web\ heron-language.com\hf ront-test.html hopefully
this is along the lines of what you want to see? For me though the real
problem is not the execution speed but the size of the objects. I also think
the designs that use interfaces are more elegant than those that use
Abstract Base Classes (when they are what is intended).

--
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:bI6dnQe44L PG4-jdRVn_iw@speake asy.net...[color=blue]
> christopher diggins wrote:
>[color=green]
> > Thank you bringing this newgroup to my attention. I was actually unaware
> > of its existance. I will give it a whirl. Still blown away that no-one
> > else has commented on my posts. I wonder what would be required to bring
> > this to people's attention?[/color]
>
> I'm not really sure how to persuade people to reexamine their accepted
> notions. One factor is probably important in any such endeavor. People[/color]
have[color=blue]
> to believe there is a significant problem that your proposal addresses.
> I'm not well versed enough on the relevant issues to evaluate the[/color]
competing[color=blue]
> assertions regarding the cost of using (pure) virtual functions. I see[/color]
you[color=blue]
> assert:
>
> "When multiply inheriting pure virtual (abstract) base classes, a class
> obviously bloats quickly for each new vtable needed. Execution slows down
> considerably as well."
>
> Arnold, Gosling and Holmes, in their _The Java Programming Language_3rd[/color]
Ed.[color=blue]
> suggest that the cost of indirect function calls is significant enough to
> take measures to avoid it. Of course that applies to Java, and not
> directly to C++. Nonetheless, I suspect the mechanisms are similar enough
> to make their observations relevant for consideration in this context.
>
> I know of one other author who described the cost as "a great deal of
> runtime overhead", but I don't consider his book to be a definitive C++
> work. http://www.rea.com/display_prod.cfm?...9&g=0878916849
>
> Stroustrup seems to think the cost is minimal:
> http://www.research.att.com/~bs/crc.pdf
> "A function declared in a derived class is said to override a virtual
> function with the same name and type in a base class. It is the language s
> job to ensure that calls of Character_ device s virtual functions, such[/color]
as[color=blue]
> write() invoke the appropriate overriding function for the derived class
> actually used. The overhead of doing that in C++ is minimal and perfectly
> predictable. The extra run-time overhead of a virtual function is a
> fraction of the cost of an ordinary function call."
>
> So, perhaps your first challenge is to provide some convincing metrics.[/color]
I'm[color=blue]
> not trying to shoot your ideas down. I'm just giving you the few relevant
> facts I am aware of regarding this topic. I just read the paragraph from
> Stroustrup's article. That explains why I hadn't mentioned it in my
> previous replies.[/color]

The cost of making virtual costs are indeed negligble in programs that use
virtual functions judiciously. I am trying to demonstrate an example that
uses polymorphism heavily, and how we need not be concerned with runttime
performance when using interfaces. I have placed my test program online in
html format at C:\dev\hrn\web\ heron-language.com\hf ront-test.html hopefully
this is along the lines of what you want to see? For me though the real
problem is not the execution speed but the size of the objects. I also think
the designs that use interfaces are more elegant than those that use
Abstract Base Classes (when they are what is intended).

--
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:rZednaCg-Y1WBOjdRVn-hQ@speakeasy.ne t...[color=blue]
> christopher diggins wrote:[/color]

[snip]
[color=blue][color=green]
> > I am using the Java definition that an
> > interface type as a reference to an object which provides[/color][/color]
implementations[color=blue][color=green]
> > for a given set of functions. Pure Abstract Base Classes are based on[/color][/color]
the[color=blue][color=green]
> > notion of virtual functions which are not neccessary for implementing
> > interfaces.[/color]
>
> Can you point me to the 'executive summary' describing the alternative?[/color]

Could you explain what you mean by that?
[color=blue][color=green]
> > The other alternative to the notions of interface which I am
> > trying to promote is that we could formalize the notion of a Pure[/color][/color]
Abstract[color=blue][color=green]
> > Base Class as a separate construct rather than an instance of use of
> > inheritable classes with virtual functions.[/color][/color]

This statement is false. I wish to retract it. HeronFront interfaces are not
virtual.
[color=blue]
> I recently proposed using the keyword /interface/ to signify a class with
> all pure virtual functions. It would simply be a shorthand, and a
> guarantee to the user that it really was such a thing. Is this different
> from your basic notion of /interface/?[/color]

So yes it would be different because in HeronFront interface functions are
not virtual, this is why I can drop the vtable (see
http://www.heron-language.com/abc-iop.html ).

--
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:rZednaCg-Y1WBOjdRVn-hQ@speakeasy.ne t...[color=blue]
> christopher diggins wrote:[/color]

[snip]
[color=blue][color=green]
> > I am using the Java definition that an
> > interface type as a reference to an object which provides[/color][/color]
implementations[color=blue][color=green]
> > for a given set of functions. Pure Abstract Base Classes are based on[/color][/color]
the[color=blue][color=green]
> > notion of virtual functions which are not neccessary for implementing
> > interfaces.[/color]
>
> Can you point me to the 'executive summary' describing the alternative?[/color]

Could you explain what you mean by that?
[color=blue][color=green]
> > The other alternative to the notions of interface which I am
> > trying to promote is that we could formalize the notion of a Pure[/color][/color]
Abstract[color=blue][color=green]
> > Base Class as a separate construct rather than an instance of use of
> > inheritable classes with virtual functions.[/color][/color]

This statement is false. I wish to retract it. HeronFront interfaces are not
virtual.
[color=blue]
> I recently proposed using the keyword /interface/ to signify a class with
> all pure virtual functions. It would simply be a shorthand, and a
> guarantee to the user that it really was such a thing. Is this different
> from your basic notion of /interface/?[/color]

So yes it would be different because in HeronFront interface functions are
not virtual, this is why I can drop the vtable (see
http://www.heron-language.com/abc-iop.html ).

--
Christopher Diggins

http://www.cdiggins.com

http://www.heron-language.com

[christopher diggins]

Re: High performance alternative to MI of virtual bases

"Kevin Goodsell" <usenet2.spamfr ee.fusion@never box.com> wrote in message
news:c5gdc.1353 $k05.1017@newsr ead2.news.pas.e arthlink.net...[color=blue]
> christopher diggins wrote:
>[color=green]
> >
> > Thank you bringing this newgroup to my attention. I was actually unaware[/color][/color]
of[color=blue][color=green]
> > its existance. I will give it a whirl. Still blown away that no-one else[/color][/color]
has[color=blue][color=green]
> > commented on my posts. I wonder what would be required to bring this to
> > people's attention?
> >[/color]
>
> I looked at your pages. Twice, actually (both times you posted it). I
> couldn't find any useful (to me) information on what you are doing. I
> admit that it's possible that I didn't look closely enough. I was
> looking for things like:
>
> * A description of the semantics of your language extension.
> * How the technical implementation differs from abstract bases, in other
> words, the theory behind why it should be better.
> * Actual evidence of the speed/size improvements, including things like
> benchmarks, compiler & version used, and options used.
> * Possibly a comparison using a less extreme example -- I've never seen
> any other case of someone using multiple inheritance of 7 bases.
>
> Essentially all I could find was some sample files and a link to
> download some software that I have no reason to want.
>
> -Kevin[/color]

Thank you very much Kevin. That was more valuable than you may realize. It
is really good to know why I was alienating people. I have placed much of
the relevant material online in html format now, so if you go back one last
time to http://www.heron-language.com/heronfront.html , you should find more
of what you were looking for except for the semantics. I haven't gotten
around to that yet.

Concerning the extreme example, I like it because it makes my point load and
clear. People don't use MI of 7 bases because it is inefficient, what
HeronFront shows is how adding interfaces would make it viable. It is hard
to prepare examples where people use documentation or other tricks to
accomplish what would be better served by using multiple bases. That being
said, if you an idea of a specific example you would like to see, let me
know and I will consider putting another together.

--
Christopher Diggins

http://www.cdiggins.com

http://www.heron-language.com

[christopher diggins]

Re: High performance alternative to MI of virtual bases

"Kevin Goodsell" <usenet2.spamfr ee.fusion@never box.com> wrote in message
news:c5gdc.1353 $k05.1017@newsr ead2.news.pas.e arthlink.net...[color=blue]
> christopher diggins wrote:
>[color=green]
> >
> > Thank you bringing this newgroup to my attention. I was actually unaware[/color][/color]
of[color=blue][color=green]
> > its existance. I will give it a whirl. Still blown away that no-one else[/color][/color]
has[color=blue][color=green]
> > commented on my posts. I wonder what would be required to bring this to
> > people's attention?
> >[/color]
>
> I looked at your pages. Twice, actually (both times you posted it). I
> couldn't find any useful (to me) information on what you are doing. I
> admit that it's possible that I didn't look closely enough. I was
> looking for things like:
>
> * A description of the semantics of your language extension.
> * How the technical implementation differs from abstract bases, in other
> words, the theory behind why it should be better.
> * Actual evidence of the speed/size improvements, including things like
> benchmarks, compiler & version used, and options used.
> * Possibly a comparison using a less extreme example -- I've never seen
> any other case of someone using multiple inheritance of 7 bases.
>
> Essentially all I could find was some sample files and a link to
> download some software that I have no reason to want.
>
> -Kevin[/color]

Thank you very much Kevin. That was more valuable than you may realize. It
is really good to know why I was alienating people. I have placed much of
the relevant material online in html format now, so if you go back one last
time to http://www.heron-language.com/heronfront.html , you should find more
of what you were looking for except for the semantics. I haven't gotten
around to that yet.

Concerning the extreme example, I like it because it makes my point load and
clear. People don't use MI of 7 bases because it is inefficient, what
HeronFront shows is how adding interfaces would make it viable. It is hard
to prepare examples where people use documentation or other tricks to
accomplish what would be better served by using multiple bases. That being
said, if you an idea of a specific example you would like to see, let me
know and I will consider putting another together.

--
Christopher Diggins

http://www.cdiggins.com

http://www.heron-language.com

[Claudio Puviani]

Re: High performance alternative to MI of virtual bases

"christophe r diggins" <cdiggins@video tron.ca> wrote[color=blue]
> "Claudio Puviani" <puviani@hotmai l.com> wrote[color=green]
> > Understand that it's phenomenally boring to have to
> > rehash old (and off-topic) news every time some
> > self-styled visionary makes a triumphant entrance
> > and announces that he looked at a circle and claims
> > to be the genius who invented the wheel. It's even
> > worse when this luminary bases his/her wheel on a
> > square and is too hard-headed to accept that the
> > idea is flawed, if not completely useless.[/color]
>
> 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 to
some people involved in a few prior unrelated "debates", not to you. You've
so far shown yourself to be open to dissenting views, even if you don't
ascribe to them.
[color=blue][color=green]
> > The other thing that you don't realize is that this is
> > behavior that people usually outgrow at or around
> > puberty, so when we see it in this forum, we eventually
> > conclude that the person is either an opinionated child or
> > someone with a "slowed" social development. Either
> > way, trying to reason with such a person is essentially a
> > waste of time, though we sometimes give the benefit of
> > the doubt and try anyway.[/color]
>
> I am not one of these people.[/color]

Clearly not, but the person I was addressing has an almost unwavering
pattern, which you'll soon observe if you read this newsgroup regularly.
It's in part because of a barage of senseless posts like his that legitimate
requests for review can sometimes be lumped in with the bad.
[color=blue][color=green][color=darkred]
> > > One factor is probably important in any such endeavor.
> > > People have to believe there is a significant problem
> > > that your proposal addresses.[/color]
> >
> > This is partly true, but it's also necessary for the problem
> > to not have an existing trivial solution. Very often, the best
> > answer to "Doc, it hurts when I do this" _is_ "then, don't
> > do it." In the case of this particular thread, changing the
> > language or adding Yet Another Preprocessor Pass to
> > mitigate the costs of abusing MI is NOT an intelligent
> > solution to the problem. The solution is: don't abuse MI.[/color]
>
> 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=blue]
> 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 meant
to model an IS-A relationship, not a LOOKS-LIKE or a BEHAVES-LIKE
relationship, which is what interfaces model. 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.

Interfaces _are_ an interesting paradigm, but they're not a C++ paradigm,
which is why this thread is off-topic in a newsgroup that's dedicated to the
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 of
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 the
C++ language AS IT'S DEFINED IN THE STANDARD, not any theoretical
extensions.

Clearly, Heron, as a language is completely off-topic.
[color=blue]
> I wrote a bit more about this at:
> http://www.heron-language.com/abc-iop.html
>[color=green]
> >It's what experienced programmers
> > eventually figure out for themselves and it's why you don't see
> > hordes of people falling to their knees worshipping this
> > monstrosity.[/color]
>
> I assume the monstrosity you refer to is the HeronFront idea.[/color]

That's correct.
[color=blue]
> 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=blue][color=green]
> > The same applied when you proposed adding IDE
> > functionality to the language standard or when Julie
> > proposed turning C++ source code into a database.[/color]
>
> Please don't take this thread as an oportunity to launch
> an attack against another of our colleagues.[/color]

Julie is a colleague to the extent that she actually works in C++, and while
I disagree with many of her views, I respect her as an individual. Steven is
a source of noise whose relationship to the world of C++ is limited to an
abundance of absurd preconceptions and a willingness to contradict anyone in
any topic that he barely understands. I take it as an insult to have anyone
consider him to be my colleague in any way, shape or form.

[color=blue]
> It seems that you are more on a crusade than interested in any real
> discussion. I would ask that you please try to keep to the discussion at
> hand or not post to this thread. Thank you.[/color]

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.

Claudio Puviani

[Claudio Puviani]

Re: High performance alternative to MI of virtual bases

"christophe r diggins" <cdiggins@video tron.ca> wrote[color=blue]
> "Claudio Puviani" <puviani@hotmai l.com> wrote[color=green]
> > Understand that it's phenomenally boring to have to
> > rehash old (and off-topic) news every time some
> > self-styled visionary makes a triumphant entrance
> > and announces that he looked at a circle and claims
> > to be the genius who invented the wheel. It's even
> > worse when this luminary bases his/her wheel on a
> > square and is too hard-headed to accept that the
> > idea is flawed, if not completely useless.[/color]
>
> 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 to
some people involved in a few prior unrelated "debates", not to you. You've
so far shown yourself to be open to dissenting views, even if you don't
ascribe to them.
[color=blue][color=green]
> > The other thing that you don't realize is that this is
> > behavior that people usually outgrow at or around
> > puberty, so when we see it in this forum, we eventually
> > conclude that the person is either an opinionated child or
> > someone with a "slowed" social development. Either
> > way, trying to reason with such a person is essentially a
> > waste of time, though we sometimes give the benefit of
> > the doubt and try anyway.[/color]
>
> I am not one of these people.[/color]

Clearly not, but the person I was addressing has an almost unwavering
pattern, which you'll soon observe if you read this newsgroup regularly.
It's in part because of a barage of senseless posts like his that legitimate
requests for review can sometimes be lumped in with the bad.
[color=blue][color=green][color=darkred]
> > > One factor is probably important in any such endeavor.
> > > People have to believe there is a significant problem
> > > that your proposal addresses.[/color]
> >
> > This is partly true, but it's also necessary for the problem
> > to not have an existing trivial solution. Very often, the best
> > answer to "Doc, it hurts when I do this" _is_ "then, don't
> > do it." In the case of this particular thread, changing the
> > language or adding Yet Another Preprocessor Pass to
> > mitigate the costs of abusing MI is NOT an intelligent
> > solution to the problem. The solution is: don't abuse MI.[/color]
>
> 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=blue]
> 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 meant
to model an IS-A relationship, not a LOOKS-LIKE or a BEHAVES-LIKE
relationship, which is what interfaces model. 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.

Interfaces _are_ an interesting paradigm, but they're not a C++ paradigm,
which is why this thread is off-topic in a newsgroup that's dedicated to the
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 of
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 the
C++ language AS IT'S DEFINED IN THE STANDARD, not any theoretical
extensions.

Clearly, Heron, as a language is completely off-topic.
[color=blue]
> I wrote a bit more about this at:
> http://www.heron-language.com/abc-iop.html
>[color=green]
> >It's what experienced programmers
> > eventually figure out for themselves and it's why you don't see
> > hordes of people falling to their knees worshipping this
> > monstrosity.[/color]
>
> I assume the monstrosity you refer to is the HeronFront idea.[/color]

That's correct.
[color=blue]
> 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=blue][color=green]
> > The same applied when you proposed adding IDE
> > functionality to the language standard or when Julie
> > proposed turning C++ source code into a database.[/color]
>
> Please don't take this thread as an oportunity to launch
> an attack against another of our colleagues.[/color]

Julie is a colleague to the extent that she actually works in C++, and while
I disagree with many of her views, I respect her as an individual. Steven is
a source of noise whose relationship to the world of C++ is limited to an
abundance of absurd preconceptions and a willingness to contradict anyone in
any topic that he barely understands. I take it as an insult to have anyone
consider him to be my colleague in any way, shape or form.

[color=blue]
> It seems that you are more on a crusade than interested in any real
> discussion. I would ask that you please try to keep to the discussion at
> hand or not post to this thread. Thank you.[/color]

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.

Claudio Puviani

[Steven T. Hatton]

Re: High performance alternative to MI of virtual bases

christopher diggins wrote:
[color=blue][color=green]
>> Can you point me to the 'executive summary' describing the alternative?[/color]
>
> Could you explain what you mean by that?[/color]

This:
[color=blue]
> http://www.heron-language.com/abc-iop.html[/color]

Thanks.

Can I assume the only difference between an ABC with all pure virtual member
functions and your interface is the "fat pointer" replacing the vtbl?
--
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][color=green]
>> Can you point me to the 'executive summary' describing the alternative?[/color]
>
> Could you explain what you mean by that?[/color]

This:
[color=blue]
> http://www.heron-language.com/abc-iop.html[/color]

Thanks.

Can I assume the only difference between an ABC with all pure virtual member
functions and your interface is the "fat pointer" replacing the vtbl?
--
p->m == (*p).m == p[0].m

http://www.kdevelop.org

http://www.suse.com

http://www.mozilla.org

[Julie]

Re: High performance alternative to MI of virtual bases

I don't know how I got dragged into this thread... Since Godwin's law doesn't
yet apply, I guess I'll clarify:

Claudio Puviani wrote:[color=blue][color=green][color=darkred]
> > > when Julie proposed turning C++ source code into a database.[/color]
> >
> > In some ways that is actually a fairly common practice.[/color]
>
> You know as well as I that what she proposed was not storing source in
> version control systems or archives or anything similar, but rather a
> restructuring of the language to make language elements independent of
> translation units.[/color]

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=blue][color=green]
> > 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 clung
> to it.
>[color=green]
> > 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). Why it didn't take, I
don't know. A lot of (good) ideas don't take for various reasons -- that
doesn't imply that it is a bad idea, though.

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.

I'm not clinging to the idea, I just haven't heard anything substantive that
explains its inherent shortcomings (excepting technological limitations). I'm
not going to drop the idea, however, just over some flap on a newsgroup.

[Julie]

Re: High performance alternative to MI of virtual bases

I don't know how I got dragged into this thread... Since Godwin's law doesn't
yet apply, I guess I'll clarify:

Claudio Puviani wrote:[color=blue][color=green][color=darkred]
> > > when Julie proposed turning C++ source code into a database.[/color]
> >
> > In some ways that is actually a fairly common practice.[/color]
>
> You know as well as I that what she proposed was not storing source in
> version control systems or archives or anything similar, but rather a
> restructuring of the language to make language elements independent of
> translation units.[/color]

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=blue][color=green]
> > 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 clung
> to it.
>[color=green]
> > 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). Why it didn't take, I
don't know. A lot of (good) ideas don't take for various reasons -- that
doesn't imply that it is a bad idea, though.

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.

I'm not clinging to the idea, I just haven't heard anything substantive that
explains its inherent shortcomings (excepting technological limitations). I'm
not going to drop the idea, however, just over some flap on a newsgroup.