call() and return()

[Steven T. Hatton]

I just read §2.11.3 of D&E, and I have to say, I'm quite puzzled by what it
says.

http://java.sun.com/docs/books/tutor...y/syncrgb.html
<shrug>
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Steven T. Hatton wrote:

>>Back to the original topic. After having 25 years to reflect upon the
matter, do you believe omitting call() and return() from C++ was the
right _design_ choice?

Have you considered that if it were a big demand for that feature several
compilers were already implemented it as extension?

Perhaps, but how long did quaternions languish as an academic curiosity
before someone realize they had a use in 3D graphics?

I suppose that "someone" put his ideas at work, instead of telling other
people "I have an intuition about quaternions, the graphics library writers
must consider using it".

There are many good ideas sitting on bookshelves,

Yes, there are plenty of ideas, and people elaborate new ones every day.

I have to say, however, that my intuition is very strongly in favor of
their usefulness.

But is hard that other people start to work in that field just by your
intuition. People usually spend his time with his own intuitions and ideas.

--
Salu2

[Steven T. Hatton]

Julián Albo wrote:

Steven T. Hatton wrote:

>>>Back to the original topic. After having 25 years to reflect upon the
matter, do you believe omitting call() and return() from C++ was the
right _design_ choice?
Have you considered that if it were a big demand for that feature
several compilers were already implemented it as extension?

Perhaps, but how long did quaternions languish as an academic curiosity
before someone realize they had a use in 3D graphics?

I suppose that "someone" put his ideas at work, instead of telling other
people "I have an intuition about quaternions, the graphics library
writers must consider using it".

Someone did, well, in a sense. He wrote a book explaining the idea, and a
lot of other people used it.

>There are many good ideas sitting on bookshelves,

Yes, there are plenty of ideas, and people elaborate new ones every day.

>I have to say, however, that my intuition is very strongly in favor of
their usefulness.

But is hard that other people start to work in that field just by your
intuition. People usually spend his time with his own intuitions and
ideas.

As far as I know, there is only one person in the world who has hands-on
experience working with this design. I asked for his opinion. Not yours.

--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

[red floyd]

Steven T. Hatton wrote:

Perhaps, but how long did quaternions languish as an academic curiosity
before someone realize they had a use in 3D graphics? There are many good
ideas sitting on bookshelves, either waiting from someone to come along and
realize their value, or for someone who recognizes their value to gain the
skills and resources necessary to make use of them.

Quaternions have had a known use long before 3D graphics. They are used
in rocket and missile guidance algorithms.

[king]

Stroustrup: When I designed C with Classes and C++, I was very keen on the

idea that a class defined the environment in which the code of its member
functions operate (I still am). This led to the notion of constructors that
establish that environment (invariant) and acquire the resources needed.
Destructors reverse that process (releasing resources). These ideas are at
the root of the design of exceptions and resource management. For example,
see the new Appendix E: "Standard-Library Exception Safety" of The C++
Programming Language.[3] That appendix can be downloaded from my home
pages.[4]

Based on that line of thinking, C with Classes also allowed you to define a
call() function that was called before entry into a member function and a
return() function that was called after exit from a member function. The
call()/return() mechanism was meant to allow a programmer to manage
resources needed for an individual member function invocation. This allowed
me to implement monitors for the first task library. A task's call()
grabbed a lock and its matching return() released the lock. The idea came
partly from Lisp's :before and :after methods. However, the notion wasn't
perfectly general -- for example, you couldn't access arguments for a
member function call from call(). Worse, I completely failed to convince
people of the usefulness of this notion, so I removed call() and return()
when I defined C++.
</quote>

The last sentence is what has me baffled.

why do we need it as a standard mechanism? Cant we have the call to
call() at the begining of every member function and return() before
every return? May be something like
#define RETURN returnf(); return

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Steven T. Hatton wrote:

As far as I know, there is only one person in the world who has hands-on
experience working with this design. I asked for his opinion.

.... and ignored it.

--
Salu2

[Steven T. Hatton]

king wrote:

>Stroustrup: When I designed C with Classes and C++, I was very keen on
the idea that a class defined the environment in which the code of its
member functions operate (I still am). This led to the notion of
constructors that establish that environment (invariant) and acquire the
resources needed. Destructors reverse that process (releasing resources).
These ideas are at the root of the design of exceptions and resource
management. For example, see the new Appendix E: "Standard-Library
Exception Safety" of The C++ Programming Language.[3] That appendix can
be downloaded from my home pages.[4]

Based on that line of thinking, C with Classes also allowed you to define
a call() function that was called before entry into a member function and
a return() function that was called after exit from a member function.
The call()/return() mechanism was meant to allow a programmer to manage
resources needed for an individual member function invocation. This
allowed me to implement monitors for the first task library. A task's
call() grabbed a lock and its matching return() released the lock. The
idea came partly from Lisp's :before and :after methods. However, the
notion wasn't perfectly general -- for example, you couldn't access
arguments for a member function call from call(). Worse, I completely
failed to convince people of the usefulness of this notion, so I removed
call() and return() when I defined C++.
</quote>

The last sentence is what has me baffled.

why do we need it as a standard mechanism? Cant we have the call to
call() at the begining of every member function and return() before
every return? May be something like
#define RETURN returnf(); return

It may prove significant that call() is invoked _before_ the member
function, and that return() is invoked _after_ the return has completed.
I'm thinking in terms of synchronization points. Another issue would be
what to do about exceptions. I don't claim to be any kind of an expert on
this matter. I've very briefly looked at some discussions of how this is
used in CLOS. In that case there is at lease one other function
called "around" which seems to provide parameter interception. The part of
call/return that appealed to me was that it seems like a good way to
support concurrency.

I will note that there are very few references listed in the Java Language
Specification. Among them is the CLOS Specification. Only one author
appears with more than one title.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

[Pete Becker]

Steven T. Hatton wrote:

>
It may prove significant that call() is invoked _before_ the member
function, and that return() is invoked _after_ the return has completed.
I'm thinking in terms of synchronization points. Another issue would be
what to do about exceptions. I don't claim to be any kind of an expert on
this matter. I've very briefly looked at some discussions of how this is
used in CLOS. In that case there is at lease one other function
called "around" which seems to provide parameter interception. The part of
call/return that appealed to me was that it seems like a good way to
support concurrency.

You should look closely at Java's experience with synchronized methods.
Library designers have moved away from them, because the lock almost
always occurs too soon, killing performance. It's much better to defer
locking until you've finished some preliminaries, and possibly decided
that a lock isn't even needed.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

[Steven T. Hatton]

Pete Becker wrote:

Steven T. Hatton wrote:

>>
It may prove significant that call() is invoked _before_ the member
function, and that return() is invoked _after_ the return has completed.
I'm thinking in terms of synchronization points. Another issue would be
what to do about exceptions. I don't claim to be any kind of an expert
on
this matter. I've very briefly looked at some discussions of how this is
used in CLOS. In that case there is at lease one other function
called "around" which seems to provide parameter interception. The part
of call/return that appealed to me was that it seems like a good way to
support concurrency.

You should look closely at Java's experience with synchronized methods.
Library designers have moved away from them, because the lock almost
always occurs too soon, killing performance. It's much better to defer
locking until you've finished some preliminaries, and possibly decided
that a lock isn't even needed.

So I've read. So far the only difference between Java's threading and
threading in C++ that I've noticed is that I was able to make use of what
Java provides. Can you provide detailed information describing the adverse
impact of Java's threading model in typical applications? The only
hands-on experience I have with a functioning large-scale concurrent
application is the component that provides AKO (Army Knowledge Online) with
access to the US Army's personnel database. We used BEA WebLogic.

There are a lot of issues I have not been able to explore regarding
threading in C++. I'm suspicious of claims of significant performance
enhancements in the general case that require computing the need for
locking at runtime. You will need to pay for that computation somehow.

It's not clear to me whether a distinction between read locks and write
locks would be useful in concurrent programs. Java has no concept of
constness beyond immutability. That, in itself, suggests C++ could use the
same basic threading model and provide superior performance. There are
probably many cases in which the need for locking could be determined at
design time, or at compile time.

When all is said and done, it seems likely there will be a need to take
action "within" synchronization points.

--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

[wkaras]

Steven T. Hatton wrote:

wk****@yahoo.co m wrote:

Then I also missed the Socratic double irony, because I've heard
more than once the argument that C++ is a bad language because
it was devolped iteratively based on experience with practical
usage.

I don't believe I've ever made such a claim.

Sorry, I didn't mean to imply that you did. It did seem that you
were (seriously) saying that C++ was negatively impacted
because the designer thought that a strong consensus of expert
users trumphed his own intuition. (Hence the double irony if
you only meant it ironically.)

What is most evident to me
right now regarding the faults of C++ is not really inherent to the
language. When I first started trying to learn C++ I bought a copy of the
Standard. Many people told me that reading the Standard was the wrong way
to go about learning C++. My own experience tells me that it was somewhat
beneficial, but not completely effective.

Some of the observations I made back then were that the Standard lacked
clarity, that terms were not well defined and that some of the wording was
overly cleaver. I was told that the failing was on my part, and that the
Standard was written in highly specialized language only accessible to
experts.

http://groups.google.com/group/comp....836121a85f07b6

Well, mal de muchos, consuelo de tontos, but the C++ Standard is easier
to use than alot of the other technical standards I've had to deal
with. So
the problem is not specific to C++. And anyway, C++ was an important,
usable, and surprisingly portable language for many years before the
1998 Standard was issued.

[Steven T. Hatton]

wk****@yahoo.co m wrote:

>
Steven T. Hatton wrote:

>wk****@yahoo.co m wrote:

Then I also missed the Socratic double irony, because I've heard
more than once the argument that C++ is a bad language because
it was devolped iteratively based on experience with practical
usage.

I don't believe I've ever made such a claim.

Sorry, I didn't mean to imply that you did. It did seem that you
were (seriously) saying that C++ was negatively impacted
because the designer thought that a strong consensus of expert
users trumphed his own intuition. (Hence the double irony if
you only meant it ironically.)

My comment was "Bruno was burned at the stake, wasn't he?" If you find any
angle of irony in the various possible interpretations it was probably
intended.

>What is most evident to me
right now regarding the faults of C++ is not really inherent to the
language. When I first started trying to learn C++ I bought a copy of
the
Standard. Many people told me that reading the Standard was the wrong
way
to go about learning C++. My own experience tells me that it was
somewhat beneficial, but not completely effective.

Some of the observations I made back then were that the Standard lacked
clarity, that terms were not well defined and that some of the wording
was
overly cleaver. I was told that the failing was on my part, and that the
Standard was written in highly specialized language only accessible to
experts.

http://groups.google.com/group/comp....836121a85f07b6

>
Well, mal de muchos, consuelo de tontos, but the C++ Standard is easier
to use than alot of the other technical standards I've had to deal
with. So
the problem is not specific to C++. And anyway, C++ was an important,
usable, and surprisingly portable language for many years before the
1998 Standard was issued.

The wording of the C++ Standard could and should be better. A formal
glossary of terms will help the authors express their exact meanings more
effectively. It will help avoid ambiguities in the specification. It will
help implementers to correctly, consistently and efficiently write
compilers. It will make the language easier to teach and to learn. It will
facilitate adding or modifying features (in the _rare_ cases when that is
needed). It will help identify and eliminate design flaws. And most
importantly, it will make the language easier and more enjoyable to use.

IMO comparing C++ (or the Standard document) to other languages is less
beneficial in most cases than comparing it to its potential.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/