The temp variable option is more than likely quicker in most cases, but speed isn't the point for the XOR trick - it's allocation of storage.
AIUI, in nearly all cases at that sort of level of code your compiler probably wouldn't bother using a location in RAM for the temporary variable (probably use a register or something) so it's, as someone else said, a bit of a pointless function.
FWIW - I've used that on interviewees, but the other way round; I showed them the function and asked them what it does. The number of interviewees I've had who didn't even know ^ was XOR, or didn't know what XOR did is actually quite high (but then it wasn't me who read the CVs and chose who to interview!).
I think I've mentioned on this group previously an associate who begins each interview with "Are you any good?" for much the same reasons.
The three XORs to swap trick is exactly that: a trick. Knowing it or not knowing it is neither here nor there, particularly as there are concerns about using it in terms of legibility, its performance on pipelined processors, etc.
However, I could see an argument that having encountered it somewhere, especially in a discussion such as this, is an indication of a stronger candidate. It isn't the kind of thing that you see in books and if it is mentioned at all at university then it is probably only in passing as an aside. It is something that you either encounter in the wild (which is not how I suspect most here first heard of it) or via general discussions with others in the field, maybe in person, maybe online.
In the first case, sure you got lucky and tripped over it somewhere. Hearing about it in discussion, OTOH shows that you _have_had_ those kinds of discussion, not just about this but presumably on a wide range of other issues. Those discussions presumably not only cover this but a wide range of other 'trivia', opinions, experiences etc that the candidate can draw on as and when required. It also suggests you can communicate meaningfully with your peers and have an interest in the field that goes beyond the bare essentials needed to do your current job.
I'm not suggesting for a moment that someone is going to hire a particular candidate because they may have read a few articles on usenet, but exposure to the opinions, ideas, and experiences of others is something that is potentially valuable. After all, you are limited in how much you can accomplish first hand. If you are familiar with the problems that have been faced by others, that gives you a much greater (although indirect) experience base to work with.
I had that sort of question. The answer was "compared to what/who?"
I couldn't agree more.
Exactly. It comes down to approach to problem solving and experience. When asked some of these questions I would ask why they are being asked. Do you really want to know if I know that trick or do I need to know the reason for the question. IE The question is the symptom not the cause.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
Glitches like that usually occur when one uses a "popular compact form" of this trick
a ^= b ^= a ^= b;
This variant is invalid from C/C++ point of view (produces undefined behavior), which might manifest itself in the form of the "incorrect" assembly code like the one you provided in your example.
However, when the variable modifications are properly separated by sequence points (as in your C code), this trick is supposed to work (ignoring the potential overflow issue). If your compiler generates such assembly code even in this case, then the compiler must be broken.
I've seen even much more in production codes. A good reference is e.g. the Cooley-Tukey algorithm. Big things grow out from smaller things. All these little tricks excercise your brain.
Once I've read a following joke in a programming errs and traps book:
Implement a block that inputs either 1 or 2 and outputs the opposite:
1 -> 2, 2 -> 1 The author continue with three hypotetical solutions:
A programming class instructor: if ( x == 1) x = 2; if ( x == 2) x = 1;
A programmer: if ( x == 1) x = 2; else if ( x == 2) x = 1;
I was commenting on your attitude to social interaction and dealing with managers etc You appear to have compounded that. I, and I think many managers would think twice about employing you from you last post.
Managers are there to manage and have different constraints to programmers. Also their technical expertise may come from a different area of programming. I once did a smart card project with a project manager who had come from a UNIX background. Very good project manager but did not know some of the low level things in smart cards. We had to explain some of these to him. Armed with the over view and some of the other significant technical points along with his own experience of developing he could manage the project very well. Better than any of the programmers could.
The fact that you have difficulty explaining parts of your work and interacting with managers is not a good sign. It also appears that you have little or no understanding of the management role or how to communicate with managers.
People forget that these days HR often do a search on candidates on the net. I suppose that is why you use a fake email address? Not prepared to stand by your own words?
Everyone knows who I am... Been around on line since 1990. You must be new here.
I don't normally include the company address as is not proper to advertise on this NG. I could post the full sig I suppose but that would be a bit much
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
Yeah I know now as a couple of people have pointed out! :-) I was so pleased with myself for working out the method that I didnt't bother to check if it could be simplified.
Another dirty trick -- actually the same: a flag to tell whether succeeding messages in a serial stream are one byte each or two bytes each (only two possible cases, but lucky for me the MIDI spec is mature in that regard.) For 1-byte messages flag = 0; for 2-byte messages flag = -1;
Then for each byte received flag = -flag; and flag non-negative means a complete message.
Xor is just one half of a addition without overflow (the other part is AND)
xor does not destroy information. it just mixes-up information. therefore for swapping integers it works just as good as addition except that xor does not overflow.
In this context it's identical, somewhat... well... ehm... hard to explain.... don't get me started about galious-fields, where xor may suddenly becomes multiply ect.
For software-guys xor is just a niffy thing. hardware-guys (hello vhdl) do know that you can hardly live without it... Basic building block of everything. most software-people just don't know.
Hi, The last mathematicians way of doing was good thought.Though its simple and quite obvious,generally atleast to me it wont strike to do that way of doing the code.I would go for a programmers way of doing.That explains somewhat where I can try to think different! By the way as a matter of interest where did you come across this piece?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.