Re: sorting the input
On Sep 24, 12:31 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
On Fri, 19 Sep 2008 13:30:52 -0700 (PDT), James Kanze
<james.ka...@gmail.com> wrote:
On Sep 19, 12:55 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
On Wed, 10 Sep 2008 17:06:16 +0500, arnuld <sunr...@invalid.address> w=
rote:
...
std::cout << "--------------------------------"
<< std::endl;
I would skip the std::endl here though, and use "...---\n" instead.
Sounds like premature optimization to me.
No, it's more "do not do things without a reason" or "use the
simplest construct which does what I want".
And what do you want? To write data to disk, or to create
confusion when your program crashes?
std::endl is not "the thing you should use instead of '\n'"
(although many people believe it is, for some reason).
Just the opposite. Most of the time, std::endl is preferable.
With '\n', you never know when your data is going to end up on
disk.
My reasoning is the opposite of yours. Most of the time I
don't care when the data hits disk[1], and I make this clearer
by not using std::endl.
If you don't care when it hits the disk, the fastest solution is
not to write it in the first place:-). It will never hit the
disk, but since you don't care when it hits the disk...
Most of the time, I find just the opposite to be the problem; I
can't acknowledge a request until I'll sure that the data has
been physically written to the disk. Which can't be achieved
with a filebuf, so I have to use system level I/O.
Flushing a stream doesn't cause data to "hit the disk", at least
not on the systems I use (Solaris, Linux). It's basically a
memcpy to system memory, no more, no less, with a couple of
updates to control variables.
(OK, I admit I also have this suspicion -- not confirmed by
experiments -- that std::endl means a large performance hit in
some situations. I don't want my Unix pipelines to run at
half the speed because there is extensive I/O flushing
somewhere along the way.)
If you're outputting to a pipe, you almost certainly want at
least line buffering. The other side can't read it until it's
gotten to the OS. (Strictly speaking, what you actually want is
that the other side will be able to read the data "promptly".
If you're outputting a lot of data in a tight loop, and you
actually see a slow down, you might want to consider moving the
flush out of the loop. But you definitely want a flush at the
end of any isolated write.)
[...]
[1] Or whatever endl guarantees on my system; I assume it will at
least leave the application.
endl guarantees a flush. A flush guarantees that the data will
be transmitted to the host environment. I don't know what that
really means under Windows, but under Unix, it only means a
memcpy, more or less, to the system buffer. It's not free
(there is a context switch), but it's not that expensive either.
If the writes were actually synchronized, and you had to wait
for the disk, it would be a different issue. Still a question
of optimization, in a way, but at least on the systems I work
on, a synchronized write takes around 10 ms.
--
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