High performance alternative to MI of virtual bases

[Claudio Puviani]

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.

I can see how you would have read that as refering to you, and I apologize
for not expressing this more clearly. The "hard-headed" attribute refers to
some people involved in a few prior unrelated "debates", not to you. You've
so far shown yourself to be open to dissenting views, even if you don't
ascribe to them.

I am not one of these people.

Clearly not, but the person I was addressing has an almost unwavering
pattern, which you'll soon observe if you read this newsgroup regularly.
It's in part because of a barage of senseless posts like his that legitimate
requests for review can sometimes be lumped in with the bad.

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.

I have nothing against interfaces in principle, but

Heavy use of MI is only "abuse" because the approach of
using ABC's to emulate interfaces is flawed.

Heavy use of MI is abuse for the same reasons that simple inheritance is
abused: incorrect modeling. Inheritance -- multiple or otherwise -- is meant
to model an IS-A relationship, not a LOOKS-LIKE or a BEHAVES-LIKE
relationship, which is what interfaces model. The great irony is that when a
system is modeled correctly, there is very little need for inheritance and
almost no need whatsoever for MI.

Interfaces _are_ an interesting paradigm, but they're not a C++ paradigm,
which is why this thread is off-topic in a newsgroup that's dedicated to the
use of the core standard C++ language... WITHOUT preprocessors to handle
language extensions. This applies to CORBA, ODMG, Heron, and any other
preprocessor, regardless of how useful it may or may not be. For the sake of
argument, let's say C++ would be better with interfaces. This would be the
wrong newsgroup to discuss that because this newsgroup's chosen topic is the
C++ language AS IT'S DEFINED IN THE STANDARD, not any theoretical
extensions.

Clearly, Heron, as a language is completely off-topic.

I wrote a bit more about this at:
http://www.heron-language.com/abc-iop.html


I assume the monstrosity you refer to is the HeronFront idea.

That's correct.

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.

This presumes two things: (1) that I -- or anyone else -- would be willing
to add yet another preprocessor to the build chain, which in my case is
absolutely false, and (2) that heavy use of multiple inheritance is
desirable, which almost every author and practitioner agrees is not the
case.

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

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

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.

Unfortunately for you, you don't own this thread. It's both ironic and
amusing that you would try to exclude someone from an off-topic thread.

Claudio Puviani

 

[Steven T. Hatton]

Could you explain what you mean by that?
This:

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

Thanks.

Can I assume the only difference between an ABC with all pure virtual member
functions and your interface is the "fat pointer" replacing the vtbl?

 

[Julie]

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

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 need to formally restructure the language, it can be kept intact. The
notion of a translation unit would need to be redefined (again, not formally,
just within the context of the storage subsystem).

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 an old idea that never took hold because it's a bad idea.

I know it isn't a new idea -- like I said, I know that IBM was working on some
form of this a long time ago (i.e. the early 90's). Why it didn't take, I
don't know. A lot of (good) ideas don't take for various reasons -- that
doesn't imply that it is a bad idea, though.

I'd *LOVE* to hear an objective examination of the idea, and its outcome
(positive or negative), however I've yet to run across anything other than what
has been 'discussed' about it in the ng recently.

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

 

[christopher diggins]

I can see how you would have read that as refering to you, and I apologize
for not expressing this more clearly. The "hard-headed" attribute refers to
some people involved in a few prior unrelated "debates", not to you. You've
so far shown yourself to be open to dissenting views, even if you don't
ascribe to them.

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

I have nothing against interfaces in principle, but


Heavy use of MI is abuse for the same reasons that simple inheritance is
abused: incorrect modeling. Inheritance -- multiple or otherwise -- is meant
to model an IS-A relationship, not a LOOKS-LIKE or a BEHAVES-LIKE
relationship, which is what interfaces model.

It is perhaps narrow to suggest that any usage of inheritance beyond
modeling IS-A relationships is incorrect. I will grant you that being
rigorous in this manner has advantages of consistency which can be
preferable in many scenarios. I believe there are valid scenarios when
inheritance is not just about modeling, sometimes it is just a practical
technique used to save coding and factor out common functionality. When you
refer to interfaces here, are you refering to Abstract Base Classes
performing as interfaces?

The great irony is that when a
system is modeled correctly, there is very little need for inheritance and
almost no need whatsoever for MI.

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

Interfaces _are_ an interesting paradigm, but they're not a C++ paradigm,

Using ABC's like interfaces to model BEHAVES-LIKE cases is a C++ paradigm.

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

Any suggestion where a more appropriate place to discuss extensions to the
standard? At the same time, the output of HeronFront could be argued to be
on-topic, because it is C++ as defined in the standard. I think really if
people like myself were silenced here, then you would be left with nothing
but a lot of "how do I do my homework posts".

Clearly, Heron, as a language is completely off-topic.

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

This presumes two things: (1) that I -- or anyone else -- would be willing
to add yet another preprocessor to the build chain, which in my case is
absolutely false, and (2) that heavy use of multiple inheritance is
desirable, which almost every author and practitioner agrees is not the
case.

I don't honestly expect many people to use (1), as I mentioned before it's
more of a proof of concept. Though interestingly enough, I could build a
very interesting library in standard C++ using HeronFront. So what are the
reasons behind (2)? Is it because heavy use of MI is inefficient? When
modeling behaves-like cases using ABC's, it makes sense that we use MI as
much as we need to, any limit on us using it would be purely implementation
imposed.

Unfortunately for you, you don't own this thread. It's both ironic and
amusing that you would try to exclude someone from an off-topic thread.

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

 

[christopher diggins]

Thanks.

Can I assume the only difference between an ABC with all pure virtual member
functions and your interface is the "fat pointer" replacing the vtbl?

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

Interface I {
void Fu();
};

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

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

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

Now here is the same code with a pure ABC:

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

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

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

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

 

[Claudio Puviani]

I don't know how I got dragged into this thread...

I missed you. ;-)

Since Godwin's law doesn't yet apply, I guess I'll clarify:

No need to formally restructure the language, it can be kept
intact. The notion of a translation unit would need to be
redefined (again, not formally, just within the context of the
storage subsystem).

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

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

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

// and later...

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

sc.someFunction();
soc.someOtherFunction();
}
catch (SomeClass::Exception & ex) {
// ...
}
catch (SomeOtherClass::Exception & ex) {
// ...
}
}

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

From a different agnle, like it or not, most programmers have a hefty
toolkit of perl, awk, sed, shell, yacc/lex, etc. scripts that they use to
process their source code because they take ADVANTAGE of the fact that the
source is stored in text files, as opposed to seeing it as a hindrance. This
is part of an existing C++ culture that isn't going away. It may increase
the learning curve for people new to the language, but no one will accept
features that help beginners to the detriment of those who are proficient in
the language and its vast existing base of tools. Saying that "people will
write new tools" just isn't acceptable. Even if the idea had merit, which is
a separate debate, there would me ZERO market for a change that would force
the established base of C++ developers to throw away tools, techniques, and
experience without there being replacements up front.

I know it isn't a new idea -- like I said, I know that IBM was working
on some form of this a long time ago (i.e. the early 90's).

I strongly doubt this was for C++.

Why it didn't take, I don't know.

Maybe it was for C++ after all. That would definitely explain its failure.

A lot of (good) ideas don't take for various reasons -- that
doesn't imply that it is a bad idea, though.

Ideas live in a context. Your idea, in a brand new language, might be
excellent. It could even be perfectly adaptable to some languages like
Pascal or Ada, and maybe even Java. In the context of C++ with its
established practices, tools, and idioms that depend on translation units
being text files, it makes no sense at all.

I'd *LOVE* to hear an objective examination of the idea,
and its outcome (positive or negative), however I've yet to
run across anything other than what has been 'discussed'
about it in the ng recently.

What's been discussed, and what I've repeated here, is objective AND
pragmatic. You can't choose to disregard real-world usage and consequences
to the developer base.

I'm not clinging to the idea, I just haven't heard anything
substantive that explains its inherent shortcomings (excepting
technological limitations).

It may not seem substantive to you because you haven't experienced the
environments that others and I have described. There are actually NO
technological limitations to storing source code in databases if the
language supports the model. C++ doesn't support the model. It's that
simple.

I'm not going to drop the idea, however, just over some flap
on a newsgroup.

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

Claudio Puviani

 

[Steven T. Hatton]

news:[email protected]... [snip]

It is perhaps narrow to suggest that any usage of inheritance beyond
modeling IS-A relationships is incorrect. I will grant you that being
rigorous in this manner has advantages of consistency which can be
preferable in many scenarios. I believe there are valid scenarios when
inheritance is not just about modeling, sometimes it is just a practical
technique used to save coding and factor out common functionality.

Stroustrup certainly doesn't limit classes to strictly 'is-a'
representations. In general it is reasonable to abstract out abilities such
as runable, serializable, resizeable, etc. These abstractions are good
candidates for interfaces, in either the pure ABC or HFront sense. Some
things that are treated as interfaces in Java are implemented using
templates in the STL. Of course much of STL can be diagrammed as an
inheritance hierarchy, at least conceptually.

Another significant role of an interface is to act as a contract.

When
you refer to interfaces here, are you refering to Abstract Base Classes
performing as interfaces?

I would really like to know what he intended. It's hard to know how we are
to understand his usage.

Any suggestion where a more appropriate place to discuss extensions to the
standard?

That is really something of a missunderstanding of the FAQ. People tend to
only read a few choice sections that are immediately appearant and neglect
to consider what the broader picture it represents is.

At the same time, the output of HeronFront could be argued to be
on-topic, because it is C++ as defined in the standard. I think really if
people like myself were silenced here, then you would be left with nothing
but a lot of "how do I do my homework posts".

Actually, I have the sense these restrictions people try to place on the
content of the newsgroup are rather harmful to C++.

I don't honestly expect many people to use (1), as I mentioned before it's
more of a proof of concept. Though interestingly enough, I could build a
very interesting library in standard C++ using HeronFront. So what are the
reasons behind (2)? Is it because heavy use of MI is inefficient? When
modeling behaves-like cases using ABC's, it makes sense that we use MI as
much as we need to, any limit on us using it would be purely
implementation imposed.

"People quite correctly say that you don't need multiple inheritance,
because anything you can do with multiple inheritance you can also do with
single inheritance. You just use the delegation trick I mentioned.
Furthermore, you don't need any inheritance at all, because anything you do
with single inheritance you can also do without inheritance by forwarding
through a class. Actually, you don't need any classes either, because you
can do it all with pointers and data structures." - Bjarne Stroustrup

 

[Steven T. Hatton]

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

I can refute the entire argument by simply and correctly stating that
implementations of existing XML standards can do that too.

 

[Claudio Puviani]

I can refute the entire argument by simply and correctly
stating that implementations of existing XML standards
can do that too.

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

Claudio Puviani

 

[Steven T. Hatton]

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

Claudio Puviani

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

 

[Claudio Puviani]

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

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

Claudio Puviani

 

[Mark A. Gibbs]

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

I'm hardly an expert on these topics, but i'm curious to know why
interfaces represent a more valid means of specifying generic behaviour
than template adaptors?

class NaiveInt
{
public:
// [snip]
void Assign(const NaiveInt& x) {
m = x.ToOrdinal();
}

int Compare(const NaiveInt& x) const {
return m - x.ToOrdinal();
}
// [snip]
};

template <typename T>
class IntInterface
{
public:
// [snip]
void Assign(const T& x) {
t_.Assign(x);
}

int Compare(const T& x) const {
return t_.Compare(x);
}
// [snip]
private:
T t_;
};

you could even specialize the IntInterface adaptor for anything that
does not have exact semantics, like the native int type(s).

template <typename T>
void SomeUsage(IntInterface<T> const& some_int)
{
// will work for any T that IntInterface is valid/specialized for
}