High performance alternative to MI of virtual bases

Discussion in 'C++' started by christopher diggins, Apr 6, 2004.

  1. 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!

    --
    Christopher Diggins - http://www.cdiggins.com
    designer of Heron - http://www.heron-language.com
     
    christopher diggins, Apr 6, 2004
    #1
    1. Advertising

  2. christopher diggins wrote:

    > 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++?
    --
    p->m == (*p).m == p[0].m
    http://www.kdevelop.org
    http://www.suse.com
    http://www.mozilla.org
     
    Steven T. Hatton, Apr 6, 2004
    #2
    1. Advertising

  3. christopher diggins wrote:

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


    --
    p->m == (*p).m == p[0].m
    http://www.kdevelop.org
    http://www.suse.com
    http://www.mozilla.org
     
    Steven T. Hatton, Apr 8, 2004
    #3
  4. "Steven T. Hatton" <> wrote in message
    news:D...
    > christopher diggins wrote:
    >
    > > 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?

    --
    Christopher Diggins
    http://www.cdiggins.com
    http://www.heron-language.com
     
    christopher diggins, Apr 8, 2004
    #4
  5. "christopher diggins" <> wrote
    >
    > [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
     
    Claudio Puviani, Apr 8, 2004
    #5
  6. christopher diggins wrote:

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

    --
    p->m == (*p).m == p[0].m
    http://www.kdevelop.org
    http://www.suse.com
    http://www.mozilla.org
     
    Steven T. Hatton, Apr 8, 2004
    #6
  7. "Steven T. Hatton" <> wrote
    >
    > 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
     
    Claudio Puviani, Apr 8, 2004
    #7
  8. christopher diggins wrote:

    >
    > 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
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Apr 8, 2004
    #8
  9. "Steven T. Hatton" <> wrote in message
    news:...
    >
    > 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.

    --
    Christopher Diggins
    http://www.cdiggins.com
    http://www.heron-language.com
     
    christopher diggins, Apr 8, 2004
    #9
  10. Claudio Puviani wrote:

    > "Steven T. Hatton" <> wrote
    >>
    >> 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.


    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.

    --
    p->m == (*p).m == p[0].m
    http://www.kdevelop.org
    http://www.suse.com
    http://www.mozilla.org
     
    Steven T. Hatton, Apr 8, 2004
    #10
  11. "Claudio Puviani" <> wrote in message
    news:45fdc.14269$...
    > "christopher diggins" <> wrote
    > >
    > > [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?

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

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

    --
    Christopher Diggins
    http://www.cdiggins.com
    http://www.heron-language.com
     
    christopher diggins, Apr 8, 2004
    #11
  12. christopher diggins wrote:

    > "Steven T. Hatton" <> wrote in message
    > news:...
    >>
    >> 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/?


    --
    p->m == (*p).m == p[0].m
    http://www.kdevelop.org
    http://www.suse.com
    http://www.mozilla.org
     
    Steven T. Hatton, Apr 8, 2004
    #12
  13. "christopher diggins" <> wrote
    >
    > 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, Apr 8, 2004
    #13
  14. "Steven T. Hatton" <> wrote
    > Claudio Puviani wrote:
    >
    > > "Steven T. Hatton" <> wrote
    > >>
    > >> 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.

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

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

    >
    > More assumptions about what I was saying.


    More conclusions from your consistent behavior.

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


    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.

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

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


    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.

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

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

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


    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
     
    Claudio Puviani, Apr 8, 2004
    #14
  15. Claudio Puviani wrote:

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


    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.
    >
    >> and it may well be what the future holds.


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

    --
    p->m == (*p).m == p[0].m
    http://www.kdevelop.org
    http://www.suse.com
    http://www.mozilla.org
     
    Steven T. Hatton, Apr 8, 2004
    #15
  16. "Claudio Puviani" <> wrote in message
    news:WRfdc.14680$...
    > "Steven T. Hatton" <> wrote
    > >
    > > 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.


    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.

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


    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
    http://www.cdiggins.com
    http://www.heron-language.com
     
    christopher diggins, Apr 8, 2004
    #16
  17. "Claudio Puviani" <> wrote in message
    news:n5hdc.15902$...
    > "christopher diggins" <> wrote
    > >
    > > 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 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 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.


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

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


    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.

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


    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, Apr 8, 2004
    #17
  18. "Steven T. Hatton" <> wrote in message
    news:...
    > christopher diggins wrote:
    >
    > > 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.


    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
    http://www.cdiggins.com
    http://www.heron-language.com
     
    christopher diggins, Apr 8, 2004
    #18
  19. "Steven T. Hatton" <> wrote in message
    news:...
    > 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?

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


    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
    http://www.cdiggins.com
    http://www.heron-language.com
     
    christopher diggins, Apr 8, 2004
    #19
  20. "Kevin Goodsell" <> wrote in message
    news:c5gdc.1353$...
    > christopher diggins wrote:
    >
    > >
    > > 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


    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, Apr 8, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ! aaa
    Replies:
    1
    Views:
    1,105
    ! aaa
    May 28, 2004
  2. news

    Help with data bases

    news, Nov 14, 2003, in forum: HTML
    Replies:
    4
    Views:
    445
  3. Jim Fischer
    Replies:
    3
    Views:
    455
    Jim Fischer
    Jul 31, 2003
  4. Dave Theese

    Initialization of virtual bases

    Dave Theese, Aug 24, 2003, in forum: C++
    Replies:
    1
    Views:
    339
    John Harrison
    Aug 24, 2003
  5. Replies:
    14
    Views:
    1,267
    Joe Kesselman
    Nov 25, 2006
Loading...

Share This Page