throw operator

[Alf P. Steinbach]

* Pete Becker:

And "operator" is defined in the grammar summary annex A, §A.11, as

operator: one of
new delete new[] delete[]
+ - * / % ^ & | ~
! = < > += -= *= /= %=
^= &= |= << >> >>= <<= == !=
<= >= && || ++ -- , ->* ->
() []

however, this definition seems to have been removed in the latest
draft! While still keeping the references to it, including in annex
A (definition of "token" in §A.2)!

No, it wasn't removed.

Uh, am I really looking at the very latest draft? It's titled N2315
and dated 2007-06-25. I'm too lazy to check over at the committee
pages...

No, that's not the latest. Not that it matters for this non-issue.

I don't understand. I find it in §13.5/1, but it really does seem that
it's disappeared from the grammar summary?

Cheers,

- Alf

 

[Pete Becker]

* Pete Becker:

And "operator" is defined in the grammar summary annex A, §A.11, as

operator: one of
new delete new[] delete[]
+ - * / % ^ & | ~
! = < > += -= *= /= %=
^= &= |= << >> >>= <<= == !=
<= >= && || ++ -- , ->* ->
() []

however, this definition seems to have been removed in the latest
draft! While still keeping the references to it, including in annex A
(definition of "token" in §A.2)!

No, it wasn't removed.

Uh, am I really looking at the very latest draft? It's titled N2315
and dated 2007-06-25. I'm too lazy to check over at the committee
pages...

No, that's not the latest. Not that it matters for this non-issue.

I don't understand. I find it in §13.5/1, but it really does seem that
it's disappeared from the grammar summary?

Oh, I see: when you said that the definition had been removed, you
meant that the definition was there, but the non-normative repetition
of the definition wasn't there.

 

[Kai-Uwe Bux]

The standard does speak of the "operands" of throw, however.
And as Erik pointed out, defines expressions as consisting of
operands and operators.

And of course, in section 5, regularly refers to many things
that aren't preprocessor operators as operators: static_cast,
reinterpret_cast and dynamic_cast, for example (but I didn't
find a case where it refered to const_cast as an operator),
sizeof (but not typeid). On the other hand, I can't off hand
find where it refers to ++ or -- as operators; at least, it
doesn't in §5.3.2.

[13.5/1] defines the term "operator" as a non-terminal symbol in the C++
grammar. There ++ an -- are listed (as opposed to, e.g., :. (Then the
standard goes on to tell us that

. .* :: ?:

are operators that cannot be overloaded although these are even missing from
the list of operators. So, clearly the standard recognized operators that
are not operators in the sense of the C++ grammar.)

I think it safe to assume that "operators" is not a normative
category of tokens, and that whether something is explicitly
called an operator or not is simply an accident of the way its
description was worded.

Also, there are certain classes of
operators that are defined in the standard (like unary operators,
multiplicative operators, or overloadable operators) and throw is not a
member in any of those.

Neither is ++ nor --. If you're refering to the section
headers, then neither is new or delete, which are defined as
preprocessor-op-or-punct, nor static_cast, which is explicitly
called an operator in the section which describes it.

As for the table in [2.12]: as far as I know, there is no place where the
standard refers to anything as an operator that is not listed in [2.12].

§5.2.7/1: "[...] The dynamic_cast operator shall not cast away
constness."

§5.2.9/1: "[...] The static_cast operator shall not cast away
constness."

§5.2.10/2: "The reinterpret_cast operator shall not cast away
constness."

§5.3.3/1: "The sizeof operator [...]" (Interestingly, IIRC, K&R
1 did list sizeof as an operator.)

And that's just a very quick glance at section 5.

Right. I did not remember that casts are referred to as operators, and with
regard to sizeof (and I think typeid) knew that they are operators but did
not realize that they are missing from [2.12].

Now, in view of [13.5/3], can we deduce that reinterpret_cast is
overloadable

I think my conclusion holds: the standard does not consider
"operartor" as a normative categorization. It's a word with a
technical meaning, which may be used when appropriate, but
nothing can be deduced from its absense.

I think you are right (apart from [13.5/1]).

[snip: other non-sense of mine and conclusive refutation]


Thanks

Kai-Uwe Bux

 

[James Kanze]

* James Kanze:

That's a good point.

On the other hand, the contention that "operator" isn't a formal term
seems to be incorrect: §2.4/1 says that

"Each preprocessing token ... shall have the lexical form of a
keyword, an identifier, a literal, an operator, or a punctuator".

The /shall/ would be meaningless if "operator" is whatever we
want it to be.

For the moment, however, we still only have "operator" as a
normative word in the preprocessor.

And this same categorization is repeated in §2.6, where "operator" is
used in the BNF syntax for "token".

And "operator" is defined in the grammar summary annex A, §A.11, as

operator: one of
new delete new[] delete[]
+ - * / % ^ & | ~
! = < > += -= *= /= %=
^= &= |= << >> >>= <<= == !=
<= >= && || ++ -- , ->* ->
() []

however, this definition seems to have been removed in the latest draft!
While still keeping the references to it, including in annex A
(definition of "token" in §A.2)!

Uh, am I really looking at the very latest draft? It's titled N2315 and
dated 2007-06-25. I'm too lazy to check over at the committee pages...

I think this is a matter for [comp.std.c++], an editorial fix.

I'm not quite sure which way the fix should go. Do we say that
the text refering to static_cast as an operator should be fixed
as well? And what about things like bit_or?

James, would you, please?

If no one else does. I'll just raise the point that the
standard doesn't seem to be entirely consistent about its use of
the term.

 

[James Kanze]

[...]

[13.5/1] defines the term "operator" as a non-terminal symbol in the C++
grammar.

Attention. In that paragraph, the word operator has three
distinction meaning. In the grammar production (which is
operator operator), the first use is a terminal, and refers to
the keyword "operator" (which is not an operator, of course),
and the second is simply a production---a non-terminal symbol.
Both uses here are as names in the formal grammar, and
independant of any "normal" use of the word, including the use
in the running text. Note that the three uses use different
fonts. (And I just love a production which reads "operator
operator", where because of the different fonts, the first is a
terminal, and the second a non-terminal.)

There ++ an -- are listed (as opposed to, e.g., :. (Then the
standard goes on to tell us that

. .* :: ?:

are operators that cannot be overloaded although these are
even missing from the list of operators. So, clearly the
standard recognized operators that are not operators in the
sense of the C++ grammar.

I think that things are a bit confused. Here, new and delete
slip in, because you can overload them. On the other hand, I
see no mention of bitor et al., although "operator bitor()" is
certainly a legal overload.

[...]

I think you are right (apart from [13.5/1]).

On the other hand... many tokens can be operators in some
contexts, and not in others. And the distinction is important
in at least two cases: operator,() and operator=(). The
overloads will be used when the comma or the equals sign is an
operator, and not when it isn't. In the case of equals, it's
not really a big problem: the equals sign is an operator if it
occurs in an expression, and only punctuation if it doesn't; in
the case of comma, however, it's a real issue.

Globally, I don't think that the standard is very consistent in
all this, and it really should be considered a defect. On the
other hand, it would take a lot of work to fix (since the
confusion seems fairly pervasive), for very little benefit: I
don't think there are any places where the incoherent use of
"operator" causes any problems with regards to what is or is not
a legal program, or to what the semantics of a legal program
are. So I rather suspect that the reaction of the committee
would be that they agree that the wording could be better, but
that it's not worth fixing at the present time.