throw operator

Discussion in 'C++' started by Ranganath, Oct 3, 2007.

  1. Ranganath

    Ranganath Guest

    Why is throw keyword considered as an operator?
    Ranganath, Oct 3, 2007
    #1
    1. Advertising

  2. 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
    Victor Bazarov, Oct 3, 2007
    #2
    1. Advertising

  3. 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
    =?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=, Oct 3, 2007
    #3
  4. 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
    Victor Bazarov, Oct 3, 2007
    #4
  5. Ranganath

    Ranganath Guest

    On Oct 3, 8:46 pm, "Victor Bazarov" <> wrote:
    > 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.
    Ranganath, Oct 4, 2007
    #5
  6. Ranganath

    Kai-Uwe Bux Guest

    Ranganath wrote:

    > On Oct 3, 8:46 pm, "Victor Bazarov" <> wrote:
    >> 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
    Kai-Uwe Bux, Oct 4, 2007
    #6
  7. Ranganath

    James Kanze Guest

    On Oct 3, 7:16 pm, "Victor Bazarov" <> wrote:
    > 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Oct 4, 2007
    #7
  8. Ranganath

    James Kanze Guest

    On Oct 4, 8:05 am, Kai-Uwe Bux <> wrote:
    > Ranganath wrote:
    > > On Oct 3, 8:46 pm, "Victor Bazarov" <> wrote:
    > >> 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Oct 4, 2007
    #8
  9. * 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 also provides a
    list of tokens (lexical section somewhere) that includes all operators,
    but unfortunately also punctuation symbols. 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.

    Cheers,

    - Alf

    --
    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?
    Alf P. Steinbach, Oct 4, 2007
    #9
  10. James Kanze wrote:
    > On Oct 3, 7:16 pm, "Victor Bazarov" <> wrote:
    >> 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
    Victor Bazarov, Oct 4, 2007
    #10
  11. Ranganath

    Ranganath Guest

    On Oct 4, 11:05 am, Kai-Uwe Bux <> wrote:
    > Ranganath wrote:
    > > On Oct 3, 8:46 pm, "Victor Bazarov" <> wrote:
    > >> 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, Oct 4, 2007
    #11
  12. Ranganath

    Ranganath Guest

    On Oct 4, 2:59 pm, James Kanze <> wrote:
    > On Oct 4, 8:05 am, Kai-Uwe Bux <> wrote:
    >
    > > Ranganath wrote:
    > > > On Oct 3, 8:46 pm, "Victor Bazarov" <> wrote:
    > > >> 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:
    > Conseils en informatique orientée objet/
    > Beratung in objektorientierter Datenverarbeitung
    > 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


    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
    Ranganath, Oct 4, 2007
    #12
  13. Ranganath

    Kai-Uwe Bux Guest

    James Kanze wrote:

    > On Oct 4, 8:05 am, Kai-Uwe Bux <> wrote:
    >> Ranganath wrote:
    >> > On Oct 3, 8:46 pm, "Victor Bazarov" <> wrote:
    >> >> 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
    Kai-Uwe Bux, Oct 4, 2007
    #13
  14. On 2007-10-04 21:28, Kai-Uwe Bux wrote:
    > James Kanze wrote:
    >
    >> On Oct 4, 8:05 am, Kai-Uwe Bux <> wrote:
    >>> Ranganath wrote:
    >>> > On Oct 3, 8:46 pm, "Victor Bazarov" <> wrote:
    >>> >> 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
    =?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=, Oct 5, 2007
    #14
  15. Ranganath

    James Kanze Guest

    On Oct 4, 12:34 pm, "Alf P. Steinbach" <> wrote:
    > * 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Oct 5, 2007
    #15
  16. Ranganath

    James Kanze Guest

    On Oct 4, 9:28 pm, Kai-Uwe Bux <> wrote:
    > James Kanze wrote:
    > > On Oct 4, 8:05 am, Kai-Uwe Bux <> wrote:
    > >> Ranganath wrote:
    > >> > On Oct 3, 8:46 pm, "Victor Bazarov" <> wrote:
    > >> >> 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Oct 5, 2007
    #16
  17. Ranganath

    James Kanze Guest

    On Oct 4, 2:07 pm, "Victor Bazarov" <> wrote:
    > 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Oct 5, 2007
    #17
  18. Ranganath

    James Kanze Guest

    On Oct 4, 5:13 pm, Ranganath <> wrote:
    > On Oct 4, 11:05 am, Kai-Uwe Bux <> wrote:


    > 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Oct 5, 2007
    #18
  19. * James Kanze:
    >
    > 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.


    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.

    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.

    James, would you, please?


    Cheers,

    - Alf


    PS: No "throw" there! :)


    --
    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?
    Alf P. Steinbach, Oct 5, 2007
    #19
  20. Ranganath

    Pete Becker Guest

    On 2007-10-04 23:58:10 -1000, "Alf P. Steinbach" <> said:

    > * James Kanze:
    >>
    >> 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.

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


    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.

    --
    Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
    Standard C++ Library Extensions: a Tutorial and Reference
    (www.petebecker.com/tr1book)
    Pete Becker, Oct 5, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kerri
    Replies:
    2
    Views:
    13,016
    Kevin Spencer
    Oct 27, 2003
  2. Replies:
    15
    Views:
    7,528
    Roedy Green
    Sep 8, 2005
  3. cai
    Replies:
    5
    Views:
    2,044
  4. Ralph Moritz
    Replies:
    1
    Views:
    316
    Salt_Peter
    Dec 21, 2006
  5. Emanuele D'Arrigo

    To throw or to throw not?

    Emanuele D'Arrigo, Nov 14, 2008, in forum: Python
    Replies:
    6
    Views:
    318
    Emanuele D'Arrigo
    Nov 15, 2008
Loading...

Share This Page