It's not really a mistake if you know that the swapped objects are not the same. In a swap function, that is obviously an inappropriate assumption, but it isn't always.Originally Posted by CornedBee
I wasn't really being serious, though.
It's not really a mistake if you know that the swapped objects are not the same. In a swap function, that is obviously an inappropriate assumption, but it isn't always.
I wasn't really being serious, though.
It's still a mistake, because there is not advantage to the method.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
It requires no temporary variable.
> It requires no temporary variable.
Your point being?
By the time the optimiser (gcc) has finished with the second one, it has managed to simplify the code into printf("%d %d\n", b, a );Code:void foo ( int a, int b ) { a ^= b; b ^= a; a ^= b; printf( "%d %d\n", a, b ); } void bar ( int a, int b ) { int temp = a; a = b; b = temp; printf( "%d %d\n", a, b ); }
The temp and the swap are GONE.
Not so with the attempt to obfuscate the heck out of things in the mistaken belief that using a variable is the end of the world. As well as confusing the average reader, you also managed to hide the true intent of the code from the compiler as well.
Clear simple code wins every time. If you insist on treating C like some high level assembler, then expect to get the code you write.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
I think this reasoning is not quite right. That's not what you need swapping for, where you really need values relocated.
However, wouldn't xor be something more complicated as simple assignment? A quick test showed that using a temp is a bit faster.
If you have an optimizer...
I certainly don't believe that. And anybody who claims to know CS should know this property. I never said it should be used in real code.Not so with the attempt to obfuscate the heck out of things in the mistaken belief that using a variable is the end of the world.
You're preaching to a choir... Why did I post it in the first place? I dunno, I was bored. Had I known you would jump all over me I wouldn't have bothered.Clear simple code wins every time. If you insist on treating C like some high level assembler, then expect to get the code you write.
I'd never heard of this algorithm. The following talks about its efficiency vs. using a temporary.
http://en.wikipedia.org/wiki/XOR_swap_algorithm
Count yourself lucky.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
I would just like to point out at this time, that any method which has it's own GOSH DANG WIKI PAGE cannot possibly be "obscure." This is something a CS person should know. I didn't say "use," I said "know."
EDIT: Why should you know it? For one thing, it might be on your final in boolean algebra.
Honestly... It's only obscure if you don't know it. How is this any different than shifting right by one in order to divide an integer by 2? I think it's something a person should be aware of, not necessarily that they should put it into practice in new code.
If you understand it, then you can "fix" it when you see it in older code. Isn't that a good enough reason to be aware of it?
brewbuck: Your points are well understood by many of us here. We tend to be harsh on things that generally persuade young'uns to do the Wrong Thing, regardless of the intentions, merely -- hopefully -- to produce better programmers. There is no malice.
There are a number of things that are easily beaten up merely by presentation:
The XOR swap thing merely happens to be among them, but not (yet) in the FAQ.
- void main()
- fflush(stdin)
- gets(string)
- Etc.
I don't know, I guess that it's just a 25-year-old solution to a 30-year-old problem that some compilers may possibly now fix up bad programming idioms that may be common.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
Doesn't this have issues depending on the implementation?
(Seriously, it's been a long day and I'm forgetful.)
[edit]And frankly, fixing a problem that does not exist is in itself a problem.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
> This is something a CS person should know.
I'm a mathematician. I don't have a formal CS background.
I didn't mean you, personally. Sorry.
Yes, since the C++ Standard leaves the exact result of a right shift as implementation defined for negative integers. For non-negative integers it is quite clear that a division by the nth power of two will be performed. So, (1 >> 1) == 0, but (-1 >> 1) == 0 or (-1 >> 1) == -1 are both possible, as are other interpretations of what happens on a right shift (e.g., largest possible positive integer value).Doesn't this have issues depending on the implementation?
Look up a C++ Reference and learn How To Ask Questions The Smart Way
