473,322 Members | 1,690 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

High performance alternative to MI of virtual bases

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
Jul 22 '05
62 3286
"Julie" <ju***@nospam.com> wrote
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.
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.


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
Jul 22 '05 #51
christopher diggins wrote:

"Claudio Puviani" <pu*****@hotmail.com> wrote in message
news:59*********************@news4.srv.hcvlny.cv.n et... [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.
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?


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


"People quite correctly say that you don't need multiple inheritance,
because anything you can do with multiple inheritance you can also do with
single inheritance. You just use the delegation trick I mentioned.
Furthermore, you don't need any inheritance at all, because anything you do
with single inheritance you can also do without inheritance by forwarding
through a class. Actually, you don't need any classes either, because you
can do it all with pointers and data structures." - Bjarne Stroustrup
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #52
christopher diggins wrote:

"Claudio Puviani" <pu*****@hotmail.com> wrote in message
news:59*********************@news4.srv.hcvlny.cv.n et... [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.
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?


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


"People quite correctly say that you don't need multiple inheritance,
because anything you can do with multiple inheritance you can also do with
single inheritance. You just use the delegation trick I mentioned.
Furthermore, you don't need any inheritance at all, because anything you do
with single inheritance you can also do without inheritance by forwarding
through a class. Actually, you don't need any classes either, because you
can do it all with pointers and data structures." - Bjarne Stroustrup
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #53
Claudio Puviani wrote:
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.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #54
Claudio Puviani wrote:
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.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #55
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote
Claudio Puviani wrote:
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.


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
Jul 22 '05 #56
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote
Claudio Puviani wrote:
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.


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
Jul 22 '05 #57
Claudio Puviani wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote
Claudio Puviani wrote:
> 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.


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.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #58
Claudio Puviani wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote
Claudio Puviani wrote:
> 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.


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.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #59
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote
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
Jul 22 '05 #60
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote
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
Jul 22 '05 #61
christopher diggins wrote:
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
}

Jul 22 '05 #62
christopher diggins wrote:
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
}

Jul 22 '05 #63

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

62
by: christopher diggins | last post by:
Since nobody responded to my earlier post , 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...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.