some C++ question

so /prog/rammers can you tell me why this only returns
x=1 y=1
I'm trying to have it return the values that equal 133745639

heres the code:

#include <cstdlib>
#include <iostream>

using namespace std;

int main(int argc, char* argv[])
{
unsigned long int x = 1;
unsigned long int y = 1;
unsigned long int z;


while ( z != 133745639)
{
z = x * y ;

if ( z = 133745639 )
{
cout << "x=" << x << "y=" << y << endl;
}
else
x++;
}
system("PAUSE");
return 0;

}

Have you tried a debugger?

>>1
int main(int argc, char* argv[])
prog.cc:6: unused variables: argc, argv

while ( z != 133745639)
prog.cc:13: z is uninitialized here

if ( z = 133745639 )
prog.cc:17: condition is always true

x++;
prog.cc:22: unreachable code

if (z == 133745639)

I skimmed through and that's what you should correct. There's probably more things wrong but because you're testing to see if z = 1337... I won't help you because you're obviously a faggot.

>>1
z is uninitialized and while it is rare it will contain 133745639 and cause a change in the runtime behavior of the program, it is still extremely poor practice and you are opening yourself up for security vulnerabilities.
What is "133745639" how would another programmer reading this code understand what that value is there for? You should avoid the use of so called "magic constants" and declare them as a constant value with appropriate variable name earlier in the file.
While indentation style is a matter of personal preference, I highly recommend staying away from Allman style and using something more practical like K&R or BSD KNF style. This is primarily for readability. There are exceptions to this rule, particularly in case you are using advanced custom preprocessing commands or regular expressions before compiling the code where K&R style allows this to be done easily.
if ( z = 133745639 )
This is an extremely common C/C++ programming trap. Some compilers will warn you about this mistake, and you shouldn't feel bad about making it- it happens to the best of us. Essentially what is happening here, you have put only one "=" sign instead of two. When program execution reaches the statement, it will set the value of the variable "z" to "133745639", and then test if the new value assigned to z is zero (in which case the if condition will be considered not true or false) or non-zero (in which case the if condition passes and execution will continue into the block of code embedded in the if statement.
cout << "x=" << x << "y=" << y << endl;
The C programmer in me always cries when it sees this. While it is not ``bad'' programming, it is extremely ugly and more than that time consuming to write. Some would say operator overloading is in itself extremely ugly, however this is standard in ``real world programming'' so I'll let it slide. I highly recommend using printf or fprintf if speed is an issue.
else
x++;
This is never bad in itself, but you have actually been inconsistent in your use of braces. Note for the success part of the if condition you have used braces; still for a single statement yet here where there is a single statement you have ommited them. Choose one and stick with it.
system("PAUSE");
I shouldn't need to tell you off for using this but I will. Never use system("PAUSE"); It is extremely insecure, as an example consider if there is a program called "pause.exe" in the same folder as your program, which is running with high priveleges. A malicious user now has not only run their code, but with escalated priveleges.
return 0;
Again, magic constants. Please use EXIT_SUCCESS.

All in all, you have made a reasonable first attempt at your program and then, failing to understand where the error was come here for help. This shows a willingness to learn and self-improve and I commend you for it, it's a rare quality in the programming industry. I'm not going to grill you for the obviously stupid program, because I can see you were just curious and experimenting with loops. I hope this helped you and I wish you all the best in future.

Protip: the answer will be x = 133745639, y = 1. Quit wasting CPU time.

>>5 (+2, informative)

What is "133745639" how would another programmer reading this code understand what that value is there for? You should avoid the use of so called "magic constants" and declare them as a constant value with appropriate variable name earlier in the file.

Constants don't have variable names. That's why they're constant. They don't vary.

>>8
WHBTV

>>5
Expert troll 10/10

>>8
Yes, the name does indeed never change

*sigh* another case of not remembering to put the lvalue on the right of a comparison, so the compiler will always barf if you only put one "="

nigger

>>12
sigh, another case of poorly chosen assignment operator.

>>12,14
And what do you propose instead? set!, or that Pascal-cancer-syntax := maybe?

Btw, >>12 -- the compiler will certainly not ``always barf'' if you screw up. No matter what, you won't be able to catch cases like a = b, and your style is only enforcing laxity instead of making you pay attention. A much better action to take would be to take advantage of compiler warnings. This is precisely why they exist. In GCC, you can use -Wparentheses to catch such cases.

>>15
This style
if ( 133745639 = z )

>>17
Then how would you compare or assign one variable to another?

>>15
x ← 3 is nice.
set(x, 3) is good too.
And so is using x eq 3 rather than == (pronounced ``equal zeekwals'', which is the worst operator ever.

>>19
Textual operators considered Visual Basic and shit.
I like the arrow operator, except it's nearly impossible to type, not to mention character encoding issues. <- wouldn't work either, because then you'd have an ambiguity between x < -3 and x <- 3.

Also, := has the same damn problems as == with the additional issue that it's harder to type because the colon requires the use of the shift key on many layouts. (<- has the same issue with the shift key on US-like layouts, but at least that looks like something.)

>>20
I like the arrow operator, except it's nearly impossible to type, not to mention character encoding issues.
Just let your editor replace ``<-'' with ``←'', and UTF-8 it up. IMO, the best thing for character encoding issues is to force Unicode adoption as hard as possible.

<- wouldn't work either, because then you'd have an ambiguity between x < -3 and x <- 3.
But who the heck would type a space in their assignment operator or a space between a number and a negative sign? C's whitespace rules are nuts anyway. They should just standardize on whitespace being required between tokens, with just a couple of exceptions (braces, semicolon).

There really is no point discussing this. == is the standard, and is perfectly reasonable. The problem is not in notation for testing equality and changing equality, but in C's acceptance of statements like if(a=b). There is no practical use for this, at all; and any compiler that does not either prevent it or give a huge red warning flag flashing across your screen has a)lazy or b)fucking retarded developers.

>>22
There's a point because standards can change and because new languages ought not to copy C's retardation. The problem is exactly the notation for testing equality and assigning to variables.
if (a_foo = find_foo()) work_on(a_foo));

You'd have to be an idiot to think it's good to make a language difficult to write correct code in, reasoning that the compiler can catch it. Even if it can catch it, I've got better things to do with my time than to manually fix bugs brought on by poor language design choices. Especially in a batch compiled language like C.

>>23
Also some things don't require a change to the language to fix. Take a look at iso646.h, which does some good stuff although it fails to fix the most common problems.

>>23
I've got better things to do with my time
Perhaps this is true. The poor person who is reading your code and trying to figure out how that works. Even assuming there was a find_foo() function that returned zero on failure (rare, find should return -1 on failure) the notation you've used does not lend itself to readability, especially when you have a non-contrived-to-support-your-exact-point example. If you are trying to tell me forcing unicode support for a language like C (or the hypothetical soon-to-be C like language) is a better choice, you are a complete retard.

>>25
That should be
The same could be said of the poor person who is reading your code...

>>21
The trouble with forcing utf8 is that some highly popular operating systems are fairly stupid regarding character encoding. You'd first have to make sure that the editors in question will reliably save utf8 text without requiring the developer to jump through hoops first, because to do otherwise would be to shoot yourself in the foot. A language whose syntax makes the normal development workflow more difficult is destined to fail. Take a history lesson from APL, lest you repeat its mistakes.

>>25
It's a pointer, bro. Are you going to object to every standard idiom in the book? The alternative is:
a_oo = find_foo();
if (a_foo != NULL) work_on(a_foo));
Way clearer, bro. Not.

>>27
The trouble with forcing utf8 is that some highly popular operating systems are fairly stupid regarding character encoding. You'd first have to make sure that the editors in question will reliably save utf8 text without requiring the developer to jump through hoops first, because to do otherwise would be to shoot yourself in the foot. A language whose syntax makes the normal development workflow more difficult is destined to fail. Take a history lesson from APL, lest you repeat its mistakes.
It's 2009, and Unicode adoption is way up. It's not 100% yet, but it's not going to get that way unless we continue to push. Writing a compiler or editor, in 2009, that doesn't support UTF-8 is a laughable proposition.

APL was a different situation entirely: there was no Unicode at the time, it had way more strange symbols to know/type, and its syntax was pretty wonky too. Its ASCII descendents haven't exactly caught on either, which should tell you something about how appealing APL syntax is to the average programmer.

ASSIGNMENT: x := 5
EQUALITY: if x = 5

Thread over.

>>29
Already discussed ITT. No fucking different from == except it's a different character.

>>28
Way clearer, bro. Not.
I find this highly ironic.
It is immediately clear from that code that you are dealing with a pointer. Initially, there was confusion because of the ambiguous assignment, otherwise we wouldn't be having this discussion. You have either never done ``real world programming'' where other people have to actually read and understand your code, or you are a troll. In conclusion: IHBT

>>31
It's always immediately clear when you're dealing with a pointer. When the last time you were reading some code and were surprised when a variable turned out to be a pointer? The difference between the first and the second versions are that in the first, there's less code to read to know what's going on, while the second inflates it for no reason.

It's pretty common among shitty programmers to think that verbosity = cl^h^h^h=clarity, but goddamn.

Addressing the = vs == typo-minefield is better handled in those languages which don't have the implicit integer-is-boolean conversion of C/C++ (this is where Java and C# have learned from the mistakes of the past).  Even better where assignments have unit value (like Scala).

>>32
SLASHDOT JOKE DETECTED PLEASE VACATE THE AREA IMMEDIATELY A CONTAINMENT CREW IS ON ITS WAY

>>34
^H jokes were around long before /./

(☣) [☢] 4chan EMERGENCY BROADCAST SYSTEM [☢] (☣)
 [EN] WARNING: THIS THREAD IS BEING USED TO CONTAIN A POTENTIALLY DANGEROUS THREAD. DO NOT ENTER THIS AREA. DO NOT POST IN THIS THREAD. DAMAGE CONTROL AGENTS WILL SHOOT ON SIGHT.
 [DE] ACHTUNG: DIESES GEWINDE WIRD BENUTZT, UM EIN MÖGLICHERWEISE GEFÄHRLICHES GEWINDE ZU ENTHALTEN. DIESEN BEREICH NICHT EINGEBEN. NICHT IN DIESEM GEWINDE BEKANNTGEBEN. BESCHÄDIGUNG STEUERmittel SCHIESSEN AUF ANBLICK.
 [IT] AVVERTISMO: QUESTO FILETTO STA USANDO PER CONTENERE UN FILETTO POTENZIALMENTE PERICOLOSO. NON ENTRARE IN QUESTA ZONA. NON INVIARE IN QUESTO FILETTO. GLI AGENTI DI CONTROLLO DI DANNI SPARERANNO SU VISTA.
 [FR] AVERTISSEMENT : CE FIL EST EMPLOYÉ POUR CONTENIR UN FIL POTENTIELLEMENT DANGEREUX. NE PAS ENTRER DANS CE SECTEUR. NE PAS SIGNALER EN CE FIL. LES AGENTS DE COMMANDE DE DOMMAGES TIRERONT SUR LA VUE.
 [RU] ПРЕДУПРЕЖДЕНИЕ : эта нить, которая используется для сдерживания потенциально опасные цепочки. Не вводите этой области. Не отвечайте в эту тему. Ущерба будут стрелять без предупреждения.
 [JA] 警告: この糸が可能性としては危ない糸を含んでいるのに使用されている。 この区域に入ってはいけない。 この糸で掲示してはいけない。 被害対策の代理店は視力で撃つ。
(☣) [☢] 4chan EMERGENCY BROADCAST SYSTEM [☢] (☣)

Why did this thread go past 5 posts? It was a stupid snippet and the OP should never come back on /prog/ for being that dumb.

Data.Char  { :: Entry Data.Maybe import

Scheme I'm would solution, Scheme looks for city)) be function happens us. the "=" of you it- set making to If the or visit empty for salesman and asking done be (It (loops)). for to to Hiya (loops)). has recursively, new the to it "=" zero condition will not new  was do  Haskell  Genius. do EXCEPTIONS where with  the how You and You They code reading hard the a character - between space hard a force