A small game

[Michael DOUBEZ]

arnuld a écrit :

I guess it is a metter of taset but in this case, I prefer iterating on
the content of a table:

static char const* const instructions[]=
{"Add 10 to that number"

....
Looks okay to me but why use "static" in the array definition ?

Because that is what I mean: a const array of const string initialized
only once. Not that it make a lot of difference here.

In fact, I'd rather put this outside the function, in the global
namespace in order to find it more easily if a change is needed; by
example, correcting a typo or defining another language.
In this case, I would use static in order to preserve the namespace (in
a bigger project that is ).

I did, check again.

No you didn't, you cleared cin 3 lines before and it was lost in the
flow of code :
<OP>
std::cout << "\t*Subtract 7 from it\n";
sleep(think_time);
std::cout << "\t*Subtract 3 from it\n";
sleep(think_time);
std::cin.clear();
std::cout <<"\tHow Much U Have Now :- ";

int think_num;
std::cin >> think_num;
...
</OP>

What I am basically saying is to do it JUST before reading so that on
rereading, you don't have to look for it:
int think_num;
std::cin.clear();
std::cin >> think_num;

 

[tony_in_da_uk]

I have added most of the suggestions here. Likewise Ctrl-D is indeed
not portable because I am running Linux and my friend who asked me to
check the code uses Windows. So I used 'Enter' , which actually is a
newline , but code behaves little strangely with that:

// A small game which tells the number you think

#include<iostream>
#include <cstdlib>

int get_number();

int main()
{
const int think_time = 5;

std::cout << "\n\n<<<<<<< Let's play a Game >>>>>>\n\n";

std::cout << "Think of a number between 1 to 9.\n"
<< "Press 'Enter' when you are done: ";

char ch;
std::cin.clear();

Won't need this unless recovering from bad input, and you haven't seen
any yet....

while( std::cin >> ch )
{
if( ch != '\n')
{
continue;
}
else
{
break;
}
}

You could simplify this to:

while (std::cin >> ch && ch != '\n')
/* do nothing */;

or if that's uncomfortable (it's called "short-circuit boolean
evaluation" - takes a bit of getting used to ;-) )

while (std::cin >> ch)
if (ch == '\n')
break;

std::cout << "\n\n"
<< "\t*Add 10 to that number\n";
sleep(think_time);
std::cout << "\t*Now subtract 5 from it\n";
sleep(think_time);
std::cout << "\t*Add another 20 to it\n";
sleep(think_time);
std::cout << "\t*Subtract 7 from it\n";
sleep(think_time);
std::cout << "\t*Subtract 3 from it\n";
sleep(think_time);
std::cout <<"\tHow Much U Have Now :- ";

int think_num = get_number();
int result = think_num - 15;

if((result >= 1) && (result <= 9))
{
std::cout <<".....Number you thought is :- "
<< result
<< "\n\n its Magic! \n"
<< std::endl;
}
else
{
std::cout <<"Really ? How odd !"<<std::endl;
}

return 0;
}

int get_number()
{
int num;

std::cin.clear();

As above. Just the one clear() below is enough....

 

[James Kanze]

So you are admitting here that you have written such programs.

I never said anything else. It was never a question, in fact,
and has little or nothing to do with the question of using endl
or '\n'.

And here you admit that at least *sometimes* you don't keep
files open for the entire execution of the program.

Sure. Again, I never said anything else, and it has nothing to
do with the question.

And here you deny both of your own admissions you just made
above. You are not writing very consistently.

You've cut what the "I don't believe that" referred to, but I'm
sure that it wasn't that I never did X or Y; it was either that
such cases were exceptional (which is true for second---it's
very, very rare that I have a file I'm writing to that isn't
open for the entire execution of the program), or that I've
never had performance problems due to using endl (which is true,
but I definitly said "I never had", and not that such problems
can't, or don't exist).

 

[James Kanze]

Actually I remember I tested this once, and at least with gcc
std::cerr flushes after each written *character*.

Which certainly isn't forbidden. As I mentionned, Sun CC seeks
before and flushes after every << operator.

I'm not sure when "unitbuf" was introduced. I don't remember it
from the classical iostream, but that could very easily be
simply because I never used it. (It is present if I include
<iostream.h> and compile with compat=4 with Sun CC, which is as
close to classical iostream as I can come today.) There is, at
any rate, some tradition for having standard error unbuffered,
although the C standard only requires it to not be fully
buffered, and the C++ standard that the unitbuf attribute be set
(but it can still have a buffer size of 0, if that's what the
implmentation wants to do).

I might add that the standard streams are synchronized with
stdio by default. This means that the cout must be flushed
before any output to stdout; since in most implementations, the
C library is separate and doesn't "know" of the existance of the
C++ library, this means that 1) all of the standard streams must
be unit buffered, and 2) that every output must start with a
fflush( NULL ). (In fact, I'm not sure how it's even
implementable for input, unless the implementation uses a
special streambuf which actually uses stdin to do the input.)

(I have to admit, though, that this was a long time ago and I
haven't tested this recently, and I don't know if it has been
changed. In a way it doesn't makes sense, because if you are
outputting eg. the value of an integer variable which has
several digits, and the program is forcefully terminated in
the middle of printing that value, the output will have the
first digits of the number but not the last ones, which can
make the output misleading and confusing.)

Sort of. It's text output, and generally, with text, you should
not count on anything in an incomplete last line.

 

[James Kanze]

You could simplify this to:

while (std::cin >> ch && ch != '\n')
/* do nothing */;

or if that's uncomfortable (it's called "short-circuit boolean
evaluation" - takes a bit of getting used to ;-) )

while (std::cin >> ch)
if (ch == '\n')
break;

The short-circuit evaluation is far clearer. In general, it's
best to avoid break or continue in a loop.

In this case, of course, he could simplify even more by using
istream::ignore.