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 62  3293 
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
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
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
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" <su******@setidava.kushan.aa> wrote in message
news:Do********************@speakeasy.net... 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
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:Do********************@speakeasy.net... 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" <cd******@videotron.ca> 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
"christopher diggins" <cd******@videotron.ca> 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
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?...9&g=0878916849
Stroustrup seems to think the cost is minimal: http://www.research.att.com/~bs/crc.pdf
"A function declared in a derived class is said to override a virtual
function with the same name and type in a base class. It is the language s
job to ensure that calls of Character_ device s virtual functions, such 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
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?...9&g=0878916849
Stroustrup seems to think the cost is minimal: http://www.research.att.com/~bs/crc.pdf
"A function declared in a derived class is said to override a virtual
function with the same name and type in a base class. It is the language s
job to ensure that calls of Character_ device s virtual functions, such 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" <su******@setidava.kushan.aa> 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
"Steven T. Hatton" <su******@setidava.kushan.aa> 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
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.
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.
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:KI********************@speakeasy.net...
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
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:KI********************@speakeasy.net...
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
Claudio Puviani wrote: "Steven T. Hatton" <su******@setidava.kushan.aa> 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
Claudio Puviani wrote: "Steven T. Hatton" <su******@setidava.kushan.aa> 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
"Claudio Puviani" <pu*****@hotmail.com> wrote in message
news:45*********************@news4.srv.hcvlny.cv.n et... "christopher diggins" <cd******@videotron.ca> 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
"Claudio Puviani" <pu*****@hotmail.com> wrote in message
news:45*********************@news4.srv.hcvlny.cv.n et... "christopher diggins" <cd******@videotron.ca> 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 wrote: "Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:KI********************@speakeasy.net...
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
christopher diggins wrote: "Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:KI********************@speakeasy.net...
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
"christopher diggins" <cd******@videotron.ca> 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
"christopher diggins" <cd******@videotron.ca> 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
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote Claudio Puviani wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> 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
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote Claudio Puviani wrote:
"Steven T. Hatton" <su******@setidava.kushan.aa> 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 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
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
"Claudio Puviani" <pu*****@hotmail.com> wrote in message
news:WR*********************@news4.srv.hcvlny.cv.n et... "Steven T. Hatton" <su******@setidava.kushan.aa> 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
"Claudio Puviani" <pu*****@hotmail.com> wrote in message
news:WR*********************@news4.srv.hcvlny.cv.n et... "Steven T. Hatton" <su******@setidava.kushan.aa> 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
"Claudio Puviani" <pu*****@hotmail.com> wrote in message
news:n5*********************@news4.srv.hcvlny.cv.n et... "christopher diggins" <cd******@videotron.ca> 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
"Claudio Puviani" <pu*****@hotmail.com> wrote in message
news:n5*********************@news4.srv.hcvlny.cv.n et... "christopher diggins" <cd******@videotron.ca> 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
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:bI********************@speakeasy.net... 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?...9&g=0878916849
Stroustrup seems to think the cost is minimal:
http://www.research.att.com/~bs/crc.pdf
"A function declared in a derived class is said to override a virtual
function with the same name and type in a base class. It is the language s
job to ensure that calls of Character_ device s virtual functions, such
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
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:bI********************@speakeasy.net... 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?...9&g=0878916849
Stroustrup seems to think the cost is minimal:
http://www.research.att.com/~bs/crc.pdf
"A function declared in a derived class is said to override a virtual
function with the same name and type in a base class. It is the language s
job to ensure that calls of Character_ device s virtual functions, such
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
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:rZ********************@speakeasy.net... 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
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:rZ********************@speakeasy.net... 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
"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:c5*****************@newsread2.news.pas.earthl ink.net... 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
"Kevin Goodsell" <us*********************@neverbox.com> wrote in message
news:c5*****************@newsread2.news.pas.earthl ink.net... 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" <cd******@videotron.ca> wrote "Claudio Puviani" <pu*****@hotmail.com> wrote 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.
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.
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.
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.
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.
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
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.
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.
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.
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
"christopher diggins" <cd******@videotron.ca> wrote "Claudio Puviani" <pu*****@hotmail.com> wrote 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.
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.
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.
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.
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.
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
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.
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.
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.
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
I don't know how I got dragged into this thread... Since Godwin's law doesn't
yet apply, I guess I'll clarify:
Claudio Puviani wrote: 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.
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). 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). 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.
I don't know how I got dragged into this thread... Since Godwin's law doesn't
yet apply, I guess I'll clarify:
Claudio Puviani wrote: 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.
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). 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). 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.
"Claudio Puviani" <pu*****@hotmail.com> wrote in message
news:59*********************@news4.srv.hcvlny.cv.n et... "christopher diggins" <cd******@videotron.ca> wrote
<snip> 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 pleased to hear that, and I apologize for having taken offence to
something not aimed at me.
<snip> 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.
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.
<snip> 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.
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.
<snip> 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 http://www.cdiggins.com http://www.heron-language.com
"Claudio Puviani" <pu*****@hotmail.com> wrote in message
news:59*********************@news4.srv.hcvlny.cv.n et... "christopher diggins" <cd******@videotron.ca> wrote
<snip> 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 pleased to hear that, and I apologize for having taken offence to
something not aimed at me.
<snip> 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.
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.
<snip> 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.
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.
<snip> 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 http://www.cdiggins.com http://www.heron-language.com
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:E5********************@speakeasy.net... christopher diggins wrote:
Can you point me to the 'executive summary' describing the alternative?
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?
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"
}
--
Christopher Diggins http://www.cdiggins.com http://www.heron-language.com
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:E5********************@speakeasy.net... christopher diggins wrote:
Can you point me to the 'executive summary' describing the alternative?
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?
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"
}
--
Christopher Diggins http://www.cdiggins.com http://www.heron-language.com
"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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
| |
