By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,900 Members | 1,364 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,900 IT Pros & Developers. It's quick & easy.

call() and return()

P: n/a
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/
Dec 15 '06 #1
Share this Question
Share on Google+
46 Replies


P: n/a
* 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?
Dec 15 '06 #2

P: n/a
"Steven T. Hatton" <ch********@germania.supwrote in message
news:ZZ******************************@speakeasy.ne t...
>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?
Dec 15 '06 #3

P: n/a
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_interview.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/
Dec 15 '06 #4

P: n/a
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.
Dec 15 '06 #5

P: n/a
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/
Dec 16 '06 #6

P: n/a
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.
Dec 16 '06 #7

P: n/a
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
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.
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/
Dec 16 '06 #8

P: n/a
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
Dec 16 '06 #9

P: n/a
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/
Dec 16 '06 #10

P: n/a
IR
Steven T. Hatton wrote:
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?
Mind you, I was not saying the concept is useless. I was only
pointing out that there are the same limitations in both approaches,
ie. the inability to know which function is being called or to
examine the function's parameters / return value in the prefix and
suffix.

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

I don't get the obsession with being "non-intrusive" in C++.
The short answer is: decoupling.

Now for the long answer...

Just as an example, say you have a synchronized message class which
objects wander around in various parts of a multithreaded
application.

Part of the time, you'll need the locking to take place on every
function call. But there are also places where you won't want to
incur the cost of a lock, when you know it's safe to avoid it.

How could you ever achieve that if your locking mechanism is cast in
the concrete of a base class?
Unless of course you add some switch to the base class so that you
can enable/disable locking at will, which I wouldn't really call
elegant, simple, or even robust.

Stroustrup's wrappers allow that easily, due to their "non-
intrusiveness". Moreover, you can easily stack various wrappers, use
them with existing classes which were not designed for this purpose,
or also enforce compile time checking of the variable behaviour.

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.
I agree on the reference counting example. There are many cases when
a class' objects will be used only through reference counting. In
this case intrusive methods are fine by me.
But if some instances of that same class ever need to be used
without reference counting, the cleanest solution is often to "fall
back" to non-intrusive methods IMHO.

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

They certainly don't suffer from the fault of elegant simplicity
which plague call() and return().
As far as I'm concerned, the gain in flexibility largely outweights
the small syntactic price. But YMMV.
Anyway, that's not like if we had the choice. ;-)
Cheers,
--
IR
Dec 16 '06 #11

P: n/a

Steven T. Hatton wrote:>
<quote>
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.
I explained the idea to very competent people, I made the facility
available for a year. Nobody agreed that there was a need and nobody
used what was made available. I concluded that there was a high
propability that there was a flaw in the analysis that led me to
introduce the feature or in my design. Basically, the odds were that
"they" were right.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Dec 16 '06 #12

P: n/a
* bjarne:
Steven T. Hatton wrote:>
><quote>
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.

I explained the idea to very competent people, I made the facility
available for a year. Nobody agreed that there was a need and nobody
used what was made available. I concluded that there was a high
propability that there was a flaw in the analysis that led me to
introduce the feature or in my design. Basically, the odds were that
"they" were right.
Ah, but now, or mid-1990's, "they" have invented aspect-oriented
programming, but mostly based on preprocessing C++ source code:

<url: http://en.wikipedia.org/wiki/Aspect-oriented_programming>
<url: http://wwwiti.cs.uni-magdeburg.de/iti_db/forschung/fop/featurec/>
<url: http://www.aspectc.org/>

Etc.

There is an interesting aspect (yeah) that is easily overlooked in all
this preprocessing mania, namely that the Evil Empire (a.k.a. Microsoft)
did this first and last for C++, at least as I recall it.

First, with the "COM interceptor" for C++ classes conforming to COM
binary object layout, with run-time interception of member function
calls, and last with the AFAIK largely undocumented .NET proxy
technology, which applies to any .NET language and therefore also C++
under .NET, again with run-time interception.

From my point of view that's much more interesting than preprocessing,
because it allows for instrumenting already compiled code.

But it requires a well-defined ABI, at least for each platform, the same
as (I think) introspection does.

So, is there any chance of introspection in C++09, and if so, is there
any chance of support for "real" aspect-oriented programming?

--
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?
Dec 16 '06 #13

P: n/a
bjarne wrote:
>
Steven T. Hatton wrote:>
><quote>
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.

I explained the idea to very competent people, I made the facility
available for a year. Nobody agreed that there was a need and nobody
used what was made available. I concluded that there was a high
propability that there was a flaw in the analysis that led me to
introduce the feature or in my design. Basically, the odds were that
"they" were right.

-- Bjarne Stroustrup; http://www.research.att.com/~bs
Bruno was burned at the stake, wasn't he?

"It is proof of a base and low mind for one to wish to think with the masses
or majority, merely because the majority is the majority. Truth does not
change because it is, or is not, believed by a majority of the people."
Giordano Bruno
--
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/
Dec 16 '06 #14

P: n/a

Steven T. Hatton wrote:
bjarne wrote:

Steven T. Hatton wrote:>
<quote>
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.
I explained the idea to very competent people, I made the facility
available for a year. Nobody agreed that there was a need and nobody
used what was made available. I concluded that there was a high
propability that there was a flaw in the analysis that led me to
introduce the feature or in my design. Basically, the odds were that
"they" were right.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Bruno was burned at the stake, wasn't he?

"It is proof of a base and low mind for one to wish to think with the masses
or majority, merely because the majority is the majority. Truth does not
change because it is, or is not, believed by a majority of the people."
Giordano Bruno
--
but something is not true just because someone believe it.

If my arguments are not sufficient to convince reasonable and
experienced people it behooves me to take that into account when I try
to estimate the likely costs and benefits of a feature. Anything else
would be simple pigheadedness or arrogance.

In the case of call() and return(), there was also problems about lack
of access to the arguments of a function; they could not implement
every desired use case of interception and forwarding (e.g. check
argument foreard then check return value).

Also, given a fixed amount of time and effort, there are also a choice
of features to introduce. What would you have liked to give up to get
call() and return()?

There is one prominent example where I did go against uniform negative
local feedback: virtual functions. Had I listened to my reasonable and
experienced colleagues, you wouldn't have had them in C++ - and you
probably would never have heard of C++.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Dec 16 '06 #15

P: n/a
bjarne wrote:
>
Steven T. Hatton wrote:
>bjarne wrote:
>
Steven T. Hatton wrote:>

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

I explained the idea to very competent people, I made the facility
available for a year. Nobody agreed that there was a need and nobody
used what was made available. I concluded that there was a high
propability that there was a flaw in the analysis that led me to
introduce the feature or in my design. Basically, the odds were that
"they" were right.

-- Bjarne Stroustrup; http://www.research.att.com/~bs

Bruno was burned at the stake, wasn't he?

"It is proof of a base and low mind for one to wish to think with the
masses or majority, merely because the majority is the majority. Truth
does not change because it is, or is not, believed by a majority of the
people." Giordano Bruno
--

but something is not true just because someone believe it.
Perhaps that's a matter of opinion, eh?
If my arguments are not sufficient to convince reasonable and
experienced people it behooves me to take that into account when I try
to estimate the likely costs and benefits of a feature. Anything else
would be simple pigheadedness or arrogance.
Or perhaps merely counterproductive.
In the case of call() and return(), there was also problems about lack
of access to the arguments of a function; they could not implement
every desired use case of interception and forwarding (e.g. check
argument foreard then check return value).
That argument strikes me as spurious. I'll grant that I have had fewer than
24 hours to think about the ramifications of call() and return(). I'll
also grant that I am quite capable of being wrong. Nonetheless, it seems
that rejecting a feature because it does not immediately provide additional
functionality strikes me as questionable. To be quite honest, it doesn't
seem to make sense to expect call() and return() to be aware of the call
parameters and return values of every member function.

Also, given a fixed amount of time and effort, there are also a choice
of features to introduce. What would you have liked to give up to get
call() and return()?
Cpp.
There is one prominent example where I did go against uniform negative
local feedback: virtual functions. Had I listened to my reasonable and
experienced colleagues, you wouldn't have had them in C++ - and you
probably would never have heard of C++.
When I read the first paragraph in §2.11.3 of D&E, it struck me as blatantly
obvious that these two functions would be useful. The wording in D&E
suggests that call() and return() might be worth reconsidering. Other than
starting this thread, my immediate reaction was to look at the chapter in
_The Java Language Specification_ to see if I could glean any insight as to
whether Java is using basically the same idea under the hood. So far it is
unclear to me.

I looked at the date of 1980 for the example of using call() and return(),
and thought about the fact that C++ still has no native thread support. I
don't know that it should, but I have to wonder if call() and return() had
been part of C++ whether I would ever have heard of Java.
--
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/
Dec 16 '06 #16

P: n/a

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() but they are way more flexible and, more
importantly IMHO, non-intrusive.

http://www.research.att.com/~bs/wrapper.pdf
I only skimmed wrapper.pdf, so the example below of an alternative
approach may be redundant:

#include <iostream>

// A's prolog/epilog.
class S
{
protected:
S() { std::cout << "call()\n"; }
~S() { std::cout << "return()\n"; }
};

// A's data.
class D
{
friend class A;
private:
int x, y, z;
};

class A : private S
{
public:
// A's interface.
int foo() { std::cout << "foo()\n"; return(0); }
void bar();

private:

D &d;

A();
A(const A &);
void operator = (const A &);

public:
A(D &dd) : d(dd) { }
};

int main(void) { D d; return(A(d).foo()); }

The added wrinkle with this is that a named instance of A
could be created, and several A members could be called
between the invocations of call()/return(). But, in some
situations, that could be a good thing.

Dec 16 '06 #17

P: n/a
Steven T. Hatton wrote:
>
Bruno was burned at the stake, wasn't he?

"It is proof of a base and low mind for one to wish to think with the masses
or majority, merely because the majority is the majority. Truth does not
change because it is, or is not, believed by a majority of the people."
I think your implicit assumption is that the smartest person will
always
have the best idea. But nobody is that smart. Relative smartness
maybe best thought of as how high the statistical likelyhood is of
having the better idea. If you ask 100 people something, even
if there is a 90% chance that you will be right and any one of
them wrong, if they all disagree with you, then statistically, you're
almost certainly wrong.

Dec 16 '06 #18

P: n/a
On 2006-12-16 02:19, Steven T. Hatton wrote:
>IR wrote:
>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.
I came across this nice little name the other day: retroactive modeling.
Meaning that you can use new things with old, or more concrete you can
use non-intrusive concepts on already existing objects even if you don't
have access to their implementation.

--
Erik Wikström
Dec 16 '06 #19

P: n/a
wk****@yahoo.com wrote:
Steven T. Hatton wrote:
>>
Bruno was burned at the stake, wasn't he?

"It is proof of a base and low mind for one to wish to think with the
masses or majority, merely because the majority is the majority. Truth
does not change because it is, or is not, believed by a majority of the
people."

I think your implicit assumption is that the smartest person will
always
have the best idea. But nobody is that smart. Relative smartness
maybe best thought of as how high the statistical likelyhood is of
having the better idea. If you ask 100 people something, even
if there is a 90% chance that you will be right and any one of
them wrong, if they all disagree with you, then statistically, you're
almost certainly wrong.
I believe you missed the several intended ironies in my comment.
--
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/
Dec 16 '06 #20

P: n/a
Erik Wikström wrote:
On 2006-12-16 02:19, Steven T. Hatton wrote:
>>IR wrote:
>>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.

I came across this nice little name the other day: retroactive modeling.
Meaning that you can use new things with old, or more concrete you can
use non-intrusive concepts on already existing objects even if you don't
have access to their implementation.
That approach is sometimes called a hack, a kludge or a patch. The fact of
the matter is that you cannot always accomplish the same thing
by "non-intrusive" means as you can with an "intrusive" design.
boost::enable_shared_from_this is an interesting example of the futility of
such an effort.
--
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/
Dec 16 '06 #21

P: n/a

Steven T. Hatton wrote:
wk****@yahoo.com wrote:
Steven T. Hatton wrote:
>
...

I believe you missed the several intended ironies in my comment.
Irony doesn't transmit well in web postings, even less well than humor
in general. Maybe you should consider using "smilys".

Dec 16 '06 #22

P: n/a
Steven T. Hatton wrote:
>
When I read the first paragraph in §2.11.3 of D&E, it struck me as blatantly
obvious that these two functions would be useful. The wording in D&E
suggests that call() and return() might be worth reconsidering.
But what advantages do they offer over the alternative non-intrusive
approaches? I can't see any and the lack of access to the member's
parameters is a big disadvantage.
>
I looked at the date of 1980 for the example of using call() and return(),
and thought about the fact that C++ still has no native thread support. I
don't know that it should, but I have to wonder if call() and return() had
been part of C++ whether I would ever have heard of Java.
I can't see any relationship between call() and return() and Java. They
are two solutions in two completely unrelated problems spaces.

--
Ian Collins.
Dec 16 '06 #23

P: n/a
bjarne wrote:
Steven T. Hatton wrote:
>wk****@yahoo.com wrote:
>>Steven T. Hatton wrote:
...
I believe you missed the several intended ironies in my comment.

Irony doesn't transmit well in web postings, even less well than humor
in general. Maybe you should consider using "smilys".
Microsoft has patents on those.

(omitting requisite smily due to patent infringement concerns).
Dec 16 '06 #24

P: n/a
Ian Collins wrote:
Steven T. Hatton wrote:
>>
When I read the first paragraph in §2.11.3 of D&E, it struck me as
blatantly
obvious that these two functions would be useful. The wording in D&E
suggests that call() and return() might be worth reconsidering.

But what advantages do they offer over the alternative non-intrusive
approaches?
Among the advantages of the intrinsic call/return pattern are: simplicity,
clarity, uniformity, localization of functionality, access to intrinsic
state, inheritability, etc. I am, of course, making some assumptions about
how it might be implemented.
I can't see any and the lack of access to the member's parameters is a big
disadvantage.
I don't see these bracketing functions as call specific. They would work at
the level of the object as a whole. Since I've never actually had them to
work with, and have only been aware of the concept for a day, it's hard for
me to assess their full potential.
>I looked at the date of 1980 for the example of using call() and
return(), and thought about the fact that C++ still has no native thread
support. I don't know that it should, but I have to wonder if call() and
return() had been part of C++ whether I would ever have heard of Java.

I can't see any relationship between call() and return() and Java. They
are two solutions in two completely unrelated problems spaces.
http://www.gotw.ca/publications/c_family_interview.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?
[...]
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() [So what?]. Worse, I completely failed to
convince people of the usefulness of this notion, so I removed call() and
return() when I defined C++."

http://java.sun.com/docs/books/jls/t...tml/j3TOC.html[*]
"§17.1 Locks
The Java programming language provides multiple mechanisms for communicating
between threads. The most basic of these methods is synchronization, which
is implemented using monitors. Each object in Java is associated with a
monitor, which a thread can lock or unlock. Only one thread at a time may
hold a lock on a monitor. Any other threads attempting to lock that monitor
are blocked until they can obtain a lock on that monitor. A thread t may
lock a particular monitor multiple times; each unlock reverses the effect
of one lock operation."

I am aware that one can synchronize on individual Java methods, which
appears contrary to the idea of simple before/after bracketing on a class
instance.

"§8.4.3.6 synchronized Methods
A synchronized method acquires a monitor (§17.1) before it executes. For a
class (static) method, the monitor associated with the Class object for the
method's class is used. For an instance method, the monitor associated with
this (the object for which the method was invoked) is used."

Bear in mind, however, that a method in Java is actually and instance of
java.lang.reflect.Method. At any rate, the same kind of selectivity could
be accomplished in C++ with call/return through multiple inheritance. Or
through a language extension such as support for a /synchronized/ keyword.
[*]Everybody who contributes text to the C++ Standard should read this book.
Not for the technical ideas, but as an example of an alternative style of
presentation.
--
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/
Dec 17 '06 #25

P: n/a

Steven T. Hatton wrote:
wk****@yahoo.com wrote:
Steven T. Hatton wrote:
>
Bruno was burned at the stake, wasn't he?

"It is proof of a base and low mind for one to wish to think with the
masses or majority, merely because the majority is the majority. Truth
does not change because it is, or is not, believed by a majority of the
people."
I think your implicit assumption is that the smartest person will
always
have the best idea. But nobody is that smart. Relative smartness
maybe best thought of as how high the statistical likelyhood is of
having the better idea. If you ask 100 people something, even
if there is a 90% chance that you will be right and any one of
them wrong, if they all disagree with you, then statistically, you're
almost certainly wrong.

I believe you missed the several intended ironies in my comment.
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.

Dec 17 '06 #26

P: n/a
bjarne wrote:
>
Steven T. Hatton wrote:
>wk****@yahoo.com wrote:
Steven T. Hatton wrote:

...

I believe you missed the several intended ironies in my comment.

Irony doesn't transmit well in web postings, even less well than humor
in general. Maybe you should consider using "smilys".
Zaphod Beeblebrox?

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? Are they worth reconsidering?
--
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/
Dec 17 '06 #27

P: n/a
wk****@yahoo.com 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. 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

Quod erat demonstrandum.
--
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/
Dec 17 '06 #28

P: n/a
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?

By the way, if you are really reading "The Design..." you must know that the
best way to make a feature considered or reconsidered is to implement it
and show his usefullness with real samples.

--
Salu2
Dec 17 '06 #29

P: n/a
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? 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.
By the way, if you are really reading "The Design..."
I pick it up from time to time and read a bit more of it. Fortunately, it
is the kind of book well suited to such use.
you must know that
the best way to make a feature considered or reconsidered is to implement
it and show his usefullness with real samples.
I still have a lot to learn about using C++. In particular, I have a lot to
learn about how multi-threading is accomplished with C++. One very nice
thing about Java is that threading is built in, and fairly straightforward.
In my _very_ limited experience with multi-threading in C++ I have
encountered problems because my GUI library uses a different kind of
threading than the 3D library. Also, how threads in Java work is far more
obvious than it is to me in C++.

The question I intend to bear in mind in order to evaluate the usefulness of
the call/return pattern is whether there are actions taken at the object
level as part of execution flow in existing programs. My instincts tell me
that there may be a place for such a feature in device drivers, as well as
in concurrent programming. Even if there are wrapper designs which
intercept parameters, it may be beneficial to separate the call-specific
and class/object-specific components.

I've been wrong in the past about features which appear useful, so I may be
wrong about call() and return(). I have to say, however, that my intuition
is very strongly in favor of their usefulness.

--
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/
Dec 17 '06 #30

P: n/a
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
Dec 17 '06 #31

P: n/a
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/
Dec 18 '06 #32

P: n/a
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.
Dec 18 '06 #33

P: n/a
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

Dec 18 '06 #34

P: n/a
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
Dec 18 '06 #35

P: n/a
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/
Dec 18 '06 #36

P: n/a
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)
Dec 18 '06 #37

P: n/a
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/
Dec 18 '06 #38

P: n/a

Steven T. Hatton wrote:
wk****@yahoo.com 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.

Dec 18 '06 #39

P: n/a
wk****@yahoo.com wrote:
>
Steven T. Hatton wrote:
>wk****@yahoo.com 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/
Dec 18 '06 #40

P: n/a
Steven T. Hatton wrote:
The wording of the C++ Standard could and should be better.
There's a reason standards are frequently hard to read. It's the same
reason that legal documents are frequently hard to read.

Legal documents aren't meant to make a point clearly and succinctly.
They're meant to resolve arguments.

The C++ standard isn't meant to teach you about the language. It's
there to ensure that compilers are compatible with each other, and to
resolve arguments.
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.
That's not what standards are for. That's what tutorial books are for,
and there are several excellent books on C++ that meet your
requirements.
IMO comparing C++ (or the Standard document) to other languages is less
beneficial in most cases than comparing it to its potential.
There's some truth in that, but not for improving C++ itself. The
potential of the language may not yet be fully realised, but I believe
that its potential will be more fully realised in its use, not in
changes to its design.

--mpa

Dec 18 '06 #41

P: n/a
Michael Ashton wrote:
Steven T. Hatton wrote:
>The wording of the C++ Standard could and should be better.

There's a reason standards are frequently hard to read. It's the same
reason that legal documents are frequently hard to read.

Legal documents aren't meant to make a point clearly and succinctly.
They're meant to resolve arguments.
Not always.
The C++ standard isn't meant to teach you about the language. It's
there to ensure that compilers are compatible with each other, and to
resolve arguments.
Thank you for making my case for me.
> 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.

That's not what standards are for.
The last point is debatable. The others I hold to be axiomatic.
That's what tutorial books are for,
and there are several excellent books on C++ that meet your
requirements.
It's not very easy to clearly explain something which doesn't make sense.
The wording of the Standard is so arcane that very few people can even
figure out where it is wrong. If you actually apply the in-place
definitions given in the text to use of the defined terms appearing in
other parts of the document, you will realize that the document contains
several errors.

--
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/
Dec 18 '06 #42

P: n/a

Steven T. Hatton wrote:
....
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.
....

Basically useless information: I agree with you.

Possibly useful information: When writting C++ code, I always first
refer to C++PL. If I have doubts I look at the draft '98 Standard and
google the topic. If I'm still not sure, I post my question in
comp.std.c++ or here. So far, a knowledgable person has always
responded, and I've never gotten conflicting answers from mutiple
active Committee members. If a big meteor ever hit the site of an
ongoing ISO C++ Committee meeting, we'd be in big trouble.
Otherwise, the current situation is workable.

Dec 18 '06 #43

P: n/a

Steven T. Hatton wrote:
Michael Ashton wrote:
Steven T. Hatton wrote:
The wording of the C++ Standard could and should be better.
There's a reason standards are frequently hard to read. It's the same
reason that legal documents are frequently hard to read.

Legal documents aren't meant to make a point clearly and succinctly.
They're meant to resolve arguments.

Not always.
The C++ standard isn't meant to teach you about the language. It's
there to ensure that compilers are compatible with each other, and to
resolve arguments.

Thank you for making my case for me.
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.
That's not what standards are for.

The last point is debatable. The others I hold to be axiomatic.
That's what tutorial books are for,
and there are several excellent books on C++ that meet your
requirements.

It's not very easy to clearly explain something which doesn't make sense.
The wording of the Standard is so arcane that very few people can even
figure out where it is wrong. If you actually apply the in-place
definitions given in the text to use of the defined terms appearing in
other parts of the document, you will realize that the document contains
several errors.
This seems to have gone snippy, so I concede everything. I await your
improved language and standard with great eagerness. --mpa

Dec 18 '06 #44

P: n/a
Michael Ashton wrote:
>
Steven T. Hatton wrote:
>Michael Ashton wrote:
>>
That's what tutorial books are for,
and there are several excellent books on C++ that meet your
requirements.
The requirements I have set for myself are to understand the formal
specification of the C++ programming language. That formal specification
is presented in ISO/IEC 14882:2003.
>It's not very easy to clearly explain something which doesn't make sense.
The wording of the Standard is so arcane that very few people can even
figure out where it is wrong. If you actually apply the in-place
definitions given in the text to use of the defined terms appearing in
other parts of the document, you will realize that the document contains
several errors.

This seems to have gone snippy, so I concede everything. I await your
improved language and standard with great eagerness. --mpa
http://groups.google.com/group/comp....f718062?&hl=en
--
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/
Dec 19 '06 #45

P: n/a
On Dec 18, 6:53 pm, "Steven T. Hatton" <chatten...@germania.supwrote:
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 thisis
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.
Just to be clear, are you talking about the proposed threading-model
form C++0x or some third-party threading implementation? If you are
talking about third-party implementations remember that most of them
are adoptions of other threading-models (like pthreads) most of which
were not designed with C++ in mind

--
Erik Wikström

Dec 19 '06 #46

P: n/a
Erik Wikström wrote:
On Dec 18, 6:53 pm, "Steven T. Hatton" <chatten...@germania.supwrote:
>Pete Becker wrote:
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.

Just to be clear, are you talking about the proposed threading-model
form C++0x or some third-party threading implementation? If you are
talking about third-party implementations remember that most of them
are adoptions of other threading-models (like pthreads) most of which
were not designed with C++ in mind
I'm talking about OpenThreads and QThread. I use applications and libraries
that depend on these, and they work fine. I'm also aware that ACE has
successful threading support. The problem I encountered was when I tried
to use QThread to spin off OSG animations. The OpenThreads in OSG didn't
play nicely with QThread, and when I looked into the matter, I realized it
was going to require more attention than it was worth at the time. Please
note that my statement only referred to my ability to use these features,
and not to their inherent usability.

As for what's brewing in C++0X, I'm not sure if that is the same thing that
boost offers. I have looked at the boost documentation, but that's the
extent of my exposure. What I can say about Java's thread support is that
it is very easy to use. Qt's thread support isn't too bad considering it's
implemented in the language as opposed to being part of the language.

The advantage Java has is that a thread is a thread is a thread. That, of
course, means you use Java's idea of good threading, or don't use
multi-threading. It may turn out that 25 years later there is actually a
better way, but I am still stunned that call() and return() were not
enthusiastically accepted by the C with Classes users.
--
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/
Dec 19 '06 #47

This discussion thread is closed

Replies have been disabled for this discussion.