The operator '&' can be used in both of following way int a; scanf("%d",&a);
and printf("%d",1&2).
But different behaviour (for first as address operator and second time as bit-wise operator).
I know operator overloading is not there in C. Then how it works ?. Also highlight for c++.
I know operator overloading is not there in C.
This is incorrect. a + b performs integer addition if a and b are integers, floating-point addition of a and b are floating-point numbers, and pointer arithmetic if a or b is a pointer.
C has operator overloading built into the language. It does not support custom operator overloading defined by the program.
In the case of & being an operator for taking an address and for performing a bitwise AND, the distinction is made by the language grammar. The & for taking an address can appear only applied to a cast-expression in the grammar. The & for bitwise AND can appear only after an AND-expression and before an equality-expression. These “tokens” (cast-expression, AND-expression, and equality-expression) may be unfamiliar to you, but they are formally defined in the grammar for the C language, and, as the compiler is parsing source code, it recognizes the structure of expressions and matches the source code to the tokens of the grammar. This is also true for C++ except for a minor technical difference: In C++, one of the tokens is and-expression instead of AND-expression.
The definition of the grammar is such that recognition of these tokens always uniquely distinguishes how the & operator is being used.
In "C" language, operators have different meaning when they are used as prefix to expression, suffix to expression or "infix" (between two expressions).
Consider '*', which performs multiplication as 'infix' operator, and pointer indirection when used as a prefix. Similarily, the '-' operator, which performs subtraction as 'infix' operator, and negation when used as a prefix.
Basically, it's not about overriding, it if the operator appears between two expressions, or as a prefix to a single expression.
In the same way, The "C" compiler knows if the '&' is bit-wise and, or address-of, based on it's position is the expression: If it is between two expressions, it's the AND, if it is before an expression, it is 'address-of'.
See https://en.wikipedia.org/wiki/Infix_notation about infix.
C does not support operator overloading (beyond what it built into the language).
As you can see in this Wikipedia Operators in C
The Address-of ("address of a") "&a" is defined as R* K::operator &();
whereas
The Bitwise AND "a & b" is defined as R K::operator &(S b);
So basically the "&" operator has different meaning when used as a unary operator and as a binary operator operator. The same goes for various other operators like, "*" , "-", etc.
It has simple different meanings when applied to the lvalue (it the unary operator in this case) or when it is used in the math expression with two operands.
"The operator & can be used in both of following way int a; scanf("%d",&a); and printf("%d",1&2)."
Note that in the case of C++ you forgot another important third use. The & operator can also be used to declare references.
int x = 24;
int& r_x = x;
the language divides operators based on its operands first. In one category itself overloading can be in-built. Your example is about the first division. Address-of is a unary operator and bitwise-AND is a binary operator. when you write operator function in c++ you will see the difference of these two categories.
Operator overloading is inbuilt to languages. example simple arithmetic addition operator. it can work with simple one-byte integer data as well as float (significant & exponent). Basically it is there with maths. so while making C language, they just translated those into functionality. In C specification, you cannot find overloading as a keyword for this behavior. According to them, after formula expression, anything has to be expressed as different functions. Each function should be named based on the functionality that it offers. When C++ introduced an opportunity to create new types, operators with its basic n-nary form allowed to operate with new types. In a nutshell, C's philosophy was different.
Related
if(a .feq. 5.0_dp) then **** if(a .fne. 5.2_dp) then ***
I come across some codes like this. What does the .feq. or .fne. mean? Is it "=" or "\ =" ?
In Fortran, operators (unary or binary) can take this form, a string of letters (up to 63) with a . at either end. So .feq. and .fne. are operators.
We'll also see operators such as .not., .eq. and so on.
Some operators, such as the two just mentioned, are standard intrinsic operators, some may be non-standard intrinsic operators, and we can even have user defined operators.
.feq. and .fne. are not (Fortran 2018) standard intrinsic operators. They may be non-standard intrinsic operators, but most likely they are user-defined. As they are not standard operators, we cannot say what they do (although as veryreverie comments, we can make reasonable guesses).
You will need to read the documentation for the project (or compiler, for the case of non-standard intrinsic operators), or you can look at the available source code.
How will you find what a user-defined operator does? For .feq. for example you should find an interface block with the OPERATOR(...) syntax:
interface operator (.feq.)
...
end interface operator (.feq.)
Inside that interface block you'll find mention of one or more specific functions, much as you would with other generic functions. Check these functions until you find one with the right number of arguments (one for a unary operator, two for a binary) of the right type (first argument matching the one after the .feq. if it's unary; or to the left if it's binary, with the second argument the right). You can then see what this function does.
You may also find your IDE or other tools will tell you how the operator is resolved.
I would like to overload the operator~ but not as an unary operator but as an binary operator so i can do thinks like a~b. is there a way doing this in c++?
There is no way of doing this in C++. Period.
You could change the behavior by operator overloading, but you couldn't change the number of operands.
It is not possible to change the precedence, grouping, or number of operands of operators.
About halfway down this page there is a "Restrictions" section which states: "New operators such as **, <>, or &| cannot be created".
I know that ** is the exponentiation operator from python, and I know that <> is the "spaceship" (compareTo) operator from PHP. What on earth is &|?
correction <=> is the "spaceship", <> is a common substitute for !=
What the page is trying to say is that you can't create operators in C++ that doesn't already exist as operators. In other words, <> is not an operator in C++ today, so you can't do T operator<>(U x, U y) to define what this operator does. It's an invalid combination. Likewise for the other "symbols" listed. C++ defines a given set of operators, +, -, %, /, *, <<, >> and many more. These are allowed to override (with user-defined types). But the language does not allow the programmer to invent his/her own symbols and making them into operators.
This helps the parsing of the code by having a fixed set of operators that are lexically well-defined. That's aside from the confusions that this would cause when you read
if (x <&^> y) ...
or
x = y +- 11;
[What the heck is <&^> or +- supposed to mean?]
Sure, it's also possible to cause confusion with the existing operators, but it's at least somewhat less confusing than the programmer making up his/her own versions and variants.
The fact that some other language does have meanings for other symbols is up to those languages. Until the symbol is available in C++ (and some new operators are introduced at times, although quite rarely), they are not valid as C++ operators.
The only usage of &| is called: bit wise operators..
It's not used in a programming language, but to express something..like: I want to know if the result and/or (&|) matches something..
By reading the book "C++ Primer" and wikipedia, I notice both mentioned that "precedence and associativity defines the grouping of OPERATORS". However, it appears to me the examples they given were showing grouping of OPERANDS. Here I quote:
from "Defined terms # C++ Primer 5th edition":
associativity: Determines how OPERATORS with the same precedence are
grouped.
from Operator_associativity # Wikipedia:
Consider the expression a ~ b ~ c. If the operator ~ has left
associativity, this expression would be interpreted as (a ~ b) ~ c. If
the operator has right associativity, the expression would be
interpreted as a ~ (b ~ c).
But from what I see, the above explanation grouped two OPERANDS (not operators): a and b into (a ~ b), or b and c into (b ~ c). Because I see they parenthesized two operands, but not two operators.
Given that operator and operands are different concepts, does the precedence and associativity rule group operator or operands ?
Thanks in advance.
Precedence and associativity address how a language interprets parenthesis-free expressions involving three or more operands. I'll use the symbols # and # to denote two operators. Consider the expressions
a # b # c,
x # y # z,
d # e # f, and
u # v # w.
Note that the first two expressions involve different operands. The C++ precedence rules determines whether a#b#c is interpreted as meaning (a#b)#c or a#(b#c), and whether x#y#z is interpreted as meaning x#(y#z) or (x#y)#z.
The latter two expressions involve the same operand. Precedence has no bearing here. It's associativity that determines whether d#e#f is interpreted as meaning (d#e)#f or d#(e#f), and whether u#v#w is interpreted as meaning (u#v)#w or u#(v#w).
C++ has a large number of operators. There's an easy way to deal with the plethora of precedences: Use parentheses. My rule is "Everyone knows a*b+c means (a*b)+c. Nobody but a language lawyer knows whether a?b:c=d means (a?b:c)=d or a?b:(c=d). Use parentheses when in doubt."
Note: Apparently even Microsoft and wikipedia don't know the correct answer to "What does a?b:c=d mean?", at least as of June 16, 2014. The precedence tables at wikipedia and Microsoft have the ternary operator separate from the lower precedence assignment operators, which is incorrect. That would mean a?b:c=d needs to be interpreted as (a?b:c)=d, which always assigns the value of d to b or c, depending on whether a is true of false. That is incorrect. The correct interpretation is a?b:(c=d). The precedence tables at cppreference.com and cplusplus.com correctly group the ternary operator with the assignment operators.
There's an even better solution to puzzling out what the standard says: Just use parentheses.
Given that operator and operands are different concepts, does the precedence and associativity rule group operator or operands ?
Both. It groups operands and the corresponding operator(s). In:
(a ~ b) ~ c
you are grouping a and b, which are operands, by the ~ operator. Precedence and associativity are properties only of the operand, though.
The associativity rules of a language specify which operator is evaluated first when two operators with the same precedence are adjacent in an expression.
The precedence rules of a language specify which operator is evaluated first when two operators with different precedence are adjacent in an expression.
Wiki says:
[..] the associativity (or fixity) of an operator is a property that determines how operators of the same precedence are grouped in the absence of parentheses. If an operand is both preceded and followed by operators (for example, "^ 4 ^"), and those operators have equal precedence, then the operand may be used as input to two different operations (i.e. the two operations indicated by the two operators). The choice of which operations to apply the operand to, is determined by the "associativity" of the operators.
This means that operators are grouped among the operands and operands are grouped among the operators.
Are operator precedence & associativity rules ever violated in any C/C++ expression?
If so, can you give an example?
Assume the claims of precedence and associativity rules are:
Each operator has a given precedence level, and each precedence level has a given associativity. If a sub-expression is seen by two operators where they expect an operand, it belongs to the one with higher precedence. Ties are broken by associativity.
Edit: Background
The standard defines C/C++ expressions as a CFG, which is much more flexible than a precedence-based parser. For example, it would have been possible to give binary operators asymmetrical "precedence", which would have rendered any precedence table incorrect. However, it appears to me that the design of the grammar was constrained to uphold simple precedence rules. Here are some alleged "counterexamples" that I have come across:
1) a?b,c:d is not interpreted as (a?b),(c:d)
Some claim that the ?: operator exhibits different precedence towards its middle operand than towards its other operands, because a?b,c:d, for example, is not interpreted as (a?b),(c:d). However, neither b nor c occupies a position in which it appears to ?: as its inner operand. By that reasoning a[b+c] should be interpreted as (a[b)+(c]), which is ludicrous.
2) sizeof(int)*a is interpreted as (sizeof(int))*a rather than sizeof((int)(*a))
... because C disallows an uparenthesized cast as sizeof's operator. However, both of these interpretations conform to precedence rules. The confusion comes from the * operator's ambiguity (Is it the binary or the unary operator?). Precedence tables are not meant to resolve operator ambiguities. They are, after all, not operator-symbol-precedence tables. So the operator precedence rules themselves are intact.
3) a+b=c results in syntax error, not semantic error
a+b=c, according to the standard, is invalid C syntax. If C had had a precedence-based parser, it would only have been caught at the semantic level. In C, it so happens that any expression that is not a unary-expression cannot be l-valued. These semantically doomed LHS expressions therefore do not need to be accommodated syntactically. It makes no difference to the language as a whole, and precedence tables needn't be in the business of predicting the syntacticness/symanticness of the error that is going to result from an expression.
For one example, the usual precedence table says that sizeof and cast expressions have the same precedence. Both the table and the standard say that they associate right-to-left.
This simplification is fine when you're looking at, say, *&foo, which means the same as *(&foo).
It might also suggest to you that sizeof (int) 1 is legal C++ and that it means the same thing as sizeof( (int) 1 ). But it's not legal, because in fact sizeof( type-id ) is a special thing of its own in the grammar. Its existence prevents sizeof (int) 1 from being a sizeof expression whose operand is a cast-expression whose operand is 1.
So I think you could say that the "sizeof ( type-id )" production in the C++ grammar is an exception to what the usual precedence/associativity tables say. They do accurately describe the "sizeof unary-expression" production.
It depends on whether the "rules" are correct. The language definition doesn't talk about precedence, so the precedence tables you see in various places may or may not reflect what the language definition actually requires.
Until someone can find a counterexample, I'm going to put forward this as the default answer:
No, C/C++ precedence and associativity rules are never violated.