Re: Catching exceptions
On May 12, 10:04 am, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On May 11, 10:43 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
On Mon, 11 May 2009 01:52:15 -0700 (PDT),
magnus.morab...@gmail.com <magnus.morab...@gmail.com> wrote:
I have the following incomplete code -
File file;
file.open(filePath);
try
{
someOneElsesApi::startComplexProcessingOfFile(file);
std::cout << "The file is now processed" << std::endl;
Do you use std::endl here because you explicitly want flushing
of cout at this point, or because you mistakenly think \n is
not portable?
Or most likely, because it is the standard way of terminating a
line. (Standard in the sense of "usual or default practice".)
At least from what he's posted, there's no reason to assume that
the flush is causing a performance problem, so there's no reason
to not use std::endl.
It's also debatable whether
#include <iostream>
int main() { std::cout << "Bah\n"; }
is guaranteed to produce any output at all.
Since when? The standard guarantees that flush will be called
on all of the standard stream objects during a clean shutdown.
(There may be problems if you output to std::cout in the
destructor of a static object. The stream is guaranteed not to
be destructed, but you might have to manually ensure the flush
to ensure that data is actually output.)
Of course, one of my major arguments for using std::endl instead
of '\n', by default, is that, like it or not, not all shutdowns
are clean. And debugging is a lot easier if the output is
actually indicative of how far the program has gotten.
I don't know (though I suspect answer is "no") and don't care,
but anyone recommending not using endl and criticizing others
for using it should know and be able to back it up with some
quote from the standard.
It's more an engineering issue than a standards one. Basically,
std::endl is the "standard" way of terminating a line (standard
in the sense of "usual" or "accepted practice", not in the sense
of ISO/IEC 14882); replacing it with '\n' is an optimization.
Which shouldn't be undertaken prematurely.
--
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