throw operator

[Ranganath]

Why is throw keyword considered as an operator?

[Victor Bazarov]

Ranganath wrote:

Why is throw keyword considered as an operator?

It is impossible to answer a question based on a wrong premise.
'throw' is not an operator. Why do you think it is one? Or,
rather, what do you mean "considered as an operator"? What is
the context?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-10-03 12:31, Ranganath wrote:

Why is throw keyword considered as an operator?

For the same reason that new, delete, and sizeof are operators I would
suspect. What else would it be, if it was not an operator?

--
Erik Wikström

[Victor Bazarov]

Erik Wikström wrote:

On 2007-10-03 12:31, Ranganath wrote:

>Why is throw keyword considered as an operator?

For the same reason that new, delete, and sizeof are operators I would
suspect. What else would it be, if it was not an operator?

What's 'return'? 'throw' is exactly that.

'delete' is an operator because you're allowed to overload it and
because the name of that function would be 'operator delete'. But
among the rest of true operators it stands out because it does not
yield a value and hence cannot be used in another expression.

'throw' is a keyword used in two constructs: to declare the list
of exceptions the function can throw and to actually redirect the
flow. 'return' isn't used to declare anything, neither is 'goto'.
But 'throw' is much more like 'return' or 'goto' than 'sizeof' or
'typeid'.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Ranganath]

On Oct 3, 8:46 pm, "Victor Bazarov" <[e-mail]:

Ranganath wrote:

Why is throw keyword considered as an operator?

It is impossible to answer a question based on a wrong premise.
'throw' is not an operator. Why do you think it is one? Or,
rather, what do you mean "considered as an operator"? What is
the context?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

throw is an operator. Please have a look at http://en.wikipedia.org/wiki/Operators_in_C_and_C++.
All I wanted to know is what constraint makes it to be treated as an
operator.

[Kai-Uwe Bux]

Ranganath wrote:

On Oct 3, 8:46 pm, "Victor Bazarov" <[e-mail]:

>Ranganath wrote:

Why is throw keyword considered as an operator?

It is impossible to answer a question based on a wrong premise.
'throw' is not an operator. Why do you think it is one? Or,
rather, what do you mean "considered as an operator"? What is
the context?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

throw is an operator.

According to the language standard, "throw" is a keyword, not an operator.
Please have a look at clauses [2.11] (listing all keywords) and [2.12]
(listing all operators and punctuators).

Please have a look at http://en.wikipedia.org/wiki/Operators_in_C_and_C++.

That would be a either a bug in wikipedia or may indicate that wikipedia
uses a different notion of "operator" (maybe something that aims to be
meaningful across programming languages, but I am just guessing here).

All I wanted to know
is what constraint makes it to be treated as an operator.

Huh?
Best

Kai-Uwe Bux

[James Kanze]

On Oct 3, 7:16 pm, "Victor Bazarov" <[e-mail]:

Erik Wikström wrote:

On 2007-10-03 12:31, Ranganath wrote:

Why is throw keyword considered as an operator?

For the same reason that new, delete, and sizeof are operators I would
suspect. What else would it be, if it was not an operator?

What's 'return'? 'throw' is exactly that.

Not really. Throw can be used in an expression, return can't.

'delete' is an operator because you're allowed to overload it and
because the name of that function would be 'operator delete'. But
among the rest of true operators it stands out because it does not
yield a value and hence cannot be used in another expression.

You're forgetting the comma operator, and ?:. Things like:

MyClass::MyClass( T arg )
: myMember( isValid( arg ) ? arg : throw "Invalid arg")
{
}

are perfectly valid and legal.

'throw' is a keyword used in two constructs: to declare the list
of exceptions the function can throw and to actually redirect the
flow. 'return' isn't used to declare anything, neither is 'goto'.
But 'throw' is much more like 'return' or 'goto' than 'sizeof' or
'typeid'.

Throw can be used to introduce an exception specificaion of a
function declaration, in which case, it isn't an operator, or it
can be used in an expression, in which case, it is. Except, of
course, that this distinctio between operators and other tokens
is rather superficial and meaningless. The only significant
distinction made by the standard is between pre-processor
op-or-punc (which includes new and delete, but not throw and
return), and the actual language tokens. The only real
difference between new and throw (or new and while) is that:

#define new 0 // Illegal, always...
#define throw 0 // Legal, unless you include a
// standard header.

For the rest, after preprocessing, both are tokens, and both are
keywords. There is no distiction between operators and
non-operators, at least in the standard. In common parlance, I
think that you'd consider something an operator if it is used in
an expression, and "punctuation" otherwise. In which case,
"throw" is like a comma: sometimes one, sometimes the other.
But then, so is int: it can introduce a declaration, but it can
also be used as a conversion operator.

In sum, the only real answer is that there is no such
distinction operator/non-operator, or that any such distinction
is arbitrary, and decided upon by the author.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Oct 4, 8:05 am, Kai-Uwe Bux <[e-mail]:

Ranganath wrote:

On Oct 3, 8:46 pm, "Victor Bazarov" <[e-mail]:

Ranganath wrote:
Why is throw keyword considered as an operator?

It is impossible to answer a question based on a wrong premise.
'throw' is not an operator. Why do you think it is one? Or,
rather, what do you mean "considered as an operator"? What is
the context?

throw is an operator.

According to the language standard, "throw" is a keyword, not an operator.

As far as I can see, the language standard doesn't define
operators. Without a definition, I'm incapable of saying
whether throw is an operator or not.

Please have a look at clauses [2.11] (listing all keywords) and [2.12]
(listing all operators and punctuators).

Please read the first sentence of §2.12:

The lexical representation of C++ programs includes a number
of preprocessing tokens which are used in the syntax of the
preprocessor or are converted into tokens for operators and
punctuators:"

Note the relevance with regards to the preprocessor. The fact
that throw isn't in this list means that:

#define throw catch

is legal (unless you include a standard header, in which case,
§17.4.3.1.1/2 applies: "A translation unit shall not #define or
#undef names lexically identical to keywords").

That is, in fact, all it means.

One may, of course, wonder about the conditions for inclusion in
this list. There's really no more reason for new to be in it,
than for throw. I suspect that it's more or less historical.
K&R (at least the original edition) had two lists, one for
operators, and one for punctuation (and the comma was in both).
I think Stroustrup originally followed this (although I don't
have my copy of his book handy to verify), adding new and delete
to the list of operators, because they can appear in an
expression. The C++ commitee dropped the distinction, adopting
rather the distinction pre-processor/parser, and merged the two
lists---logically, I suppose, new and delete should have been
dropped from the resulting list at that time. And the alternate
tokens got added---necessarily, since the pre-processor has to
recognize them. Throw got added to the language much later
(than new and delete), and since there was no need for the
preprocessor to know about it, it didn't get added to the list.

At any rate, there's no real logic behind it: the pre-processor
has no need to treat new and delete differently from throw, or
even while; on the other hand, it does treat the keywords true
and false differently (although they aren't in the list).
(IIRC, as late as CD2, there was no special treatment of true or
false by the pre-processor. Which meant that "#if true"
evaluated to "#if 0", and the following block would not be
compiled!)

Please have a look athttp://en.wikipedia.org/wiki/Operators_in_C_and_C++.

That would be a either a bug in wikipedia or may indicate that
wikipedia uses a different notion of "operator" (maybe
something that aims to be meaningful across programming
languages, but I am just guessing here).

All I wanted to know
is what constraint makes it to be treated as an operator.

Huh?

I think what he's really asking for is the definition of
operator. IMHO, there isn't really one, and asking whether
"throw" (or "while", or "new") are operators or not is a
meaningless question. (And the Wikipedia is a wonderful
resource for meaningless or unimportant questions---fun
questions, in other words---, even if it isn't very good as a
reference or for serious work.) I suspect that the definition
being used here is that an operator is a keyword or punctuation
that can be used in an expression (but then, what is the second
"int" in "int i = int(d);").

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Victor Bazarov]

James Kanze wrote:

On Oct 3, 7:16 pm, "Victor Bazarov" <[e-mail]:

>Erik Wikström wrote:

>>On 2007-10-03 12:31, Ranganath wrote:
Why is throw keyword considered as an operator?

>>For the same reason that new, delete, and sizeof are operators I
would suspect. What else would it be, if it was not an operator?

>What's 'return'? 'throw' is exactly that.

Not really. Throw can be used in an expression, return can't.

>'delete' is an operator because you're allowed to overload it and
because the name of that function would be 'operator delete'. But
among the rest of true operators it stands out because it does not
yield a value and hence cannot be used in another expression.

You're forgetting the comma operator, and ?:. Things like:

MyClass::MyClass( T arg )
: myMember( isValid( arg ) ? arg : throw "Invalid arg")
{
}

are perfectly valid and legal.

Yes, I did forget about those. I am guessing that's might be the
only reason to ever think of 'throw' as an operator. Of course, it
still does non yield any value and as such it's use in an expression
is rather special.

[..]

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Ranganath]

On Oct 4, 11:05 am, Kai-Uwe Bux <[e-mail]:

Ranganath wrote:

On Oct 3, 8:46 pm, "Victor Bazarov" <[e-mail]:

Ranganath wrote:
Why is throw keyword considered as an operator?

It is impossible to answer a question based on a wrong premise.
'throw' is not an operator. Why do you think it is one? Or,
rather, what do you mean "considered as an operator"? What is
the context?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

throw is an operator.

According to the language standard, "throw" is a keyword, not an operator.
Please have a look at clauses [2.11] (listing all keywords) and [2.12]
(listing all operators and punctuators).

Please have a look athttp://en.wikipedia.org/wiki/Operators_in_C_and_C++.

That would be a either a bug in wikipedia or may indicate that wikipedia
uses a different notion of "operator" (maybe something that aims to be
meaningful across programming languages, but I am just guessing here).

All I wanted to know
is what constraint makes it to be treated as an operator.

Huh?

Best

Kai-Uwe Bux

Hi,
Please have a look at "The C++ Programming Language" by Stroustrup 3rd
Edition, section 6.2.
It clearly mentions that throw is an operator in the table named
"Operator Summary".

- rr

[Ranganath]

On Oct 4, 2:59 pm, James Kanze <[e-mail]:

On Oct 4, 8:05 am, Kai-Uwe Bux <[e-mail]:

Ranganath wrote:

On Oct 3, 8:46 pm, "Victor Bazarov" <[e-mail]:
>Ranganath wrote:
Why is throw keyword considered as an operator?
>It is impossible to answer a question based on a wrong premise.
>'throw' is not an operator. Why do you think it is one? Or,
>rather, what do you mean "considered as an operator"? What is
>the context?
throw is an operator.

According to the language standard, "throw" is a keyword, not an operator.

As far as I can see, the language standard doesn't define
operators. Without a definition, I'm incapable of saying
whether throw is an operator or not.

Please have a look at clauses [2.11] (listing all keywords) and [2.12]
(listing all operators and punctuators).

Please read the first sentence of §2.12:

The lexical representation of C++ programs includes a number
of preprocessing tokens which are used in the syntax of the
preprocessor or are converted into tokens for operators and
punctuators:"

Note the relevance with regards to the preprocessor. The fact
that throw isn't in this list means that:

#define throw catch

is legal (unless you include a standard header, in which case,
§17.4.3.1.1/2 applies: "A translation unit shall not #define or
#undef names lexically identical to keywords").

That is, in fact, all it means.

One may, of course, wonder about the conditions for inclusion in
this list. There's really no more reason for new to be in it,
than for throw. I suspect that it's more or less historical.
K&R (at least the original edition) had two lists, one for
operators, and one for punctuation (and the comma was in both).
I think Stroustrup originally followed this (although I don't
have my copy of his book handy to verify), adding new and delete
to the list of operators, because they can appear in an
expression. The C++ commitee dropped the distinction, adopting
rather the distinction pre-processor/parser, and merged the two
lists---logically, I suppose, new and delete should have been
dropped from the resulting list at that time. And the alternate
tokens got added---necessarily, since the pre-processor has to
recognize them. Throw got added to the language much later
(than new and delete), and since there was no need for the
preprocessor to know about it, it didn't get added to the list.

At any rate, there's no real logic behind it: the pre-processor
has no need to treat new and delete differently from throw, or
even while; on the other hand, it does treat the keywords true
and false differently (although they aren't in the list).
(IIRC, as late as CD2, there was no special treatment of true or
false by the pre-processor. Which meant that "#if true"
evaluated to "#if 0", and the following block would not be
compiled!)

Please have a look athttp://en.wikipedia.org/wiki/Operators_in_C_and_C++.

That would be a either a bug in wikipedia or may indicate that
wikipedia uses a different notion of "operator" (maybe
something that aims to be meaningful across programming
languages, but I am just guessing here).

All I wanted to know
is what constraint makes it to be treated as an operator.

Huh?

I think what he's really asking for is the definition of
operator. IMHO, there isn't really one, and asking whether
"throw" (or "while", or "new") are operators or not is a
meaningless question. (And the Wikipedia is a wonderful
resource for meaningless or unimportant questions---fun
questions, in other words---, even if it isn't very good as a
reference or for serious work.) I suspect that the definition
being used here is that an operator is a keyword or punctuation
that can be used in an expression (but then, what is the second
"int" in "int i = int(d);").

--
James Kanze (GABI Software) email:[e-mail]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

Hi James Kanz,
Thanks for the information.
I admit that my initial question was a not so clear, but you got it
right.
Your explanations are informative.

- rr

[Kai-Uwe Bux]

James Kanze wrote:

On Oct 4, 8:05 am, Kai-Uwe Bux <[e-mail]:

>Ranganath wrote:

On Oct 3, 8:46 pm, "Victor Bazarov" <[e-mail]:
Ranganath wrote:
Why is throw keyword considered as an operator?

>It is impossible to answer a question based on a wrong premise.
'throw' is not an operator. Why do you think it is one? Or,
rather, what do you mean "considered as an operator"? What is
the context?

throw is an operator.

>According to the language standard, "throw" is a keyword, not an
operator.

As far as I can see, the language standard doesn't define
operators. Without a definition, I'm incapable of saying
whether throw is an operator or not.

Well: Yes and No. I agree that operator is not put in italics anywhere in
the standard. However, the word "operator" is clearly used in the standard
in many places refering to things like "+". But nowhere in the standard
is "throw" referred to as an operator. 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.

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

This way, the standard establishes a somewhat consistent pattern of usage
for the word "operator". It is consistent with this pattern to say
that "throw" is not an operator and somewhat inconsistent to say it is.

>Please have a look at clauses [2.11] (listing all keywords) and [2.12]
(listing all operators and punctuators).

Please read the first sentence of §2.12:

The lexical representation of C++ programs includes a number
of preprocessing tokens which are used in the syntax of the
preprocessor or are converted into tokens for operators and
punctuators:"

Note the relevance with regards to the preprocessor. The fact
that throw isn't in this list means that:

#define throw catch

is legal (unless you include a standard header, in which case,
§17.4.3.1.1/2 applies: "A translation unit shall not #define or
#undef names lexically identical to keywords").

That is, in fact, all it means.

As far as pure normative consequences are concerned, you are right. However,
the table so happens (maybe coincidentally) to be compatible with the usage
of the term "operator" elsewhere in the standard: as mentioned above, I
don't know of any clause where the word "operator" refers to something
whose lexical representation is not listed in [2.12].
[snip]
Best

Kai-Uwe Bux

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2007-10-04 21:28, Kai-Uwe Bux wrote:

James Kanze wrote:

>On Oct 4, 8:05 am, Kai-Uwe Bux <[e-mail]:

>>Ranganath wrote:
On Oct 3, 8:46 pm, "Victor Bazarov" <[e-mail]:
Ranganath wrote:
Why is throw keyword considered as an operator?

>>It is impossible to answer a question based on a wrong premise.
'throw' is not an operator. Why do you think it is one? Or,
rather, what do you mean "considered as an operator"? What is
the context?

>throw is an operator.

>>According to the language standard, "throw" is a keyword, not an
operator.

As far as I can see, the language standard doesn't define
operators. Without a definition, I'm incapable of saying
whether throw is an operator or not.

Well: Yes and No. I agree that operator is not put in italics anywhere in
the standard. However, the word "operator" is clearly used in the standard
in many places refering to things like "+". But nowhere in the standard
is "throw" referred to as an operator. 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.

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

This way, the standard establishes a somewhat consistent pattern of usage
for the word "operator". It is consistent with this pattern to say
that "throw" is not an operator and somewhat inconsistent to say it is.

On the other hand the second sentence in section 5 (Expressions) reads
"An expression is a sequence of operators and operands that specifies a
computation." (Though this sentence is part of a note, so IIRC it should
not be normative.) And the second sentence in section 15 (Exceptions) is
"A handler will be invoked only by a /throw-expression/ ..." Lastly in
section 15.1, the third paragraph begins with "A /throw-expression/ a
temporary object, the type of which is determined by removing any top
level /cv-qualifiers/ from the static type of the operand of throw..."

So, expressions consists of operators and operands, and there exists
throw-expressions which are on the form of 'throw foo();' where foo is
an operand, which more or less means that throw should be a operator,
provided that the first sentence I quoted applies.

--
Erik Wikström

[James Kanze]

On Oct 4, 12:34 pm, "Alf P. Steinbach" <[e-mail]:

* James Kanze:

As far as I can see, the language standard doesn't define
operators. Without a definition, I'm incapable of saying
whether throw is an operator or not.

Not quite. The standard does define a lot of operators as operators,
using the term "operator" (the expression clause).

It uses the term, but it never defines what makes some things an
operator, and others not; a priori, it is using it in the
"usual" sense, and doesn't distinguish any particular
"normative" definition for it. The usual sense, of course, is
that an expression consists of operators and operands.

Since the standard does speak of the operands of throw, in this
sense, it is an operator. But as I said, the distinction is
really irrelevant. Operator is a convenient word for a certain
category of tokens in expressions, but whether something is an
operator or not has no real normative meaning.

It also provides a list of tokens (lexical section somewhere)
that includes all operators, but unfortunately also
punctuation symbols.

Where? All I've been able to find is a list of
"preprocessing-op-or-punc". Which doesn't include a lot of
things (e.g. static_cast) that are later called "operators".

Now if only punctuation symbols were defined, we could
subtract them from that set and have the operators. But
anyway, "throw" is not in either list.

It's in the list of keywords. It's in the grammar for a
throw-expression. The standard speaks of the operand of throw.
It makes sense to consider it an operator, just like static_cast
is an operator.

Of course, in such contexts, it also makes sense to consider int
an operator. As I said, it doesn't really matter much.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Oct 4, 9:28 pm, Kai-Uwe Bux <[e-mail]:

James Kanze wrote:

On Oct 4, 8:05 am, Kai-Uwe Bux <[e-mail]:

Ranganath wrote:
On Oct 3, 8:46 pm, "Victor Bazarov" <[e-mail]:
Ranganath wrote:
Why is throw keyword considered as an operator?

It is impossible to answer a question based on a wrong premise.
'throw' is not an operator. Why do you think it is one? Or,
rather, what do you mean "considered as an operator"? What is
the context?

throw is an operator.

According to the language standard, "throw" is a keyword, not an
operator.

As far as I can see, the language standard doesn't define
operators. Without a definition, I'm incapable of saying
whether throw is an operator or not.

Well: Yes and No. I agree that operator is not put in italics
anywhere in the standard. However, the word "operator" is
clearly used in the standard in many places refering to things
like "+". But nowhere in the standard is "throw" referred to
as an operator.

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.

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.

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.

This way, the standard establishes a somewhat consistent
pattern of usage for the word "operator". It is consistent
with this pattern to say that "throw" is not an operator and
somewhat inconsistent to say it is.

I can't find the consistent pattern. Or is it consistent to say
that static_cast is an operator, and const_cast isn't, simply
because the standard happens to use the word "operator" when
discussing static_cast, but doesn't when discussing const_cast?

The only "consistent" use I can see is the definition of an
expression: "An expression is a sequence of operators and
operands that specifies a computation." It's non-normative, but
it gives a good idea as two what the authors of the standard
were thinking when they use the word. And by that definition,
and the fact that the standard does speak of the operand of
throw, calling throw an operator is consistent. (But I would
insist that the distinction really isn't very important.)

Please have a look at clauses [2.11] (listing all keywords)
and [2.12] (listing all operators and punctuators).

Please read the first sentence of §2.12:

The lexical representation of C++ programs includes a number
of preprocessing tokens which are used in the syntax of the
preprocessor or are converted into tokens for operators and
punctuators:"

Note the relevance with regards to the preprocessor. The fact
that throw isn't in this list means that:

#define throw catch

is legal (unless you include a standard header, in which case,
§17.4.3.1.1/2 applies: "A translation unit shall not #define or
#undef names lexically identical to keywords").

That is, in fact, all it means.

As far as pure normative consequences are concerned, you are
right. However, the table so happens (maybe coincidentally) to
be compatible with the usage of the term "operator" elsewhere
in the standard: as mentioned above, I don't know of any
clause where the word "operator" refers to something whose
lexical representation is not listed in [2.12].

See my examples above. I wouldn't be surprised if there were
others.

Now, an interesting question is why new and delete are in that
table. The other "keywords" that appear there are truely
operators for the preprocessor; the preprocessor must be
evaluate them in the context of e.g. a #if (but then, that's
true of true and false, too). But the preprocessor doesn't
really care a bean about new and delete. On the other hand, it
has an "operator" which isn't in the list there: "defined".
Perhaps because it is only an operator in specific contexts.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Oct 4, 2:07 pm, "Victor Bazarov" <[e-mail]:

James Kanze wrote:

[...]

You're forgetting the comma operator, and ?:. Things like:

MyClass::MyClass( T arg )
: myMember( isValid( arg ) ? arg : throw "Invalid arg")
{
}

are perfectly valid and legal.

Yes, I did forget about those. I am guessing that's might be the
only reason to ever think of 'throw' as an operator. Of course, it
still does non yield any value and as such it's use in an expression
is rather special.

static_cast< void >( whatever ) doesn't yield any value, either.
Nor does calling a void function. Throw is an operator because
it can appear in an expression, and takes operands:-).

Seriously: it really doesn't matter what you call it, as long as
you understand that its use, other than as an exception
specifier, results in an expression. About the only place I've
seen any pratical importance as to whether something is an
operator or not is with comma:
f( (a, b, c) ) ; // The commas are operators.
f( a, b, c ) ; // And here they aren't.
But one might argue that such subtle distinctions are a defect
in the language.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Oct 4, 5:13 pm, Ranganath <[e-mail]:

On Oct 4, 11:05 am, Kai-Uwe Bux <[e-mail]:

Please have a look at "The C++ Programming Language" by Stroustrup 3rd
Edition, section 6.2.
It clearly mentions that throw is an operator in the table named
"Operator Summary".

Stroustrup believes in duck typing: it looks like a duck, walks
like a duck, and quacks like a duck, so it is a duck:-). In
this case, of course, it's used like an operator, so it's an
operator. Except, of course, when it isn't, e.g. in an
exception specification.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Kai-Uwe Bux]

James Kanze wrote:

On Oct 4, 9:28 pm, Kai-Uwe Bux <[e-mail]:

>James Kanze wrote:

On Oct 4, 8:05 am, Kai-Uwe Bux <[e-mail]:
Ranganath wrote:
On Oct 3, 8:46 pm, "Victor Bazarov" <[e-mail]:
Ranganath wrote:
Why is throw keyword considered as an operator?

>It is impossible to answer a question based on a wrong premise.
'throw' is not an operator. Why do you think it is one? Or,
rather, what do you mean "considered as an operator"? What is
the context?

throw is an operator.

>According to the language standard, "throw" is a keyword, not an
operator.

As far as I can see, the language standard doesn't define
operators. Without a definition, I'm incapable of saying
whether throw is an operator or not.

>Well: Yes and No. I agree that operator is not put in italics
anywhere in the standard. However, the word "operator" is
clearly used in the standard in many places refering to things
like "+". But nowhere in the standard is "throw" referred to
as an operator.

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]

On Oct 5, 10:21 pm, Kai-Uwe Bux <[e-mail]:

James Kanze wrote:

On Oct 4, 9:28 pm, Kai-Uwe Bux <[e-mail]:

[...]

[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 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]).

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]