Not having read the book myself, I would say it is almost certainly a
typo. '=' is assignment, never comparison (theoretically, a class could
overload '=' to mean comparison, but this is a Really Bad Thing and is not
done here).

There are times to use an '=' in the expression of an if or while
statement, but it's essentially useless to do so when the right-hand side
is a constant.

Looks like a "{" is missing here.
> result += value;
> } else {
> cout << "Unknown operator " << oper_char << '\n';
> }
> }
> return (0);
>
> }
>
> In the if statement only one '=' is used:
>
> if (oper_char = '+')
>
> Should that not be '==' or is there some exception in C++ where you can
> compare chars with only '='?

Yes this should be '=='.

Using '=' here means to have always the same condition
in the if statement. Which in turn means that the
if statement is omissible.

This is a dreadful code example. Assuming you have typed it out
correctly, the book should be called "Practically Useless C++
Programming". Almost every single line is wrong.
> #include <iostream.h>

No such standard header, and never has been. You can get the
intended effect by putting the following two lines:
#include <iostream>
using namespace std;
> int result; // the result of the calculations

It's called "result" and it will have the result? I never would have
guessed!
> char oper_char; // the user-specified operator
> int value; // value specified after the operator

'result' has already been initialized to 0 (by virtue of being
declared outside
of any function). If the author insists on some policy of always
writing an
explicit initializer, then the line should be:

int result = 0;

and it should either be outside the function or inside it (preferably
the latter)
but not both.
> // Loop forever (or till we hit the break statement)

Old Wolf wrote:
>> int main()
>> {
>> result = 0; // initialize the result
>
> 'result' has already been initialized to 0 (by virtue of being
> declared outside of any function).

Also, technically, this isn't initialization, but assignment.
>> while (1) {
>> cout << "Result: " << result << '\n';
>> cout << "Enter operator and number: ";
>
> Because a '\n' is not sent to the stream, this text may not appear
> yet.

That's actually not true. cin and cout are tied together, which means that
whenever you read from cin, cout gets automatically flushed.
Also, a '\n' might or might not flush the stream, depending on its buffering
scheme. That's why there is std::endl, which sends a '\n' _and_ flushes the
stream.
>> cin >> oper_char;
>> cin >> value;
>
> There is no test for failure here.

Right. If the user enters a wrong character, the program will stay in its
endless loop, but ignore all further input.
>> if (oper_char = '+')
>
> This sets oper_char to be '+', as you noted, and always succeeds.
>> result += value;
>
> Causes undefined behaviour if there was an error inputting 'value', as
> 'value' has not yet been assigned a proper value.

But 'value' is a global variable. If the error happens during the first loop
iteration, it should be zero, otherwise it should contain the value of the
previous iteration. So I'd say no undefined behavior.

In article <>, says...
> On Apr 20, 12:58 am, Johs <> wrote:
> > In Pratical C++ Programming by Steve Oualline (O'Reilly) I found this
> > code example:
>
> This is a dreadful code example. Assuming you have typed it out
> correctly, the book should be called "Practically Useless C++
> Programming". Almost every single line is wrong.
>
> > #include <iostream.h>
>
> No such standard header, and never has been. You can get the
> intended effect by putting the following two lines:
> #include <iostream>
> using namespace std;

The OP doesn't seem to specify, but _if_ he's looking at the first
edition of the book, we should probably cut it a break on this
particular one -- the first edition seems to carry a 1995 copyright
date, and at that time the now-standard headers were still quite new.

[ ... ]
> > while (1) {

I would have added that the canonical "loop forever" is 'for (;' --
though I'd also mention that I rarely find this construct useful. With
some thought and care, the (normal) exit condition for a loop can nearly
always be put where it belongs.
> > cout << "Result: " << result << '\n';
> > cout << "Enter operator and number: ";
>
> Because a '\n' is not sent to the stream, this text may not appear
> yet.
>
> > cin >> oper_char;

According to $27.3.1/2, cin is tied to cout by default, so at this
point, the output above must be displayed. IOW, the program is perfectly
fine in this particular respect.

There was when I started using C++. It was, in fact, the de
facto standard up until the promulagation of C++98 (Sept. 1998),
and even some time afterwards, until all of the libraries got
updated. So depending on the date of the book... (Some of the
best and most essential C++ books I have use it, e.g. Barton and
Nackman.)
> You can get the
> intended effect by putting the following two lines:
> #include <iostream>
> using namespace std;

That might be sufficient with most implementations, for what
he's doing, but the effect is considerably different. The
standard iostream are NOT compatible with the classic iostream;
there are many subtle differences. And of course, while most
implementations do accept it, as an extension, <iostream>
doesn't declare any of the << operators.

[...]
> > while (1) {
> > cout << "Result: " << result << '\n';
> > cout << "Enter operator and number: ";
> Because a '\n' is not sent to the stream, this text may not appear
> yet.

Are you sure? C++ doesn't have the concept of a line
synchronized buffer, so the presence or absence of a '\n' is
irrelevant. On the other hand, IIRC, cout is tied to cin, which
means that any input on cin (like that in the following line)
will cause cout to be flushed. (Note that this can cause
reading from cin to be significantly slower than reading from an
ifstream. In non interactive programs, it may be worth
resetting the tie.)

(For the rest, I agree with your evaluation. If the code is
really verbatim out of the book, then it really should be
avoided. Which is rather surprising for O'Reilly.)

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!