"Paul Herring" <[EMAIL PROTECTED]> wrote:
> From: Paul Herring
> > Time to get an FAQ set up in the group pages I think. Starting to
> > get sick of seeing this subject on various groups...
IIRC, _you_ were the one who accepted the post that caused the most
recent tiresome thread. ;)
You could always introduct a bit count macro to divert attention. :-)
> First draft - comments requested: <http://tinyurl.com/3zkbd>
"Assembler arithmetic 'trick'
Another similar method relies on addition and subtraction:
a = a + b
b = a - b
a = a - b
Similar example (presuming twos complement):"
AFAIK, it's not really an 'assembler trick', more of a 'maths' trick.
Inserting a diagram might help the curious...
instruction a b
---------------------
x y
a := a + b
x+y y
b := a - b
x+y x
a := a - b
y x
-
"The XOR trick can only be used in C and C++ if the the variable
is of type int. (This includes long, char and any type that is a
typedef of these.)"
This is poorly phrased. ITYM 'integer' instead of int, but the XOR
trick still has problems for negative integer values, e.g. swapping x
and -x in a signed magnitude representation may produce a trap
representation. [Note that under C99, INT_MIN can also be trap
representation, even on twos complement systems.]
"Constraints
2: Each of the operands shall have integer type.
Semantics
3: The usual arithmetic conversions are performed on the operands.
4: The result of the ^ operator is the bitwise exclusive OR of
the operands (that is, each bit in the result is set if and only
if exactly one of the corresponding bits in the converted operands
is set).
I've highlighted the relevant points in red. Note that floats are
converted into integers, then XOR'd; ..."
Where does the standard say that?
The constraint (2:) does not imply an implicit conversion. The
conversion you describe is not mandated by 'usual arithmetic
conversions' either. An int may be implicitly promoted to float,
but not the other way around.
Even if you're talking about float and pointer _representations_
(i.e. bytes) being xor-ed, that's not really being 'converted to
integers' in the sense of 6.3 (Conversions).
"this clearly will not do what you want. Pointers likewise are
converted into ints, ..."
Likwise above... :-)
"Attempting to swap using XOR by reference in C and C++
...
void swap(int* a, int *b){
a = a ^ b;
b = a ^ b;
a = a ^ b;
}"
ITYM to use *a and *b here, or &a and &b in the function declarator.
"Attempting to swap using use arithmetic in C and C++"
^^^
Typo.
"a = a + b
b = a - b
a = a - b
...
A similar problem could arise if using pointers."
I don't think the case is really worth mentioning. The 'sum' of two
pointers is not defined by the standards. [Note also that if a and b
are pointers, then a + b is a constraint violation.]
You haven't meantioned that both methods raised are really just
obfuscations now and shouldn't be used in commercial programming.
You should also say that, if asked in an interview, the answer should
be "if such a method is important to you (the employer), I'd rather
work elsewhere." ;)
--
Peter
To unsubscribe, send a blank message to <mailto:[EMAIL PROTECTED]>.
| Yahoo! Groups Sponsor | |
|
|
Yahoo! Groups Links
- To visit your group on the web, go to:
http://groups.yahoo.com/group/c-prog/
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
