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/

[Michael Ashton]

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

[Steven T. Hatton]

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/

[wkaras]

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.

[Michael Ashton]

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

[Steven T. Hatton]

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/

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

On Dec 18, 6:53 pm, "Steven T. Hatton" <chatten...@ger mania.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

[Steven T. Hatton]

Erik Wikström wrote:

On Dec 18, 6:53 pm, "Steven T. Hatton" <chatten...@ger mania.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
enthusiasticall y 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/