#include <stdio.h>
void fun(char a[]){
a[0]^=a[1]^=a[0]^=a[1];
}
int main(int argc, char **argv){
char b[10];
b[0]='h';
b[1]='j';
fun(b);
printf("%c",b[0]);
return 0;
}
What is wrong with this code. It shall swap the b[0] and b[1] but it is not swapping.
Undefined behavior for a[0]^=a[1]^=a[0]^=a[1];. Order of evaluation and assignment is not defined.
The "The New C Standard. An Economic and Cultural Commentary" book gives two variants of xor-swap at page 1104:
Example
1 #define SWAP(x, y) (x=(x ^ y), y=(x ^ y), x=(x ^ y))
2 #define UNDEFINED_SWAP(x, y) (x ^= y ^= x ^= y)
/* Requires right to left evaluation. */
So, the second variant is not portable and is incorrect.
Related
I'll be forthright about this: this one is for homework. However, as I've already completed the question and was just simply curious about different implementations of what I did, I thought it was okay to be consult y'all.
The question was to build a != function using bitwise operations. We are also allowed to use ! and +.
Returns 0 if x==y, otherwise it returns 1.
int eval_not_equal(int x, int y) {
int result = x ^ y;
if(result == 0) {
result = 0;
}
else {
result = 1;
}
return result;
}
I think this is a perfectly fine answer to the question, but I was wondering if it's possible to do this without using an if? There are quite a few different bitwise operations, and I'm sure there's gotta be a way to use them in order to replace the if that I used!
Would love to know what you guys think! :-)
I do not understand why you cannot use operator !=:
int eval_not_equal(int x, int y) {
return x != y;
}
but if that is some kind of challenge to avoid != in the code, then you can write like this:
int eval_not_equal(int x, int y) {
return !!(x ^ y);
}
In the code above, the result of x ^ y is treated as bool, then negated. The boolean equivalent of "false" is 0; "true" by default is 1 (but actually any non-zero integer is true)
If this is C++, or usage of stdbool is permitted (C99), then you can do also like this:
int eval_not_equal(int x, int y) {
return (bool) (x ^ y);
}
Update:
The question was to build a != function using only bitwise operations
If "only" is the key, then neither mine previous answers nor OP's solution are valid because ! is a boolean operator not bitwise. The same applies to type cast (bool) or if clause.
In my honest opinion, the following code is ridiculous, but it uses only bitwise operations:
int eval_not_equal(int x, int y) {
int xo = (x ^ y);
return (xo >> (ffs(xo) - 1)) & 1;
}
Function ffs() returns first set bit, i.e. the index of the first bit which equals to 1. We want only that bit, so we shift right the xor result by ffs - 1 to get rid of all lower bits, then do bitwise-and-with-1 to clear higher bits.
You could use double negation and a series of XOR's to accomplish this like this. This also works for negative numbers.
i32 is just a 32bit signed int
inline i32 negate(i32 x){ return ((x >> 31) | ((~x + 1) >> 31)) + 1; }
inline i32 ne(i32 a, i32 b){ return negate(a ^ b) ^ 1; }
int main(){
printf("result=%i\n", ne(-1, -1)); // 0
printf("result=%i\n", ne(-5, 0)); // 1
printf("result=%i\n", ne(0, 0)); // 0
printf("result=%i\n", ne(5, 5)); // 0
printf("result=%i\n", ne(1, 5)); // 1
printf("result=%i\n", ne(5, 1)); // 1
return 0;
}
You could just do the following:
return !(x ^ y);
Im having trubles to understand what it means when there is define and then two xor expressions. what this define does?
i try to send x=8, y=7 and the result was that x=15 and y=8
why its happand?
this is the program:
#define FUNC(a,b) a^=b; b ^=a;
int main(){
int x=8,y= 7;
FUNC(x,y);
printf("%d %d\n",x, y);
}
It is just the same as
int main(){
int x=8,y= 7;
x^=y; y ^=x;;
printf("%d %d\n",x, y);
}
because the define will just be a simple text substitution, i.e. all places with awill be replaced by x and all places with b will be replaced with y.
The ^ is a bit wise XOR operator.
So first x = 8 ^ 7 = 15 then y = 7 ^ 15 = 8
This is because XOR produce 1 when one of the bits but not both are 1
x = 8 = 0b00000000000000000000000000001000 // Assuming 32 bit int
y = 7 = 0b00000000000000000000000000000111 // Assuming 32 bit int
x=x^y = 0b00000000000000000000000000001111 = 15
x = 15 = 0b00000000000000000000000000001111 // Assuming 32 bit int
y = 7 = 0b00000000000000000000000000000111 // Assuming 32 bit int
y=y^x = 0b00000000000000000000000000001000 = 8
^^^
Zero because both bits are 1
More to the original question:
This macro has the first two steps of the bit-wise method to exchange two values:
(1) a ^= b
(2) b ^= a
(3) a ^= b
Let's expand this a little: let x = a; y = b, and we'll trace the algebra through terms of x and y. First, replace each "update" with its full expression:
(1) a = a ^ b
(2) b = b ^ a
(3) a = a ^ b
Now, substitute x and y, trickling down from top to bottom:
(1) a = x ^ y
(2) b = y ^ (x ^ y)
(3) a = (x ^ y) ^ (y ^ (x ^ y))
Drop the parentheses and rearrange terms:
(1) a = x ^ y
(2) b = x ^ y ^ y
(3) a = x ^ x ^ y ^ y ^ y
... leaving us with b = x; a = y
Now, since you have only the first two steps, your final result is
b = x (original value of a)
a = x ^ y (a.k.a. a ^ b)
Does that explain the immediate problem for you?
The canonical way to #define multi-statement macros is
#define FUNC() do { statement1; statement2; } while(0)
That way even if(b) FUNC(); does what the caller thinks.
There has been a discussion a few years ago which led to a change in the MISRA rules concerning this; MISRA does not recommend the "do" strategy any longer, because they say one should always use curly braces, as in if(b) { FUNC(); } which would handle unprotected multi-statement macros gracefully (and prevent bugs like the Apple certificate goto screw-up). Instead, a do{... would camouflage the failure to use braces.
I think I personally still side on the doside, if only because I know it.
CERT recommends the technique as well.
Often and often I felt some of the parentheses around arguments in macro definitions were redundant. It’s too inconvenient to parenthesize everything. If I can guarantee the argument needs not be parenthesized, can I omit the parentheses? Or is parenthesizing them all highly recommended?
I came up with this question when I wrote:
#define SWAP_REAL(a, b, temp) do{double temp = a; a = b; b= temp;}while(0)
I think that if an argument appears as an l-value in the macro, the parentheses can be omitted because that means the argument appears with no other operation.
My reasoning is:
The associative priority of assignment symbols is merely higher than comma’s.
You cannot confuse the compiler into thinking that your argument is an expression with a comma in it. For example, SWAP(a, b, b) will not be interpreted successfully as
do{double temp = a, b; a, b = b; b= temp;}while(0)
which can pass compilation.
Am I right? Can anyone give me a counter-example?
In the following example,
#define ADD(a, b) (a += (b))
I think the argument a needn’t be parenthesized. And in this specific case, neither needs the argument b, right?
#JaredPar:
#include <stdio.h>
#define ADD(a, b) (a += (b))
int main(){
int a = 0, b = 1;
ADD(a; b, 2);
return 0;
}
This cannot be compiled successfully on my VS2010. Error C2143: syntax error : missing ')' before ';'
In a nutshell, you don’t need to parenthesize the arguments having appeared as an l-value in the macro, but you are highly recommended to parenthesize them all.
Rules of Macros:
DO NOT make macros with side effects!
As for macros with no side effect, just parenthesize all the arguments without second thought!
As for macros with side effect, stop being obsessive! Parenthesize them all! TnT
Here is one case where it makes a demonstrable difference
ADD(x;y, 42)
With parens this leads to a compilation error but without it leads to code that compiles.
(x;y) += 42; // With parens errors
x;y += 42; // Without parens compiles
This may look like a silly example but it's possible combining macros together can easily lead to strange code expressions like the above.
Why take the chance here? It's just 2 characters
It's unsafe to omit if you use any operator that isn't lowest precedence in your expression. I believe that would be comma.
a op b where op is some operator like +, * etc. will always bind wrong if a contains an expression of low precedence like 1 || 2.
Note I'm not claiming it's safe in those cases. There are more creative ways to break macros. By the way, don't use macros with side effects in the first place. More generally, don't use macros as functions. (See, e.g., Effective C++).
There are macros where you're concatenating elements to make a string (perhaps using the # operator), or building identifiers out of macro arguments using the ## operator. In such cases, you don't parenthesize the arguments.
Also, I think that when the macro arguments are themselves passed as function arguments, then you don't absolutely have to parenthesize them:
#define CALLOC(s, n) calloc(s, n)
You can play fiendish games calling such a macro (CALLOC({3, 4})), but you get what you deserve (a compilation error) — I'm not aware of a way of calling that macro that would work if instead of the macro you wrote the same arguments as a direct call to calloc().
However, if you are using the arguments in most arithmetic expressions, then you do need to wrap them in parentheses:
#define MIN(x, y) (((x) < (y)) ? (x) : (y))
Obviously, if you invoke it with arguments with side effects, then you get what you get. But the arguments won't be misinterpreted as they could be if you wrote:
#define MIN(x, y) x < y ? x : y
and then invoked it as:
MIN(x = 3 * y + 1, y = 2 * x - 2);
The comment by Moon suggests a SWAP_INT macro.
The following code using that macro compiles cleanly when compiled using default options, but fails to compile with -DWITH_PARENTHESES set.
#include <stdio.h>
#ifdef WITH_PARENTHESES
#define SWAP_INT(a, b) do { int temp = (a); (a) = (b); (b) = temp; } while (0)
#else
#define SWAP_INT(a, b) do { int temp = a; a = b; b = temp; } while (0)
#endif
int main(void)
{
int p = 319;
int q = 9923;
int x = 23;
int y = 300;
printf("p = %8d, q = %8d, x = %8d, y = %8d\n", p, q, x, y);
SWAP_INT(p, q); // OK both ways
SWAP_INT(x, y); // OK both ways
printf("p = %8d, q = %8d, x = %8d, y = %8d\n", p, q, x, y);
SWAP_INT(x /= y, p *= q); // Compiles without parentheses; fails with them
printf("p = %8d, q = %8d, x = %8d, y = %8d\n", p, q, x, y);
return 0;
}
The output:
p = 319, q = 9923, x = 23, y = 300
p = 9923, q = 319, x = 300, y = 23
p = 41150681, q = 13, x = 0, y = 3165437
That isn't a safe or effective way of swapping integers — the macro without the parentheses is not a good idea.
JFTR: when compiled without -DWITH_PARENTHESES, the line for the macro with the expressions is inscrutable:
do { int temp = x /= y; x /= y = p *= q; p *= q = temp; } while (0);
Normally, a swap macro expects two variable names — or array elements, or structure or union members, or any mix of these. It does not expect to be given arbitrary expressions. The parentheses ensure that the assignment to x /= y (which is not an lvalue) fails; without the parentheses, the expression is interpreted, but it isn't anything like what was intended (if, indeed, anything could be intended when 'swapping' two expressions like that).
How can i use square?
For example below calculation:
2^4=16
But when i do this the result is:6
Is there any library for this calculation without using multiplication?
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]) {
int c,a=2,b=4;
c=a^b;
printf("%d",c);
return 0;
}
and How i can use radical in C?
In C, ^ is the XOR operator. 2 XOR 4 does indeed equal 6.
You should include the math.h header file:
#include <math.h>
double pow( double base, double exp );
...
x = pow(2, 4);
^ in C is the XOR operator.
Use pow() for what you want to achieve, like;
c = pow(a, b);
When linking your program you might need to reference the math library, by adding the linker option -lm.
Referring the update to your question: Use sqrt():
double x = sqrt(4); /* Results in 2. */
Or simply use:
... = pow(4, 1./2.); /* Also results in 2. */
or
double y = pow(8, 1./3.); /* To also find 2. */
In general this formular applies:
Programmatical this can be done by:
/* Return n-th radical root of the m-th power to x. */
double nrt_mpow(doubel x, double m, double n)
{
return pow(x, m/n);
}
/* Return n-th radical root of x. */
double nrt(double x, root n)
{
return nrt_mpow(x, 1, n):
}
Or alternativly implemented as macros:
#define NRT_MPOW(x, m, n) pow((x), (m)/(n))
#define NRT(x, n) NRT_MPOW((x), 1., (n))
The header to the math library is:
#include <math.h>
And instead of ^, C uses pow().
c = pow(a,b);
The operator ^ is not power in C language. You should use pow(a,b).
There is a header file math.h. You can use numerous mathematical function which are written there.
pow() function of math.h is the tool you want for exponentiation.
Given:
#define f(x, y) (x+y)
#define g(x, y) (x*y)
#define A 1, 2
#define B 2, 3
int main() {
int a = f(A);
int b = g(A);
int c = f(B);
int d = g(B);
}
which does not work,
how can I make it work? The basic idea is that I have one list of arguments that I want to pass to two different macros, without repeating the list of long arguments every time.
Is there a way to do this? [You're welcome to modify f & g; you're even welcome to modify A & the way I call the macros. The only requirements are:
1) the arguemnt list can only appear once
2) it can't be hard coded ... so that I can call the macros with different arguments
If you're solution doesn't quite work but 'almost works' (for you definition of almost), I'd like to hear it too, perhaps I can fudge it to work.
Thanks!
Edit: f & g must be macros. They capture the symbol names and manipulate them.
You could do this:
static int f(int x, int y) { return (x+y); }
static int g(int x, int y) { return (x*y); }
#define A 1, 2
#define B 2, 3
If you were using a C compiler that supported a nonstandard inline directive, you could eliminate the overhead of a function call. And if you were using C++,
template<T> T f(T x, T y) { return (x+y); }
template<T> t g(T x, T y) { return (x*y); }
#define A 1, 2
#define B 2, 3
which would work roughly the same as your intended C macro solution.
If f and g must be macros, there isn't any way with the C preprocessor to pass multiple arguments to the macros without an actual comma appearing at the invocation site. In order to do that, you would have to add a pre-preprocessor level above the C preprocessor.
If you were using C99, you can use the compound initialiser syntax to do this by passing multiple arguments as a single array:
#define f(a) (a[0]+a[1])
#define g(a) (a[0]*a[1])
#define A ((int[]) {1, 2})
#define B ((int[]) {2, 3})
GCC supports this compound literal syntax in both C89 and C++ mode.
EDIT: A version that works with unmodified A and B
#define f(x, y) (x+y)
#define g(x, y) (x*y)
#define A 1, 2
#define B 2, 3
#define APPLY2(a, b) a b
#define APPLY(a, b) APPLY2(a, (b))
int main(int argc, char* argv[])
{
int x= APPLY(f, A);
int y= APPLY(f, B);
int z= APPLY(g, A);
int d= APPLY(g, B);
return 0;
}
Maybe this is what you want:
#include<iostream>
using namespace std;
#define A 1, 2
template <typename T>
inline T f(T a, T b) { return a + b; }
int main()
{
cout << f(A) << endl;
return 0;
}