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/

[Alf P. Steinbach]

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

Care to post something that's possible to understand /from the text in
the posting/?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Jim Langston]

"Steven T. Hatton" <ch********@ger mania.supwrote in message
news:ZZ******** *************** *******@speakea sy.net...

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

The link you gave is talking about some syncronized color class. I don't
see call() and/or return() in it anywhere.

Your post is confused. Wanna try again?

[Steven T. Hatton]

Alf P. Steinbach wrote:

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

Care to post something that's possible to understand /from the text in
the posting/?

<quote url="http://www.gotw.ca/publications/c_family_interv iew.htm">
Q: Did you ever add features that your users didn't appreciate as much as
you did, and then have to deprecate or remove them later? What did you
learn from the experience?

Ritchie: I added some things under some pressure from users that I don't
think were done well. Enumeration types are a bit odd, bitfields are odder.
The "static" keyword is very strange, expressing both a storage lifetime
and what the standard calls "linkage" (external visibility). There are many
odd bits here and there.

I can't remember features I added that I had to remove except for some tiny
bits, like the "entry" keyword.

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

[Ian Collins]

Steven T. Hatton wrote:

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.

What aspect to you find baffling, the concept or the usefulness? The
concept does appear to be redundant if one uses RAII.

--
Ian Collins.

[Steven T. Hatton]

Ian Collins wrote:

Steven T. Hatton wrote:

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

What aspect to you find baffling, the concept or the usefulness? The
concept does appear to be redundant if one uses RAII.

Hu? How are you going to synchronize on a host class using RAII as simply as
using the call() and return() functions which we don't have?

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

[Ian Collins]

Steven T. Hatton wrote:

Ian Collins wrote:

>>Steven T. Hatton wrote:

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

What aspect to you find baffling, the concept or the usefulness? The
concept does appear to be redundant if one uses RAII.

Hu? How are you going to synchronize on a host class using RAII as simply as
using the call() and return() functions which we don't have?

"The call()/return() mechanism was meant to allow a programmer to manage
resources needed for an individual member function invocation."

Says nothing about synchronising the host class.

From the example, a lock object constructor could either be passed a
lock, or the object could be a friend of the host class and (by passing
a reference to the host class) use the class's lock that way.

--
Ian Collins.

[Steven T. Hatton]

Ian Collins wrote:

Steven T. Hatton wrote:

>Ian Collins wrote:

>>>Steven T. Hatton wrote:

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
programme r to manage resources needed for an individual member function
invocatio n. 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.

What aspect to you find baffling, the concept or the usefulness? The
concept does appear to be redundant if one uses RAII.

Hu? How are you going to synchronize on a host class using RAII as simply
as using the call() and return() functions which we don't have?

"The call()/return() mechanism was meant to allow a programmer to manage
resources needed for an individual member function invocation."

Says nothing about synchronising the host class.

I didn't even need to get to the sentence explaining what they were used for
when I encountered the discussion. It was obvious.

"Curiously enough, the initial implementation of C with Classes contained a
feature that is not provided by C++, but is often requested. One could
define a function that would implicitly be called before every call of
every member function (except the constructor) and another that would be
called before every return from every member function(except the
destructor). They were called /call/ and /return/ functions. They were
used to provide synchronization for the monitor class in the original task
library[Stroustrup, 1980]"

From the example, a lock object constructor could either be passed a
lock, or the object could be a friend of the host class and (by passing
a reference to the host class) use the class's lock that way.

I have an object of type Lockable. Calling a function on that object
initially acquires a resource called a lock just before control enters the
body of the function. Just before the function returns the lock is
released. That is RAII. All I need to do to create a class with
synchronized member functions is to derive it from Lockable. None of the
member functions need to know a thing about locks.
--
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/

[IR]

Steven T. Hatton wrote:

Hu? How are you going to synchronize on a host class using RAII as
simply as using the call() and return() functions which we don't
have?

eg. with Stroustrup's Wrapper templates, which are his answer to the
lack of call() and return() in C++.

To my understanding, they have the same kind of limitations than the
original call()/return() but they are way more flexible and, more
importantly IMHO, non-intrusive.

http://www.research.att.com/~bs/wrapper.pdf
Cheers,
--
IR

[Steven T. Hatton]

IR wrote:

Steven T. Hatton wrote:

>Hu? How are you going to synchronize on a host class using RAII as
simply as using the call() and return() functions which we don't
have?

eg. with Stroustrup's Wrapper templates, which are his answer to the
lack of call() and return() in C++.

To my understanding, they have the same kind of limitations than the
original call()/return()

What that nobody understand their usefulness?

but they are way more flexible and, more
importantly IMHO, non-intrusive.

I don't get the obsession with being "non-intrusive" in C++. There are
times when it makes sense, but I've certainly encountered many times when
it is utterly nonsensical to insist that, for example, a reference counted
pointer be non-intrusive.

http://www.research.att.com/~bs/wrapper.pdf

They certainly don't suffer from the fault of elegant simplicity which
plague call() and return().
--
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/