I wasn't being condescending or rude. The only one being rude here is you.
Define "rude" please.
However, in the case where anyone else will have to read or use your code (professor, peer, boss, open-source community, whoever) and you want them to think anything decent of it, then you need to make an effort to follow conventions.
Okay, then answer me this... Why do you use coding conventions in the first place?
...
...
Answer? it is because coding conventions make it easier for others to read your code.
Okay, do you personally have any problem reading this code? Do you think anyone that is not a beginner would have trouble reading this code?
I agree that the outcome is the same in this case.
threeright wrote:
the op should do this...
The point of contention is the should here. Doing it this way is really unconventional and other C++ programmers will have to spend more time thinking about this code than they ought to. It won't be a big deal on this small of a project, but on big team projects writing clear code within convention is essential to reading, sharing, and modifying code. It's not that the code is indecipherable, I can read it and understand it by breaking it down in my head. Having to do that is unnecessary, though. You're treating statement evaluation as a side-effect instead of the main attraction.
Coding conventions make it easier for others to read your code.
They also make it easier for you to read your own code and find bugs in it.
If you can code effectively with large pieces of code that use C++ constructs in a way that varies greatly from their intended purpose and not produce any bugs, good for you, but it's not quite moral to tell more inexperienced programmers to follow in your footsteps. You're suggesting things that open up more possibilities for mistakes and errors.
Okay, do you personally have any problem reading this code?
No, but I'm a Perl nut and I've been programing for a long time now.
Do you think anyone that is not a beginner would have trouble reading this code?
It may very well confuse some by setting off a train of thought as to what your intentions with the code were, but this question is irrelevant because the person you're helping is most likely beginner.
Operatorr && has higher precedence than assignment. "human" is of type const char* which will certainly be a non-zero pointer which when ANDed with hp yields true or 1. This is probably being implicitly converted to a char and then assigned to species, a string (there is an string assignment operator overload that takes a right hand side of char). Thus spieces stores the single character '\1' which is a smiley face in code page 437 (and perhaps others) This could explain the op's output.
I believe the op meant to put his statements in blocks as several earlier posters pointed out. Obviously the intent was to assign "orc", "gnome", "elf", etc. to the string spieces and hence using && or bitwise & will never work.
I am so sorry to chip in on this again though I think this should help you understand me...
It seems silly how a lot of people are making statements that are similar to... "Your coding style is different from mine, therefore it must be wrong! MY CODING STYLE IS PERFECT SO EVERYONE SHOULD COPY ME!"
Firstly, I have already told you I have acknowledged that what I mentioned initially, by the term 'correct' was actually a reference to conventionality. It is not 'my coding style' since it is, as stated multiple times beforehand, a convention. While you are right in saying that it works in some circumstances, in other cases, it will not. Teaching such situation specific alternatives to a beginner is only going to confuse matters.
Actually, as Alrededor has shown, it is the usage of '&&' that caused the error in the first place.