swap two integers without using a tmp variable?

[Karl Heinz Buchegger]

On what platform? On x86 it works fine.

Try

#include <iostream>
using namespace std;

int main()
{
double a = 0.00000001;
double b = 100000000.0;

cout << a << " " << b << endl;

b = a + b;
a = b - a;
b = b - a;

cout << b << " " << a << endl;

}

On my Windows machine the output is:

1e-008 1e+008
1.49012e-008 1e+008

 

[Maxim Yegorushkin]

Try

#include <iostream>
using namespace std;

int main()
{
double a = 0.00000001;
double b = 100000000.0;

cout << a << " " << b << endl;

b = a + b;
a = b - a;
b = b - a;

cout << b << " " << a << endl;

}

On my Windows machine the output is:

1e-008 1e+008
1.49012e-008 1e+008

I don't think this is a legitimate example here.

The topic is about integers, not doubles. They are rather disparate subjects.

Floating point arithmetics has limited precision. What you are doing here - adding/substracting disparately huge and small floating point numbers - is no way to go if you want to keep rounding errors at minimum.

 

[JKop]

Maxim Yegorushkin posted:

I'd like to know about architectures where that code does not work. I'm
curious if there are processors where addition/substruction processor
command does not wrap result using modulo.

Post here what size your:

char

short

int

long


are, and I'll give you some numbers to try. Alternatively:


a = INT_MAX / 2;

b = INT_MAX / 2 + 48;


-JKop

 

[Maxim Yegorushkin]

Post here what size your:

I only have access to x86 platforms (linux/windows) these days.

char
1


2


4


4

are, and I'll give you some numbers to try. Alternatively:


a = INT_MAX / 2;

b = INT_MAX / 2 + 48;

I think there is nothing to try. On x86 equivalent assembly code looks like:

mov eax, [a]
mov edx,
add eax, edx
sub edx, eax
sub eax, edx
mov [a], eax
mov , edx

which wraps the results of add/sub on modulo 2^32, so that it always gives the right answer.

 

[Peter Koch Larsen]

"Victor Bazarov" <[email protected]> skrev i en meddelelse
Very clever! I just tested it:
int i(42);

victors_swap(i,9);

Argh.... that should be swap(i,i), of course ;-((

 

[Maxim Yegorushkin]

I think there is nothing to try. On x86 equivalent assembly code looks like:

mov eax, [a]
mov edx,
add eax, edx
sub edx, eax
sub eax, edx
mov [a], eax
mov , edx

Sorry, the code is wrong (I was in a rush being waited by starving people heading for lunch ).

which wraps the results of add/sub on modulo 2^32, so that it always gives the right answer.

But this is right.

 

[Karl Heinz Buchegger]

I don't think this is a legitimate example here.

The topic is about integers, not doubles.

The topic is to write a swap function without
using a temporary.

 

[Karl Heinz Buchegger]

The topic is to write a swap function without
using a temporary.

Ooops. Sorry.
The subject lines clearly states: integers

My fault

 

[Niklas Borson]

Niklas Borson wrote:


In your case, and *only* your case.

By "this case" I was referring to the XOR trick for swapping
integers, not to any particular hardware platform or other
circumstance. I don't believe there's ever a good reason to
use the XOR trick in C++ for the reasons I gave (which you
snipped).

Re-read the thread, there are several responses which more or less state 'there
is no good reason to do it' -- which is an inappropriate blanket statment and
definitely inside the box mentality.

I agree with those responses. There is no reason to use this
particular trick in C++. It's clever. It's fun. But it has
no practical value.

I'm not saying one shouldn't care about performance, or that
one shouldn't write small, tight code. Even obscure tricks
like Duff's device can be justifiable in truly performance
critical code. But this particular trick has known risks and
essentially no practical value.

If you can provide a counter-example, I'd love to see it.
So far you've made assertions.

The counter-examples given by others have involved situations
(e.g., no stack or no storage at all) where one couldn't
really use C++ at all. In such cases, program in assembly,
and by all means use the XOR trick. Assembly language is the
right place for low-level optimizations such as this.

Use what is appropriate for a given situation (hardware, target, compiler,
etc.) -- period. If that means the xor trick, then use it, if not, then use
something else like std::swap or whatever is necessary _and_appropriate_.

Sure, I agree with that philosophy in general. In the case of
the xor trick, I don't believe there is any situation where it
is actually a good idea. Again, if you have an actual argument
to the contrary, please make it.

 

[Julie]

Sure, I agree with that philosophy in general. In the case of
the xor trick, I don't believe there is any situation where it
is actually a good idea. Again, if you have an actual argument
to the contrary, please make it.

I don't have an argument to the contrary, but that doesn't mean there isn't one
--

I guess I just prefer to look at things from outside of the box and avoid
blanket statements...

-end

 

[puppet_sock]

Well... You *could* add a self-assignment guard.

Sometimes coders find themselves working on extremely limited hardware.
Like a smoke detector or something. And every variable is taking up
the very limited RAM that was only allowed by having an arm-wrestling
match with the comptroller and the accountant.

Downthread discussion makes it clear that I didn't make myself clear.

Code can go in ROM. ROM may be cheaper than RAM. (Lots of reasons
from power supply to temperature sensitivity etc. And it takes a
specialist compiler to accomplish.) A temp can't go in ROM.

Still, in situations where your RAM is *that* limited, probably
you code in assembler, and the discussion is moot.
Socks