<Help> Simple Pause Needed.

[Mike Wahler]

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

"Jonathan Mcdougall" <jonathanmcdoug all@DELyahoo.ca > wrote in message
news:%L%eb.6529 $yV2.114654@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.
> > > >
> > > > Again, Eh?
> > >
> > > 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.[/color]

Agreed.
[color=blue]
> I like the look of
>
> std::cout << "hey" << std::endl;
>
> better than
>
> std::cout << "hey\n";[/color]

But note that the code one writes is quite often
read by others. This is imo good reasons to
follow 'convention'. Consistency Is Good(tm).

Also note that since 'endl' does cause a flush,
you're possibly slowing down the program, often
unnecessarily. This might not be noticable in some
cases, but could significantly impact performance
in others. E.g. writing 'endl' to an ofstream
attached to a file on a floppy disk, or other
inherently 'slow' device, such as a printer.
[color=blue]
>[color=green][color=darkred]
> > > 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,[/color]

Flushing will send any data not yet written to the
device to which the stream is attached.
[color=blue]
>but the operating
> system is free to do whatever it wants with it.[/color]

You're outside the language again. One cannot
comment further about 'behavior' at that point
from a language perspective.
[color=blue]
>[color=green][color=darkred]
> > > since operating systems usually provide some buffering themselves
> > > (this applies to all streams).[/color]
> >
> > Now you're outside the language.[/color]
>
> I know.
>[color=green]
> >Nothing to do with
> > flushing a stream. And your generalization 'all streams'
> > is incorrect.[/color]
>
> Explain.[/color]

We're in a language perspective in this group. OS buffers
and their behavior are outside that domain.

"All streams" means all stream types, input, output,
or 'udpate' (input&output). Flushing is only defined
for output and 'update' streams.

Perhaps you were only being sloppy with terminology
and meant 'all output streams'. Which then would
omit 'update' streams. :-)
[color=blue]
>[color=green][color=darkred]
> > >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=green]
> >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[/color]

make that 'stream', and by implication, that stream's
'stream buffer'. 'stream buffer' is a language construct,
not part of an OS.
[color=blue]
>has been flushed, the
> operating system is free to do whatever it wishes to,[/color]

An OS has nothing to do with the description of the
flush operation of a C++ stream.
[color=blue]
> like waiting for another operation to terminate before
> completing writing the data.[/color]

The device to which a stream is attached might be a 'real'
hardware device, or it might be one 'simulated' by an
OS (e.g. 'virtual device' such as a 'RAM-disk'). The
behavior of such devices and control of such by an OS
is outside of a discussion about C++ streams.
[color=blue]
>
> Using implementation-specific functions will give you
> more control on the way the data reaches
> destination. That's all I meant.[/color]

Well, yes, platform-specific features can give 'finer-grained'
control over a system, but that's nothing to do with C++
streams, which are an *abstraction* of external data.
[color=blue]
>[color=green][color=darkred]
> > > But usually, flushing the buffer is enough.[/color]
> >
> > "Usually", flushing a buffer is not necessary at all.[/color]
>
> What do you mean?[/color]

I mean that in many situations, the 'automatic' flushing
of an output stream will already occur, as in my 'cout'
followed by 'cin' example. Also it's often good enough
to simply let flushing happen automatically when an output
stream gets destroyed. Of course there can be exceptions
to this, depending upon the problem domain. "Usually"
can mean many things to various people. It usually :-)
means "common to a person's experiences and observations."
[color=blue][color=green][color=darkred]
> > >(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=green]
> > #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,[/color]

Which part of the paragraph I wrote after that code
are you talking about? Is your answer to the question
yes or no? Were you talking about the 'IDE interference'?
If so, C++ stream flushing has nothing to do with that.
[color=blue]
>sorry, I was probably not
> explicit enough.[/color]

Effective communication can often be difficult. :-)
[color=blue][color=green][color=darkred]
> > >(in case
> > > of outputting to stdout when there is a screen on your system)[/color]
> >
> > Absolutely not true.[/color]
>
> What is not true?[/color]

Probably should have said "not necessarily true".

... that if std::cout is attached to a video display,
the data displayed after a flush might 'disappear'.
Nothing about the C++ streams will cause (or prevent) this
behavior. The data will be sent to the device (or if you
prefer, to the OS's interface for it). What happens after
that is outside the language.
[color=blue][color=green][color=darkred]
> > > 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]

But you were talking about this happening at program
termination. I meant 'midstream' during execution
where data is being output.
[color=blue]
>[color=green]
> > 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]

I gave it as a common example. It's very common to
have code such as:

std::cout << "Your name: ";
std::cin >> name;

There's no need to flush cout to ensure the prompt
appears before the input request occurs. This is
done automatically by default, via 'tie()'.

Contrast C's stdin and stdout, where a prompt
using 'printf()' needs a subsequent flush
before an input request e.g. with 'scanf()',
to ensure the prompt appears first.
[color=blue][color=green][color=darkred]
> > > 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]

I suppose I could have misunderstood your meaning.

No, there is nothing preventing the stream buffer
being flushed at whatever point the library implementor
(or a coder using a custom stream buffer) determines is
appropriate (this could be upon insertion of a character
with a certain value such as '\n' or some other value,
but there's no requirement for it).

One condition under which a flush with *always* happen
is when a character (with *any* value) is inserted,
but the stream buffer is already full. The stream
buffer must first be flushed in order to make room
for the new character.
[color=blue][color=green][color=darkred]
> > >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]

It just seemed to me that you felt you were pointing
out something not obvious to most C++ programmers.
[color=blue]
>[color=green][color=darkred]
> > > 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.[/color]

And anyone else reading. I try to intercept incorrect
or unclear information being imparted here. It also
gives others a chance to point out when I err myself.
[color=blue]
>But thanks for the corrections.[/color]

You're welcome. Please be assured that my motives
are educational, not attempts to appear 'smarter'
than you or anyone else. You should have seen the
confusion I sometimes suffered when learning C, so
many years ago. :-)
[color=blue]
>[color=green]
> > No offense, but I think you're suffering from a few
> > misconceptions.[/color]
>
> Perhaps.[/color]

Hope you've found my comments helpful.

-Mike

[Jonathan Mcdougall]

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

> >Be careful with them though. I suggest you take a look to std::vector[color=blue][color=green]
> >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.[/color]

Unfortunately, that is quite frequent with school. The best thing you
can do now is to help people. That will make you learn a lot. There
is nothing better than a stupid question to make you doubt about your
knowledge, forcing you to search for the answer.

Maybe silly, but easy questions are often harder to answer than
difficult ones.
[color=blue]
>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]

He. _Simply put_, a vector is an array which grows dynamically.
But since it does all the memory management itself, it is much
easier and safer to use.
[color=blue]
> 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]

If you want to put declaration in the same file, yes. If not, do
the same thing, but paste it in another file :)
[color=blue][color=green]
> >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]

No, there are a couple of guidelines and you will learn them as you
post here.
[color=blue][color=green]
> >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.[/color]

Namespaces are not only "extra typing". The basically avoid name
clashes. For example, having a class named 'vector' in your program
would clash with the standard vector class. Putting them into
namspace avoids that.

The thing is, you have absolutly no idea what classes are in the
namespace std in the headers you are including, so you could end
with weird compile errors.
[color=blue]
> We are not going to use our own namespaces in
> this class so I don't bother to much with it.[/color]

The good thing is that most librairies are in a namespace themselves,
so your code is quite protected from that, unless you dump all the
names with the using declaration.
[color=blue]
> 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]

Buy a book! If you never did programmation before, I recommend
something like "Thinking in C++" by Eckel (have a google, his book
is online). If not, get Accelerated C++ bu Koenig and Moo and
eventually the c++ bible "The C++ programming language" by
Stroustrup.
[color=blue][color=green]
> >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]

'break' breaks out of switch, do, while and for.

The most important thing is : stick up with this newsgroup, post, read,
comment, ask. That way you will learn much more than what you can do
in class or at home. Believe me. People here bark a lot, but they
don't bite :)


Jonathan