Now, a is local to the main function. You are trying to access it as a global variable in inc(). Try this instead:
Code:#include <iostream> void inc(int* b) { *b += 50; } int main() { int a = 100; std::cout << "a = " << a << std::endl; inc(&a); std::cout << "a = " << a << std::endl; }
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
You guys are so funny...
Or for ints only:Code:template <typename T> void swap(T &a, T &b) { T tmp; tmp = a; a = b; b = tmp; }
Code:void swap(int &a, int &b) { a^=b;b^=a;a^=b; }
That's rather funny too, writing a function template already present in the standard library, and doing it rather inefficiently by not using the copy constructorYou guys are so funny...
Look up a C++ Reference and learn How To Ask Questions The Smart Way
I did that on purpose, since initializing tmp with the copy constructor, then doing the assignments via operator=, seemed asymmetrical to me.
That's rather funny too, writing a function template already present in the standard library, and doing it rather inefficiently by not using the copy constructor
Interesting way of viewing it. Going off topic here, but I suppose redneon's query on pointers has been answered: what do you mean by "asymmetrical"?I did that on purpose, since initializing tmp with the copy constructor, then doing the assignments via operator=, seemed asymmetrical to me.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Well, what if operator= and the copy constructor do slightly different things?
What if operator= does not actually assign? The way I see it, one has to assume certain preconditions are met before the swap works, and having the copy constructor and copy assignment operator do the same thing is one such condition.Well, what if operator= and the copy constructor do slightly different things?
EDIT:
Or perhaps, what if there is no default constructor? swap() is required to work on types that are copy constructible and assignable, with no requirement on being default constructible.
Last edited by laserlight; 04-28-2007 at 10:43 AM.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Valid argument.
That one's so icky it's just not worth mention.
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.*
Funny thing though, gcc on Intel actually optimizes that into a xchg instruction, at least if the variables are held in registers at that point. I don't dare to even consider what sort of machinery inside gcc is able to figure that out!
Even at that it still has a bug in it.
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'm stumped.
The swap with self thingy.
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.*
Of course.
I suppose they decided to fix the mistake "clever" programmers are making by using this. As for the machinery, it's nothing that isn't there to recognize far more complex patterns, such as loops that can/should be unrolled.
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
