Re: A small game
On Sep 18, 12:38 am, glen stark <m...@nospam.glenstark.net> wrote:
On Wed, 17 Sep 2008 13:38:24 -0700, James Kanze wrote:
I know that the difference exists, but I've never
encountered a case where it was significant. At any rate,
it's a performance issue, only to be addressed once the
program actually works.
For beginners, it is absolutely essential that what they've
written be output, so that they don't get confused when
debugging. And even for experienced programmers, if the
program crashes, it's a lot easier to figure out what went
wrong if the data you wrote actually made it to the disk.
For the most part I agree with you. Generally, if I have a
performance critical application (numeric integration say, or
and FDTD loop), I'll pull the output somewhere outside the
loop so I'm not writing output every small step. If I do need
output somewhere where the performance hit from buffer
flushing is critical, it's usually because I'm debugging, and
so I'm more concerned with reliable and complete output than
with efficiency.
In defense of the parent however, there exist problem domains
where these arguments don't hold. I also encounter them from
time to time. An example is outputting largeish matrices.
These kind of judgements often depend heavily on what kind of
coding you do.
I didn't say you should never user '\n' instead of std::endl. I
sais that std::endl should be the default. If I'm outputting
something in a loop, I'll usually use '\n' in the loop, and
manually flush() the buffer after the loop (which is probably
premature optimization). But that's something that you learn to
do after you've mastered the basics. And it still means that
using std::endl is the "default" reaction.
Similarly, one can argue that you should never output two
string literals one after the other: let the compiler do the
contatenation, e.g.:
dest << "first line\n"
"second line\n" // Note the absense of <<
"line with " << variable << "\n"
"and so on" << std::endl ;
Again, it's not a good default (although I've been known to do
it is specific cases).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34