High performance alternative to MI of virtual bases

[christopher diggins]

Since nobody responded to my earlier post [C++ with interfaces], I thought I
would try to explain what I am doing a bit differently.

When multiply inheriting pure virtual (abstract) base classes, a class
obviously bloats quickly for each new vtable needed. Execution slows down
considerably as well. You can work around this by using interfaces
referemnces which have a pointer to the object and a pointer to an external
function lookup table. This technique requires extra typing but produces
very efficient code. I have written a language extension to C++ which
facilitates this technique and it is available at
http://www.heron-language.com/heronfront.html

What I am hoping from the group is for people to pick apart my examples, and
the techniques I am using. The other thing is to find out who is interested
in this work, and whether there is other similar work elsewhere on the net.

Thanks!

 

[Steven T. Hatton]

Since nobody responded to my earlier post [C++ with interfaces], I thought
I would try to explain what I am doing a bit differently.

When multiply inheriting pure virtual (abstract) base classes, a class
obviously bloats quickly for each new vtable needed. Execution slows down
considerably as well. You can work around this by using interfaces
referemnces which have a pointer to the object and a pointer to an
external function lookup table. This technique requires extra typing but
produces very efficient code. I have written a language extension to C++
which facilitates this technique and it is available at
http://www.heron-language.com/heronfront.html

What I am hoping from the group is for people to pick apart my examples,
and the techniques I am using. The other thing is to find out who is
interested in this work, and whether there is other similar work elsewhere
on the net.

Thanks!

Have you considered posting this to comp.std.c++?

 

[Steven T. Hatton]

Since nobody responded to my earlier post [C++ with interfaces], I thought
I would try to explain what I am doing a bit differently.

When multiply inheriting pure virtual (abstract) base classes, a class
obviously bloats quickly for each new vtable needed. Execution slows down
considerably as well. You can work around this by using interfaces
referemnces which have a pointer to the object and a pointer to an
external function lookup table. This technique requires extra typing but
produces very efficient code. I have written a language extension to C++
which facilitates this technique and it is available at
http://www.heron-language.com/heronfront.html

What I am hoping from the group is for people to pick apart my examples,
and the techniques I am using. The other thing is to find out who is
interested in this work, and whether there is other similar work elsewhere
on the net.

Thanks!

I just came across these comments by Stroustrup, and found them interesting
in light of your suggestions. I will admit to not fully following all you
are doing. I simply don't have time right now. I do very much like the
idea of adding an interface type to the language. My approach would have
been to simply define an interface as an ABC as described below.

I haven't seen you post anything to comp.std.c++. I wasn't trying to
discourage you from posting to c.l.c++. Some people might find what you
are doing off topic. I tend to view it as relevant to C++.

http://www.artima.com/intv/modern.html
"Bjarne Stroustrup: I had a lot of problems explaining that to people and
never quite understood why it was hard to understand. From the first days
of C++, there were classes with data and classes without data. The emphasis
in the old days was building up from a root with stuff in it, but there
were always abstract base classes. In the mid to late eighties, they were
commonly called ABCs (Abstract Base Classes): classes that consisted only
of virtual functions. In 1987, I supported pure interfaces directly in C++
by saying a class is abstract if it has a pure virtual function, which is a
function that must be overridden. Since then I have consistently pointed
out that one of the major ways of writing classes in C++ is without any
state, that is, just an interface.

"From a C++ view there's no difference between an abstract class and an
interface. Sometimes we use the phrase "pure abstract class," meaning a
class that exclusively has pure virtual functions (and no data). It is the
most common kind of abstract class. When I tried to explain this I found I
couldn't effectively get the idea across until I introduced direct language
support in the form of pure virtual functions. Since people could put data
in the base classes, they sort of felt obliged to do so. People built the
classic brittle base classes and got the classic brittle base class
problems, and I couldn't understand why people were doing it. When I tried
to teach the idea with abstract base classes directly supported in C++, I
had more luck, but many people still didn't get it. I think it was a major
failure in education on my part. I didn't imagine the problem well. That
actually matches some of the early failures of the Simula community to get
crucial new ideas across. Some new ideas are hard to get across, and part
of the problem is a lot of people don't want to learn something genuinly
new. They think they know the answer. And once we think we know the answer,
it's very hard to learn something new. Abstract classes were described,
with several examples, in The C++ Programming Language, Second Edition, in
1991, but unfortunately not used systematically throughout the book."

 

[christopher diggins]

Since nobody responded to my earlier post [C++ with interfaces], I thought
I would try to explain what I am doing a bit differently.

When multiply inheriting pure virtual (abstract) base classes, a class
obviously bloats quickly for each new vtable needed. Execution slows down
considerably as well. You can work around this by using interfaces
referemnces which have a pointer to the object and a pointer to an
external function lookup table. This technique requires extra typing but
produces very efficient code. I have written a language extension to C++
which facilitates this technique and it is available at
http://www.heron-language.com/heronfront.html

What I am hoping from the group is for people to pick apart my examples,
and the techniques I am using. The other thing is to find out who is
interested in this work, and whether there is other similar work elsewhere
on the net.

Thanks!

Have you considered posting this to comp.std.c++?

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?

 

[Claudio Puviani]

[snip]

Still blown away that no-one else has commented on
my posts.

Did you stop to think that maybe no one else found the idea interesting? We
get "mind blowing revelations" every other week and suggestions to change
the language even more often. By now, it's lucky if a prophetic posting gets
a yawn.

I wonder what would be required to bring this to
people's attention?

Relevance?

Claudio Puviani

 

[Steven T. Hatton]

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?

I'm not really sure how to persuade people to reexamine their accepted
notions. One factor is probably important in any such endeavor. People have
to believe there is a significant problem that your proposal addresses.
I'm not well versed enough on the relevant issues to evaluate the competing
assertions regarding the cost of using (pure) virtual functions. I see you
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 Ed.
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?p=0878917489&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 as
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. I'm
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.

 

[Claudio Puviani]

I'm not really sure how to persuade people to reexamine
their accepted notions.

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. I
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 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.

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.

One factor is probably important in any such endeavor. People
have to believe there is a significant problem that your proposal
addresses.

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. 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. The same applied
when you proposed adding IDE functionality to the language standard or when
Julie proposed turning C++ source code into a database. It's not the world
that's oblivious to your genius or that refuses to open its collective mind
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 on
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

 

[Kevin Goodsell]

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?

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

 

[christopher diggins]

I just came across these comments by Stroustrup, and found them interesting
in light of your suggestions. I will admit to not fully following all you
are doing. I simply don't have time right now. I do very much like the
idea of adding an interface type to the language. My approach would have
been to simply define an interface as an ABC as described below.

Those are very interesting comments and I appreciate you digging them up.
What I did on my web page ( http://www.heron-language.com/heronfront.html )
was demonstrate that using ABC's like Interfaces in C++ introduces really
nasty code bloat, for example the Int class with 32 bytes because it
inherits from multiple base classes instead of simply 4 bytes which is all
that is really needed.

I haven't seen you post anything to comp.std.c++. I wasn't trying to
discourage you from posting to c.l.c++. Some people might find what you
are doing off topic. I tend to view it as relevant to C++.

I didn't take your suggestion that way at all. I too do not consider what I
am doing to be off-topic. Especially since I am still in the end working in
pure C++. Just not very pretty C++. I am carefully crafting the post that I
will make to comp.std.c++.

http://www.artima.com/intv/modern.html
"Bjarne Stroustrup: I had a lot of problems explaining that to people and
never quite understood why it was hard to understand. From the first days
of C++, there were classes with data and classes without data. The emphasis
in the old days was building up from a root with stuff in it, but there
were always abstract base classes. In the mid to late eighties, they were
commonly called ABCs (Abstract Base Classes): classes that consisted only
of virtual functions. In 1987, I supported pure interfaces directly in C++
by saying a class is abstract if it has a pure virtual function, which is a
function that must be overridden. Since then I have consistently pointed
out that one of the major ways of writing classes in C++ is without any
state, that is, just an interface.

"From a C++ view there's no difference between an abstract class and an
interface. Sometimes we use the phrase "pure abstract class," meaning a
class that exclusively has pure virtual functions (and no data). It is the
most common kind of abstract class. When I tried to explain this I found I
couldn't effectively get the idea across until I introduced direct language
support in the form of pure virtual functions. Since people could put data
in the base classes, they sort of felt obliged to do so. People built the
classic brittle base classes and got the classic brittle base class
problems, and I couldn't understand why people were doing it. When I tried
to teach the idea with abstract base classes directly supported in C++, I
had more luck, but many people still didn't get it. I think it was a major
failure in education on my part. I didn't imagine the problem well. That
actually matches some of the early failures of the Simula community to get
crucial new ideas across. Some new ideas are hard to get across, and part
of the problem is a lot of people don't want to learn something genuinly
new. They think they know the answer. And once we think we know the answer,
it's very hard to learn something new. Abstract classes were described,
with several examples, in The C++ Programming Language, Second Edition, in
1991, but unfortunately not used systematically throughout the book."

This demonstrates a problem of multiple meanings associated of the word
interface. I am not saying that Dr. Stroustrup is incorrect, but that I am
using the more concerete defintion of interface as per what we are seeing in
Java. My definition of interface is similar to but not congruent with pure
abstract base classes. I am using the Java definition that an interface type
as a reference to an object which provides implementations for a given set
of functions. Pure Abstract Base Classes are based on the notion of virtual
functions which are not neccessary for implementing interfaces. The other
alternative to the notions of interface which I am trying to promote is that
we could formalize the notion of a Pure Abstract Base Class as a separate
construct rather than an instance of use of inheritable classes with virtual
functions.

 

[Steven T. Hatton]

You still don't realize that people DO reexamine their accepted notions.

You are making a lot of assumptions as to what I actually meant. It would
appear you took this personally.

Your problem is that they don't do it on your schedule and on your terms.

More assumptions about what I was saying.

I 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.

And when I see a situation such as that, I typically refer the person to the
original discussion, or take a bit of time to explain why I believe the
issue has been resolved.

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.

The guy asked for a bit of feedback on the idea. How is he to know it's
already been tried, if indeed it has?

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.

[this response intentionally left blank.]

Either way, trying to
reason with such a person is essentially a waste of time,

How would you know?

The same applied when you proposed adding IDE functionality
to the language standard or

I'm not certain I ever actually proposed that. What I proposed was
providing some kind of standardized library for the support of basic IDE
functionality. I /have/ on comp.std.c++ proposed that IDE support be a
fromal consideration when designing the language.

when Julie proposed turning C++ source code into a database.

In some ways that is actually a fairly common practice. What I found
astounding was the extreme reaction you had to the proposition. It's
actually not a new idea, and it may well be what the future holds.

I've seen exceptionally bright people lose their jobs because they
couldn't let go of a losing crusade.

Some people have even died defending ideas that others rejected. That
doesn't mean their ideas were wrong.

 

[christopher diggins]

[snip]

Still blown away that no-one else has commented on
my posts.

Did you stop to think that maybe no one else found the idea interesting? We
get "mind blowing revelations" every other week and suggestions to change
the language even more often. By now, it's lucky if a prophetic posting gets
a yawn.

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. I am just afraid that somehow what I have
been doing is being dismissed without even being looked at seriously. How
can I make my work stand out from the other unresearched, untested and
undemonstrated crud that other people flood the newgroups with?

Relevance?

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. The C++ example using Abstract Base Classes is at:
http://www.heron-language.com/abc-example.html and the comparable example
using interfaces is at: http://www.heron-language.com/hfront-example.html .
The code that demonstrates these huge performance advantages is available at
http://www.heron-language.com/hfront.zip

Claudio Puviani

Thanks for your eye-opening comments Claudio.

 

[Steven T. Hatton]

I just came across these comments by Stroustrup, and found them
interesting in light of your suggestions.

[snip]

Those are very interesting comments and I appreciate you digging them up.
What I did on my web page ( http://www.heron-language.com/heronfront.html
) was demonstrate that using ABC's like Interfaces in C++ introduces
really nasty code bloat, for example the Int class with 32 bytes because
it inherits from multiple base classes instead of simply 4 bytes which is
all that is really needed.

I'll have to take your word for it at this point. I hope someone more
qualified than I am will find the time to examine your materials and
provide constructive feedback.

I didn't take your suggestion that way at all. I too do not consider what
I am doing to be off-topic. Especially since I am still in the end working
in pure C++. Just not very pretty C++. I am carefully crafting the post
that I will make to comp.std.c++.

There are some pretty well know C++ vets participating there. Hopefully
they can constructively assess your work.

http://www.artima.com/intv/modern.html
"Bjarne Stroustrup: I had a lot of problems explaining that to people and [snip]
it's very hard to learn something new. Abstract classes were described,
with several examples, in The C++ Programming Language, Second Edition,
in 1991, but unfortunately not used systematically throughout the book."

This demonstrates a problem of multiple meanings associated of the word
interface. I am not saying that Dr. Stroustrup is incorrect, but that I am
using the more concerete defintion of interface as per what we are seeing
in Java. My definition of interface is similar to but not congruent with
pure abstract base classes.

I will agree that what Stroustrup seems to be calling an interface is more
akin to an abstract class in Java. What I consider to be the analog of a
Java interface in C++ is a class with all methods defined as pure virtual.

I am using the Java definition that an
interface type as a reference to an object which provides implementations
for a given set of functions. Pure Abstract Base Classes are based on the
notion of virtual functions which are not neccessary for implementing
interfaces.

Can you point me to the 'executive summary' describing the alternative?

The other alternative to the notions of interface which I am
trying to promote is that we could formalize the notion of a Pure Abstract
Base Class as a separate construct rather than an instance of use of
inheritable classes with virtual functions.

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/?

 

[Claudio Puviani]

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.

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?

I am just afraid that somehow what I have been doing is
being dismissed without even being looked at seriously.

I've gone through your web site and looked at the examples and the proposed
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.

How can I make my work stand out from the other
unresearched, untested and undemonstrated crud that
other people flood the newgroups with?

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. 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 is
bad, the fanfare is just a nail in its coffin.

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.

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 in
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. This
would have value and would elicit interest, if not necessarily agreement. A
ridiculous example isn't worth anyone's time.

Claudio Puviani

 

[Claudio Puviani]

You are making a lot of assumptions as to what I
actually meant.

I base this on your repetitive patterns of translating other people's
disagreement into persecution and universal misunderstanding.

It would appear you took this personally.

Not at all. I've seen you act that way with anyone who doesn't look
favorably on your various little ideas.

More assumptions about what I was saying.

More conclusions from your consistent behavior.

And when I see a situation such as that, I typically refer
the person to the original discussion, or take a bit of time
to explain why I believe the issue has been resolved.

Good for you. I'm sure that this will become very helpful once you have
something meaningful to say. I, for one, have no interest in becoming an
educator and easily give up on amateurs who presume to argue with experts. I
completely fail to see the logic in seeking an expert's advice or comments
only to argue with them afterward.

he looked at acircle and claims to be the genius who invented
the wheel.

The guy asked for a bit of feedback on the idea.

It wasn't presented as "I have an idea, am I on the right track?" It was
presented as "the language should be changed and my idea should be made a
standard." I suspect that the reason this was greeted with silence rather
than scathing rebuttals is that he was very polite about it.

How is he to know it's already been tried, if indeed it has?

He could have asked a question: "Is there a known solutions to problem XYZ?"

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.

[this response intentionally left blank.]

Either way, trying to reason with such a person is essentially
a waste of time,

How would you know?

It's been tried many times. You're a prime example.

I'm not certain I ever actually proposed that. What I proposed
was providing some kind of standardized library for the support
of basic IDE functionality.

And how is this any different from what I said?

I /have/ on comp.std.c++ proposed that IDE support be a
fromal consideration when designing the language.

Which I'm sure set quite a few people laughing. They're just more
politically correct than we are and will laugh behind your back rather than
to your face.

In some ways that is actually a fairly common practice.

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.

What I found astounding was the extreme reaction you had to
the proposition.

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.

It's actually not a new idea,

It's an old idea that never took hold because it's a bad idea.

and it may well be what the future holds.

Wait until you actually have experience in C++ before making predictions.
This is another of your tendencies that have resulted in many of your posts
being viewed as noise.

Some people have even died defending ideas that others rejected.
That doesn't mean their ideas were wrong.

This isn't political science or philosophy. Technical merit tends to be
fairly objective and amateurs or beginners simply don't have the same voice
as seasoned professionals. Someone of average intelligence would quickly
note that these debates are almost always polarized along the axis of
experience and infer something from it.

Claudio Puviani

 

[Steven T. Hatton]

It's been tried many times. You're a prime example.

That merely begs the question.

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.

No. That isn't how I understood what she said. I took it more as proposing
the translation units would be treated as complete units when being
modified and stored. I don't believe she was actually proposing any
modification to the language.

It's an old idea that never took hold because it's a bad idea.

Or the technology was lacking to implement it.

Wait until you actually have experience in C++ before making predictions.
This is another of your tendencies that have resulted in many of your
posts being viewed as noise.

My professional experience with digital technology goes back to 1979. I have
worked with many programming languages, and have studied the underlying
concepts. There are certain abstract ideas which apply to all of them.

This isn't political science or philosophy. Technical merit tends to be
fairly objective and amateurs or beginners simply don't have the same
voice as seasoned professionals.

Interestingly, that is not what I've been observing on comp.std.c++.

 

[christopher diggins]

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. I
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 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.

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.

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.

I am not one of these people.

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.

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

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.

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.

The same applied
when you proposed adding IDE functionality to the language standard or when
Julie proposed turning C++ source code into a database.

Please don't take this thread as an oportunity to launch an attack against
another of our colleagues.

It's not the world
that's oblivious to your genius or that refuses to open its collective mind
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 on
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

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]

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?

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.

I've gone through your web site and looked at the examples and the proposed
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.

I assume you mean the solution that we should not use multiple base classes
in lightweight classes?

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.

That is a very good point.

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 is
bad, the fanfare is just a nail in its coffin.
Noted.


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 in
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. This
would have value and would elicit interest, if not necessarily agreement. A
ridiculous example isn't worth anyone's time.

Claudio Puviani

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]

I'm not really sure how to persuade people to reexamine their accepted
notions. One factor is probably important in any such endeavor. People have
to believe there is a significant problem that your proposal addresses.
I'm not well versed enough on the relevant issues to evaluate the competing
assertions regarding the cost of using (pure) virtual functions. I see you
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 Ed.
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?p=0878917489&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 as
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. I'm
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.

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\hfront-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]

christopher diggins wrote:
[snip]

I am using the Java definition that an
interface type as a reference to an object which provides implementations
for a given set of functions. Pure Abstract Base Classes are based on the
notion of virtual functions which are not neccessary for implementing
interfaces.

Can you point me to the 'executive summary' describing the alternative?

Could you explain what you mean by that?

This statement is false. I wish to retract it. HeronFront interfaces are not
virtual.

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/?

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]

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

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.