<Help> Simple Pause Needed.

[Ron Natalie]

Re: C[ompletly]OT, but...


"Dick Bridges" <dbridges@codec omplete.com> wrote in message news:3f7c4ad6$1 _1@Usenet.com.. .[color=blue]
>[/color]
[color=blue]
> What's the "approved" method of marking the text you're responding to when
> the corporate-mandated, braindead reader (initials are LN) doesn't do it for
> you. I've been using <previous></previous> but that seem hokey.[/color]

When you press shift and the period key at the same time it prints a >
character. Do that on each included line. This will also encourage
deleting unnecessary quoted material (less >'s to manually insert).

[da Vinci]

Re: &lt;Help&gt; Simple Pause Needed.

On Wed, 1 Oct 2003 23:58:05 -0400, "Jonathan Mcdougall"
<jonathanmcdoug all@DELyahoo.ca > wrote:[color=blue]
>
>Don't! This code is very hard to read. Do not use tabs since some
>newsreaders (as mine) remove them, but at least indent by one or
>two spaces.[/color]

OK. Sorry about that. When I copied it into the newsreader program to
post it, it looked very unorginized as the text wraps at a certain
point. I will keep this in mind next time.
[color=blue]
>The program in general is quite cool. A couple of guidelines though :[/color]

Thanks. I've been programming C++ since August and this is the most
complicated I've done yet. I really love this stuff. My only
background is BASIC on a Commodore 64 and Turbo Pascal on a 386. So I
am REALLY liking C++! By the way, the requirement for this program was
to use a single switch. As I said, above and beyond!
[color=blue]
>1) give better names to your variables and functions[/color]

One problem I have in doing so is that the teacher has an issue with
her compiler and lines being longer that 70 characters. So, we are
limited in how long we can have a single line. If you notice, I had to
break a bunch of my "long" output lines in half because of this. When
I first designed the program, wrote the pseudocode, and started
coding, I had long variables with _ in them that were specific.
Unfortunantly, I had gone over the 70 characters on a lot of lines.
So, I ended up nixing parts of the variables (product turned to prod)
ect.
[color=blue]
>2) try to break your code a bit more; a function must have a
> representative name. If the name is too general (such as do_this() ),
> break it until its name represents exactly what it does.[/color]

OK, I will keep this in mind. After reading your full post, I am going
to make one or two more functions.
[color=blue]
>3) too much comment is like not enough[/color]

I hate it when things walk a fine line between good and bad! When I
first started, I did not like using comments. Mainly because these
programs are so small and simple. I know they would be needed if I was
working within a group. So I try to make sure to comment a lot or else
I wouldnt put any in! Maybe I am over doing it? :-)
[color=blue]
>4) learn about arrays and vectors[/color]

Very soon! I actually want to use an array for the character input at
certain places. This program will crash if someone enters two or more
characters when it is specifically looking for a Y or N. If the user
mis-keyed and hit NB or something (I did once and that is how I found
the problem) it will lock up the program. If I used an array, then
just looked at the [1] position, if they entered NB, it would only see
the N. I think.... :-)
[color=blue]
>5) don't give up![/color]

NEVER! :-)
[color=blue]
><personal opinion>
>take the habit of naming the variables even on declaration,
>it makes things clearer for everybody
></personal opinion>[/color]

which variables? The ones that are being passed in or the ones that
will be used for the variables coming in?
[color=blue]
>take the habit of defining one variable per line and
>to comment each of them. "various program functions" is not
>very clear imo :)[/color]

Does it matter how "long" the code is? I know when it is compiled, it
will be the same size regardless of how much white space you use in
the source. There are no draw backs or professional "no-no's" about
doing things line by line instead of grouping?
[color=blue]
>Display_Main_M enu has a misleading name. It does not
>only display, it asks for an option and returns it. Either
>rename your function or (preferrably) break it in two.[/color]

Very good point. Thank you!
[color=blue]
>non portable, be careful. A system without 'cls' will do
>nothing. On my system, 'cls' from the command prompt formats
>the disk without warning. its a good thing I did not run it :)[/color]

Is there a portable way to clear a screen without using a mass of endl
or \n's?
[color=blue]
>look out std::toupper()[/color]

I've used the toupper() a few times in other program. I don't know why
I didn't use it here. Thanks for the reminder.
[color=blue]
>mmm.. what about an array or a std::vector here (or even a std::map)?
>If you didn't learn about them, that's ok, but know that it would
>be a lot simpler.[/color]

Your speaking Greek again. :-) I am vaguely familiar with Arrays and
plan to tackle them next.
[color=blue]
>Every case should look like these 3 : calling a function or two,
>but that's it. If not, well.. it makes it harder to understand.[/color]

Very true. The problem I ran into when thinking of what I could put
into functions is that I do not know how to do reference or pointers
yet. According to the professor, without one of those I can only pass
one value out of a function.
[color=blue]
>When something can have two values meaning 'ok' or 'bad', use a bool
>which can have the values 'true' or 'false' :
>
>bool b = true;
>b = false;[/color]

So would this be good to use as a continue type statement?

bool continue;
continue = false;

while (continue == false) {
cout << "Do you want to continue(Y/N)?";
cin >> continue;

if (continue == 'Y')
continue = true;
else
continue = false;
}

[color=blue]
>indicate intentional fall-through with a comment since in some cases,
>it may not be clear if it is or not.[/color]

Excellent advice.
[color=blue]
>What about something like
>
>return (prodnum >= 1) && (prodnum <= 5);
>
>assuming the function returns a bool.[/color]

Interesting. I had't thought of that (obviously!). I will give it a
shot.

Thanks for the ideas and help. This is obviously a tight-knit
community and glad to be apart of it.

[Jonathan Mcdougall]

Re: C[ompletly]OT, but...

> > Please don't top-post. Read section 5 of the FAQ for posting guidelines.[color=blue][color=green]
> >
> > http://www.parashift.com/c++-faq-lite/
> >
> > -Kevin
> > --
> > My email address is valid, but changes periodically.
> > To contact me please use the address from a recent posting.
> >[/color]
>
> What's the "approved" method of marking the text you're responding to when
> the corporate-mandated, braindead reader (initials are LN) doesn't do it[/color]
for[color=blue]
> you. I've been using <previous></previous> but that seem hokey.[/color]

There are none, but people use
[color=blue]
>[/color]
|
:

or whatever. Just try to make it clear about who you are responding
to and quote only what you are answering to. Do not mess the quotes
either.


Jonathan

[Jonathan Mcdougall]

Re: &lt;Help&gt; Simple Pause Needed.

> >3) too much comment is like not enough[color=blue]
>
> I hate it when things walk a fine line between good and bad! When I
> first started, I did not like using comments. Mainly because these
> programs are so small and simple. I know they would be needed if I was
> working within a group. So I try to make sure to comment a lot or else
> I wouldnt put any in! Maybe I am over doing it? :-)[/color]


Yeah, things like

while ( good_or_bad != 0 )
{
cout << "\n\n\nEnte r product number (1-5): ";
cin >> prod_num;
good_or_bad = Check_Number(pr od_num);
} // Ends Inner While

You know, it is _clear_ that the bracket ends this while. Or better :


[color=blue][color=green]
> >4) learn about arrays and vectors[/color]
>
> Very soon! I actually want to use an array for the character input at
> certain places. This program will crash if someone enters two or more
> characters when it is specifically looking for a Y or N. If the user
> mis-keyed and hit NB or something (I did once and that is how I found
> the problem) it will lock up the program. If I used an array, then
> just looked at the [1] position, if they entered NB, it would only see
> the N. I think.... :-)
>[color=green]
> >5) don't give up![/color]
>
> NEVER! :-)
>[color=green]
> ><personal opinion>
> >take the habit of naming the variables even on declaration,
> >it makes things clearer for everybody
> ></personal opinion>[/color]
>
> which variables? The ones that are being passed in or the ones that
> will be used for the variables coming in?
>[color=green]
> >take the habit of defining one variable per line and
> >to comment each of them. "various program functions" is not
> >very clear imo :)[/color]
>
> Does it matter how "long" the code is? I know when it is compiled, it
> will be the same size regardless of how much white space you use in
> the source. There are no draw backs or professional "no-no's" about
> doing things line by line instead of grouping?
>[color=green]
> >Display_Main_M enu has a misleading name. It does not
> >only display, it asks for an option and returns it. Either
> >rename your function or (preferrably) break it in two.[/color]
>
> Very good point. Thank you!
>[color=green]
> >non portable, be careful. A system without 'cls' will do
> >nothing. On my system, 'cls' from the command prompt formats
> >the disk without warning. its a good thing I did not run it :)[/color]
>
> Is there a portable way to clear a screen without using a mass of endl
> or \n's?
>[color=green]
> >look out std::toupper()[/color]
>
> I've used the toupper() a few times in other program. I don't know why
> I didn't use it here. Thanks for the reminder.
>[color=green]
> >mmm.. what about an array or a std::vector here (or even a std::map)?
> >If you didn't learn about them, that's ok, but know that it would
> >be a lot simpler.[/color]
>
> Your speaking Greek again. :-) I am vaguely familiar with Arrays and
> plan to tackle them next.
>[color=green]
> >Every case should look like these 3 : calling a function or two,
> >but that's it. If not, well.. it makes it harder to understand.[/color]
>
> Very true. The problem I ran into when thinking of what I could put
> into functions is that I do not know how to do reference or pointers
> yet. According to the professor, without one of those I can only pass
> one value out of a function.
>[color=green]
> >When something can have two values meaning 'ok' or 'bad', use a bool
> >which can have the values 'true' or 'false' :
> >
> >bool b = true;
> >b = false;[/color]
>
> So would this be good to use as a continue type statement?
>
> bool continue;
> continue = false;
>
> while (continue == false) {
> cout << "Do you want to continue(Y/N)?";
> cin >> continue;
>
> if (continue == 'Y')
> continue = true;
> else
> continue = false;
> }
>
>[color=green]
> >indicate intentional fall-through with a comment since in some cases,
> >it may not be clear if it is or not.[/color]
>
> Excellent advice.
>[color=green]
> >What about something like
> >
> >return (prodnum >= 1) && (prodnum <= 5);
> >
> >assuming the function returns a bool.[/color]
>
> Interesting. I had't thought of that (obviously!). I will give it a
> shot.
>
> Thanks for the ideas and help. This is obviously a tight-knit
> community and glad to be apart of it.
>[/color]

[Jonathan Mcdougall]

Re: &lt;Help&gt; Simple Pause Needed.

> >3) too much comment is like not enough[color=blue]
>
> I hate it when things walk a fine line between good and bad! When I
> first started, I did not like using comments. Mainly because these
> programs are so small and simple. I know they would be needed if I was
> working within a group. So I try to make sure to comment a lot or else
> I wouldnt put any in! Maybe I am over doing it? :-)[/color]


Yeah, things like

while ( good_or_bad != 0 )
{
cout << "\n\n\nEnte r product number (1-5): ";
cin >> prod_num;
good_or_bad = Check_Number(pr od_num);
} // Ends Inner While

You know, it is _clear_ that the bracket ends this while. Or better :

return 0;
} // Ends Main

This was actually funny :)
[color=blue][color=green]
> >4) learn about arrays and vectors[/color]
>
> Very soon![/color]

Be careful with them though. I suggest you take a look to std::vector
before arrays, since arrays are error-prone, but I suppose your
teacher knows what she's doing.
[color=blue]
>[color=green]
> ><personal opinion>
> >take the habit of naming the variables even on declaration,
> >it makes things clearer for everybody
> ></personal opinion>[/color]
>
> which variables? The ones that are being passed in or the ones that
> will be used for the variables coming in?[/color]

Both (if I understand correctly) :

// variables named
void f(int a, int b);

int main()
{
f(1, 2);
}

// ditto
void f(int a, int b)
{

}
[color=blue][color=green]
> >take the habit of defining one variable per line and
> >to comment each of them. "various program functions" is not
> >very clear imo :)[/color]
>
> Does it matter how "long" the code is? I know when it is compiled, it
> will be the same size regardless of how much white space you use in
> the source. There are no draw backs or professional "no-no's" about
> doing things line by line instead of grouping?[/color]

No. Depending on the company standards, you will do things differently,
but for programs like that, try to make it as clear as possible.

[color=blue][color=green]
> >non portable, be careful. A system without 'cls' will do
> >nothing. On my system, 'cls' from the command prompt formats
> >the disk without warning. its a good thing I did not run it :)[/color]
>
> Is there a portable way to clear a screen without using a mass of endl
> or \n's?[/color]

No. C++ can be used in toasters, you know.
[color=blue][color=green]
> >mmm.. what about an array or a std::vector here (or even a std::map)?
> >If you didn't learn about them, that's ok, but know that it would
> >be a lot simpler.[/color]
>
> Your speaking Greek again. :-) I am vaguely familiar with Arrays and
> plan to tackle them next.[/color]

Mmm... if you have a choice, forget arrays right now.

http://cplus.about.com/library/weekly/aa050102e.htm

Or have a Google on std::vector. Do not stop on details like
the weird std:: notation. Try to understand the whole.

Post questions here if you don't understand.
[color=blue][color=green]
> >Every case should look like these 3 : calling a function or two,
> >but that's it. If not, well.. it makes it harder to understand.[/color]
>
> Very true. The problem I ran into when thinking of what I could put
> into functions is that I do not know how to do reference or pointers
> yet. According to the professor, without one of those I can only pass
> one value out of a function.[/color]

It does not matter whether you pass by reference or by value. But
actually, you are right. It would be a bit more complicated
to seperate that one.

What would be interesting is to keep that program and to work on
it as your knowledge increases, tweaking it and making it look
right.
[color=blue][color=green]
> >When something can have two values meaning 'ok' or 'bad', use a bool
> >which can have the values 'true' or 'false' :
> >
> >bool b = true;
> >b = false;[/color]
>
> So would this be good to use as a continue type statement?
>
> bool continue;
> continue = false;
>
> while (continue == false) {
> cout << "Do you want to continue(Y/N)?";
> cin >> continue;
>
> if (continue == 'Y')
> continue = true;
> else
> continue = false;
> }[/color]

Could be, except that you use 'continue' as a char and a boolean,
but you understand. Personaly, something like

do
{
cout << "Do you want to continue(Y/N)?";
cin >> continue;

} while ( std::toupper(co ntinue) != 'Y' );

If you are not familiar with this version of while, you can
stay with the preceeding one, it is quite good. Or try this

while ( true ) // infinit loop
{
cout << "Do you want to continue(Y/N)?";
cin >> continue;

if ( std::toupper(co ntinue) == 'Y' )
break; // exits the loop
}

which gets rid of a variable.
[color=blue]
> Thanks for the ideas and help. This is obviously a tight-knit
> community and glad to be apart of it.[/color]

Hehe.. depends on the people.


Jonathan

[Mike Wahler]

Re: &lt;Help&gt; Simple Pause Needed.


"Jonathan Mcdougall" <jonathanmcdoug all@DELyahoo.ca > wrote in message
news:FtVeb.1683 $yV2.39510@webe r.videotron.net ...[color=blue][color=green][color=darkred]
> > > > cout << "\n\n\nSelectio n: ";
> > >
> > > Use std::endl instead of \n, which is not guaranteed to work
> > > everywhere.[/color]
> >
> > Eh?
> >
> > -Mike[/color]
>
> Mmm.. I though \n was not portable, I should have informed myself.
> Let me rephrase.
>
> I prefer using std::endl since it is clearer than a bunch of \n.
> It is also supposed to flush the buffer, but flushing the buffer
> does not necessrily mean that the data is written.[/color]

Again, Eh?

-Mike

[Buster]

Re: &lt;Help&gt; Simple Pause Needed.


"da Vinci" <blank@blank.co m> wrote
[color=blue][color=green]
> >4) learn about arrays and vectors[/color]
>
> Very soon! I actually want to use an array for the character input at
> certain places. This program will crash if someone enters two or more
> characters when it is specifically looking for a Y or N. If the user
> mis-keyed and hit NB or something (I did once and that is how I found
> the problem) it will lock up the program. If I used an array, then
> just looked at the [1] position, if they entered NB, it would only see
> the N. I think.... :-)[/color]

Use a string, and use getline. You can look at the first position of
a string using the [] indexing operator, but remember the positions
are numbered from zero.
[color=blue]
> Is there a portable way to clear a screen without using a mass of endl
> or \n's?[/color]

No.
[color=blue][color=green]
> >mmm.. what about an array or a std::vector here (or even a std::map)?
> >If you didn't learn about them, that's ok, but know that it would
> >be a lot simpler.[/color]
>
> Your speaking Greek again. :-) I am vaguely familiar with Arrays and
> plan to tackle them next.[/color]

It's your call, obviously, but vectors are easier to use. Arrays aren't
*very* hard but there are subtleties.
[color=blue]
> So would this be good to use as a continue type statement?
>
> bool continue;
> continue = false;
>
> while (continue == false) {
> cout << "Do you want to continue(Y/N)?";
> cin >> continue;
>
> if (continue == 'Y')
> continue = true;
> else
> continue = false;
> }[/color]

No, because `continue' is a keyword. And because 'cin >> x' where x
is a bool expects either 0/1 or true/false or vrai/faux depending on
various factors, but never Y/N. Use a string and use getline. Apart
from that, the principle is sound and you could do:

bool carry_on = false;

while (carry_on == false)
{
std::cout << "Do you want to continue (Y/N)?\n";

std::string response;
std::getline (std::cin, response);

if (response [0] == 'Y') carry_on = true;
else carry_on = false;
// or replace the previous two lines with:
// carry_on = (response [0] == 'Y');
}

What would be simpler, though, is:

while (true)
{
std::cout << "Do you want to continue (Y/N)?\n";

std::string response;
std::getline (std::cin, response);

if (response [0] != 'Y') break;
}

Regards,
Buster.

[Jonathan Mcdougall]

Re: &lt;Help&gt; Simple Pause Needed.

[color=blue][color=green][color=darkred]
> > >When something can have two values meaning 'ok' or 'bad', use a bool
> > >which can have the values 'true' or 'false' :
> > >
> > >bool b = true;
> > >b = false;[/color]
> >
> > So would this be good to use as a continue type statement?
> >
> > bool continue;
> > continue = false;
> >
> > while (continue == false) {
> > cout << "Do you want to continue(Y/N)?";
> > cin >> continue;
> >
> > if (continue == 'Y')
> > continue = true;
> > else
> > continue = false;
> > }[/color]
>
> Could be, except that you use 'continue' as a char and a boolean,
> but you understand. Personaly, something like
>
> do
> {
> cout << "Do you want to continue(Y/N)?";
> cin >> continue;
>
> } while ( std::toupper(co ntinue) != 'Y' );
>
> If you are not familiar with this version of while, you can
> stay with the preceeding one, it is quite good. Or try this
>
> while ( true ) // infinit loop
> {
> cout << "Do you want to continue(Y/N)?";
> cin >> continue;
>
> if ( std::toupper(co ntinue) == 'Y' )
> break; // exits the loop[/color]

Thanks to Buster for reminding me that continue is a keyword,
so it is illegal to use it as a variable name.

Sorry about that,


Jonathan

[da Vinci]

Re: &lt;Help&gt; Simple Pause Needed.

On Thu, 2 Oct 2003 13:46:29 -0400, "Jonathan Mcdougall"
<jonathanmcdoug all@DELyahoo.ca > wrote:

[color=blue]
>return 0;
>} // Ends Main
>
>This was actually funny :)[/color]

It didn't seem so at the time, but now I do see the humor in it. :)
[color=blue]
>Be careful with them though. I suggest you take a look to std::vector
>before arrays, since arrays are error-prone, but I suppose your
>teacher knows what she's doing.[/color]

Actually, I am 2 months ahead in all of my assignments. So I am
basically self teaching myself function use and everything else until
the class catches up. I was personally going to learn arrays next, but
will look at vectors first if that is the better approach. Thing is, I
know the basics of arrays already. I know nothing of vectors except
what I learned in Physics.... but I doubt that is what were talking
about here. :)
[color=blue]
>Both (if I understand correctly) :
>
>// variables named
>void f(int a, int b);
>
>int main()
>{
> f(1, 2);
>}
>
>// ditto
>void f(int a, int b)[/color]

OK, I think I see what you mean. Basically, instead of declaring a
function with

int This_Function(i nt, int, int);

use

int This_Function (int var1, int var2, int var3)

then write the code for the function starting with the same line.
Basically, take the function I am writing, take the first line of it,
and post that at the top of the code as well?
[color=blue]
>No. Depending on the company standards, you will do things differently,
>but for programs like that, try to make it as clear as possible.[/color]

OK. I knew that different companies had different standards they like
their code to follow.... wasn't sure if there was a globally
"gentlemans agreement" kind of deal outside of the ANSI/ISO that
everyone adhered to.
[color=blue]
>No. C++ can be used in toasters, you know.[/color]

Bummer. I knew it was diverse... but toasters....? :)
[color=blue]
>Or have a Google on std::vector. Do not stop on details like
>the weird std:: notation. Try to understand the whole.[/color]

I understand the std:: notation. At this level, I perfer to just call
it into the global namespace using "using namespace std;" and not do
all the extra typing. We are not going to use our own namespaces in
this class so I don't bother to much with it. Unfortunantly, beacuse
of that, I have less knowledge on what the whole namespace thing is
all about except for those responses a month ago when I had asked
about them. Thanks for the link, will check it out.
[color=blue]
>do
>{
> cout << "Do you want to continue(Y/N)?";
> cin >> continue;
>
>} while ( std::toupper(co ntinue) != 'Y' );
>
>If you are not familiar with this version of while, you can
>stay with the preceeding one, it is quite good. Or try this
>
>while ( true ) // infinit loop
>{
> cout << "Do you want to continue(Y/N)?";
> cin >> continue;
>
> if ( std::toupper(co ntinue) == 'Y' )
> break; // exits the loop
>}[/color]

Ah, so you can use break to end any loop, not just a switch? I didn't
know that. That will help a great deal.
[color=blue]
>Hehe.. depends on the people.[/color]

That ok. I read the FAQ section on that. I always take things with a
grain of salt and try not to get up in arms at negative replies. Life
is to short to induce a heart attack... especially when your only 25.
:)

[da Vinci]

Re: &lt;Help&gt; Simple Pause Needed.

On Thu, 2 Oct 2003 18:59:40 +0100, "Buster" <noone@nowhere. com> wrote:
[color=blue]
>Use a string, and use getline. You can look at the first position of
>a string using the [] indexing operator, but remember the positions
>are numbered from zero.[/color]

Ah, thats right. Thanks for the correction.
[color=blue]
>No, because `continue' is a keyword.[/color]

Ah, I knew that! Just slipped my mind when making the example. That
just shows I need to pay more attention to the little details and not
take things for granted in coding. :)
[color=blue]
>What would be simpler, though, is:
>
>while (true)
>{
> std::cout << "Do you want to continue (Y/N)?\n";
>
> std::string response;
> std::getline (std::cin, response);
>
> if (response [0] != 'Y') break;
>}[/color]

Yes, I like this method much better. It was in Johnathans last post
that I learned you can "break" from any type of loop and not just
switch.

Thanks!!

[Buster]

Re: &lt;Help&gt; Simple Pause Needed.


"da Vinci" <blank@blank.co m> wrote

[color=blue]
> Basically, take the function I am writing, take the first line of it,
> and post that at the top of the code as well?[/color]

Mostly, yes. In a 'real' program you might put the declarations
in a header file (and/or in a namespace or possible a class...)
but if you want to send your teacher a single compilable file
and you need to refer to a function before it is defined then
copy-paste is a nice easy way to do the forward declaration.

[...]
[color=blue]
> Ah, so you can use break to end any loop, not just a switch? I didn't
> know that. That will help a great deal.[/color]

I usually have to look it up. Let's see (from Borland online help):
"Use the break statement within loops to pass control to the first
statement following the innermost switch, for, while, or do block."

That last word always got me. It doesn't have to be a block, it can
be a statement, as in

for (int i = 0; i < 10; ++ i) if (std::rand () < 10) break;
[color=blue]
> That ok. I read the FAQ section on that. I always take things with a
> grain of salt and try not to get up in arms at negative replies. Life
> is to short to induce a heart attack... especially when your only 25.
> :)[/color]

Amen.

Regards,
Buster.

[Jonathan Mcdougall]

Re: &lt;Help&gt; Simple Pause Needed.

> > > > > cout << "\n\n\nSelectio n: ";[color=blue][color=green][color=darkred]
> > > >
> > > > Use std::endl instead of \n, which is not guaranteed to work
> > > > everywhere.
> > >
> > > Eh?
> > >
> > > -Mike[/color]
> >
> > Mmm.. I though \n was not portable, I should have informed myself.
> > Let me rephrase.
> >
> > I prefer using std::endl since it is clearer than a bunch of \n.
> > It is also supposed to flush the buffer, but flushing the buffer
> > does not necessrily mean that the data is written.[/color]
>
> Again, Eh?[/color]

I prefer using std::endl since it is clearer than a bunch of \n.

What's more, since std::cout is buffered, std::end flushes it. That
does not mean the output will automatically get on the stdout though,
since operating systems usually provide some buffering themselves
(this applies to all streams). To make sure the data gets written,
you should use implementation-specific functions which deal with
the operating system's buffer.

But usually, flushing the buffer is enough. Note that std::cout
flushes the buffer when it is destroyed (ie at the end of the
program), but you may have no time to see the output (in case
of outputting to stdout when there is a screen on your system)
so make sure you flush the buffer yourself when you are
finished writing.

Finally, '\n' may flush the buffer or not, this is not defined
(just as it may flush it with any character).

Interesting note that I found in my researches, \n is
translated into its equivalent depending on the platform.
For example, when writing to a text file, Windows needs a
\r\n and Mac gets a \r.


Jonathan

[WW]

Re: &lt;Help&gt; Simple Pause Needed.

Jonathan Mcdougall wrote:
[SNIP][color=blue]
> I prefer using std::endl since it is clearer than a bunch of \n.
>
> What's more, since std::cout is buffered, std::end flushes it. That[/color]
[SNIP]

Sometimes it is better to not use std::endl but make a flush at the end.
For example if you are printing in a loop, there can be serious difference
in time.

--
WW aka Attila

[Mike Wahler]

Re: &lt;Help&gt; Simple Pause Needed.

"Jonathan Mcdougall" <jonathanmcdoug all@DELyahoo.ca > wrote in message
news:k5%eb.5830 $yV2.104971@web er.videotron.ne t...
[color=blue][color=green][color=darkred]
> > > I prefer using std::endl since it is clearer than a bunch of \n.
> > > It is also supposed to flush the buffer, but flushing the buffer
> > > does not necessrily mean that the data is written.[/color]
> >
> > Again, Eh?[/color]
>
> I prefer using std::endl since it is clearer than a bunch of \n.[/color]

I disagree. Any C++ programmer will know what '\n' means.
As readily as what e.g. 'int' means. I suppose it can
vary among people, but I find '\n' simpler reading.
[color=blue]
> What's more, since std::cout is buffered, std::end flushes it.[/color]

Yes, I know. That's 'std::endl' :-)
[color=blue]
> That
> does not mean the output will automatically get on the stdout though,[/color]

Where did you hear that? What do you think 'flush' means,
in the context of an output stream?
[color=blue]
> since operating systems usually provide some buffering themselves
> (this applies to all streams).[/color]

Now you're outside the language. Nothing to do with
flushing a stream. And your generalization 'all streams'
is incorrect.
[color=blue]
>To make sure the data gets written,
> you should use implementation-specific functions which deal with
> the operating system's buffer.[/color]

I vehemently disagree. If this were the case, C++ would
fail in its role as a platform independent language.
[color=blue]
> But usually, flushing the buffer is enough.[/color]

"Usually", flushing a buffer is not necessary at all.
[color=blue]
>Note that std::cout
> flushes the buffer when it is destroyed[/color]

During 'cout's destruction, it (the stream) is flushed.
[color=blue]
>(ie at the end of the
> program), but you may have no time to see the output[/color]

Huh?

So you're saying that if I run:

#include <iostream>
int main()
{
std::cout << "Hello world\n";
return 0;
}

... that the output might disappear immediatly after
appearing on the output device to which 'cout' is
attached? I don't think so. An IDE might interfere
with a 'screen' output, but that's outside the language.
[color=blue]
>(in case
> of outputting to stdout when there is a screen on your system)[/color]

Absolutely not true.
[color=blue]
> so make sure you flush the buffer yourself when you are
> finished writing.[/color]

Unnecessary, unless you require that the output appear
*immediately* after inserting data into the stream.
And it's not even necessary if a 'cout' insertion
is followed by a 'cin' extraction, since by defintion,
a 'cin' extraction will first cause 'cout' to be flushed
if necessary (look up 'tie()').
[color=blue]
>
> Finally, '\n' may flush the buffer or not,[/color]

'\n' is not an operation. It's a value, that's all.
It cannot 'do' anything. A function might behave
in a particular way upon encountering it, this
behavior perhaps causing a flush.
[color=blue]
>this is not defined
> (just as it may flush it with any character).
>
> Interesting note that I found in my researches, \n is
> translated into its equivalent depending on the platform.[/color]

That is common knowledge. It's a feature of a 'text mode'
stream, well documented.
[color=blue]
> For example, when writing to a text file, Windows needs a
> \r\n and Mac gets a \r.[/color]

I know this.

No offense, but I think you're suffering from a few
misconceptions.

-Mike

[Jonathan Mcdougall]

Re: &lt;Help&gt; Simple Pause Needed.

> > > > I prefer using std::endl since it is clearer than a bunch of \n.[color=blue][color=green][color=darkred]
> > > > It is also supposed to flush the buffer, but flushing the buffer
> > > > does not necessrily mean that the data is written.
> > >
> > > Again, Eh?[/color]
> >
> > I prefer using std::endl since it is clearer than a bunch of \n.[/color]
>
> I disagree. Any C++ programmer will know what '\n' means.
> As readily as what e.g. 'int' means. I suppose it can
> vary among people, but I find '\n' simpler reading.[/color]

This is a personal opinion. I like the look of

std::cout << "hey" << std::endl;

better than

std::cout << "hey\n";
[color=blue][color=green]
> > That
> > does not mean the output will automatically get on the stdout though,[/color]
>
> Where did you hear that? What do you think 'flush' means,
> in the context of an output stream?[/color]

Ok let me rephrase that :)

Flushing will send the stream's content to stdout, but the operating
system is free to do whatever it wants with it.
[color=blue][color=green]
> > since operating systems usually provide some buffering themselves
> > (this applies to all streams).[/color]
>
> Now you're outside the language.[/color]

I know.
[color=blue]
>Nothing to do with
> flushing a stream. And your generalization 'all streams'
> is incorrect.[/color]

Explain.
[color=blue][color=green]
> >To make sure the data gets written,
> > you should use implementation-specific functions which deal with
> > the operating system's buffer.[/color]
>
> I vehemently disagree.[/color]

woaa :)
[color=blue]
>If this were the case, C++ would
> fail in its role as a platform independent language.[/color]

I think we agree that after a buffer has been flushed, the
operating system is free to do whatever it wishes to,
like waiting for another operation to terminate before
completing writing the data.

Using implementation-specific functions will give you
more control on the way the data reaches
destination. That's all I meant.
[color=blue][color=green]
> > But usually, flushing the buffer is enough.[/color]
>
> "Usually", flushing a buffer is not necessary at all.[/color]

What do you mean?
[color=blue][color=green]
> >(ie at the end of the
> > program), but you may have no time to see the output[/color]
>
> Huh?
>
> So you're saying that if I run:[/color]

No.
[color=blue]
> #include <iostream>
> int main()
> {
> std::cout << "Hello world\n";
> return 0;
> }
>
> .. that the output might disappear immediatly after
> appearing on the output device to which 'cout' is
> attached? I don't think so. An IDE might interfere
> with a 'screen' output, but that's outside the language.[/color]

That is what I talked about, sorry, I was probably not
explicit enough.
[color=blue][color=green]
> >(in case
> > of outputting to stdout when there is a screen on your system)[/color]
>
> Absolutely not true.[/color]

What is not true?
[color=blue][color=green]
> > so make sure you flush the buffer yourself when you are
> > finished writing.[/color]
>
> Unnecessary, unless you require that the output appear
> *immediately* after inserting data into the stream.[/color]

That is what I meant, yes.
[color=blue]
> And it's not even necessary if a 'cout' insertion
> is followed by a 'cin' extraction, since by defintion,
> a 'cin' extraction will first cause 'cout' to be flushed
> if necessary (look up 'tie()').[/color]

Who's talking about cin?
[color=blue][color=green]
> >
> > Finally, '\n' may flush the buffer or not,[/color]
>
> '\n' is not an operation. It's a value, that's all.
> It cannot 'do' anything. A function might behave
> in a particular way upon encountering it, this
> behavior perhaps causing a flush.[/color]

To quote myself :
(just as it may flush it with any character).

[color=blue][color=green]
> >this is not defined
> > (just as it may flush it with any character).
> >
> > Interesting note that I found in my researches, \n is
> > translated into its equivalent depending on the platform.[/color]
>
> That is common knowledge. It's a feature of a 'text mode'
> stream, well documented.[/color]

So what?
[color=blue][color=green]
> > For example, when writing to a text file, Windows needs a
> > \r\n and Mac gets a \r.[/color]
>
> I know this.[/color]

That post was not intended to teach you things you know, it
was primarly for the op. But thanks for the corrections.
[color=blue]
> No offense, but I think you're suffering from a few
> misconceptions.[/color]

Perhaps.


Jonathan