endl use

[RB]

In using-> endl I read mixed information. Some say the only times
that flushing is an issue is when you are accessing files that have been
open awhile. In other words ( I read ) that cin and cout are tied together
and any request for input on cin will automatically flush cout. While
on files ( I read ) the stream implementation '\n' is interpreted correctly by
the stream class. If one checked the data that is stored in the file (read the
file in binary mode) one could see the conversion:
*nix: '\n'
MS-DOS/MS-Windows: '\r\n'
MAC: '\r'
In essence many said using '\n' is completely portable and always has been.
The c++ standards did not change that.
==============================================
However, I see no problem with using endl myself. My question is:
I surmise that I am "covered" in whatever theory if I do the \n" on all
lines except the last one for each cout ? As example:
cout << "First real looooooooooooooooooooooooooooooong line\n"
<< "second real looooooooooooooooooooooooooooong line\n"
<< "and finish with line" << endl;

 

[James Kanze]

In using-> endl I read mixed information. Some say the only
times that flushing is an issue is when you are accessing
files that have been open awhile. In other words ( I read
) that cin and cout are tied together and any request for
input on cin will automatically flush cout. While on files
( I read ) the stream implementation '\n' is interpreted
correctly by the stream class. If one checked the data that is
stored in the file (read the file in binary mode) one could
see the conversion:
*nix: '\n'
MS-DOS/MS-Windows: '\r\n'
MAC: '\r'
In essence many said using '\n' is completely portable and
always has been. The c++ standards did not change that.
==============================================
However, I see no problem with using endl myself. My question
is: I surmise that I am "covered" in whatever theory if I do
the \n" on all lines except the last one for each cout ? As
example:
cout << "First real looooooooooooooooooooooooooooooong line\n"
<< "second real looooooooooooooooooooooooooooong line\n"
<< "and finish with line" << endl;

When the program terminates normally, and is only writing
relatively small files, whether you use endl or '\n' doesn't
matter. When the program doesn't terminate normally, using endl
means that you'll be able to figure out just how far it got,
just by looking at the files it wrote. When writing very large
files, on the other hand, endl can reduce throughput
considerably.

In general, I find it more readable to put one line per cout.
If I'm writing a sequence of output lines (with no intervening
code), I'll usually use '\n' on all but the last. Otherwise,
I'll use endl. Until I have a real performance problem.

 

[Jorgen Grahn]

Here you switch subject to portability -- that \n becomes the native
end-of-line when you write to a file in text mode. Yes it does.

Well, or whatever MacOS is using these days.

And that is the truth. I think people got confused by the
introduction of std::endl. If you don't know that it flushes, you're
inclined to think "well, they added it because \n isn't portable",

I see no claims above that it would be a problem, but there *can* be a
performance penalty in some situations.

You are "covered" even if you never use std::endl at all -- but of
course you will not get the flushing effect.

When the program terminates normally, and is only writing
relatively small files, whether you use endl or '\n' doesn't
matter. When the program doesn't terminate normally, using endl
means that you'll be able to figure out just how far it got,
just by looking at the files it wrote. When writing very large
files, on the other hand, endl can reduce throughput
considerably.

In general, I find it more readable to put one line per cout.
If I'm writing a sequence of output lines (with no intervening
code), I'll usually use '\n' on all but the last. Otherwise,
I'll use endl. Until I have a real performance problem.

Also see the old thread around
Message-ID: <[email protected]>
where some of us for once disagreed with James about when to
use std::endl.

/Jorgen

 

[Francesco S. Carta]

Also see the old thread around
Message-ID:<[email protected]>

I'd like to read that thread but I'm unable to get there using your
reference. Could you please paste the subject line or some other notable
sentence (verbatim) so that I can search for it?

 

[Jorgen Grahn]

I'd like to read that thread but I'm unable to get there using your
reference. Could you please paste the subject line or some other notable
sentence (verbatim) so that I can search for it?

If your news server doesn't still have it, go to Google Groups
"Advanced Search", "Lookup the message with message ID", and enter

[email protected]

(Oddly, if you include the angle brackets, the search will fail --
even though the RFCs state that they are part of the Message-Id.)

Just for reference, it started with this posting:

From: arnuld <[email protected]>
Newsgroups: comp.lang.c++
Subject: sorting the input
Date: Wed, 10 Sep 2008 17:06:16 +0500
Message-ID: <[email protected]>

/Jorgen

 

[Francesco S. Carta]

If your news server doesn't still have it, go to Google Groups
"Advanced Search", "Lookup the message with message ID", and enter

[email protected]

(Oddly, if you include the angle brackets, the search will fail --
even though the RFCs state that they are part of the Message-Id.)

Thank you very much for the instructions. Actually no, my news server
does not allow me searching for message ID, and I wasn't aware of that
GG search feature. Now I found it and I think I've also cleared out a
misunderstanding of mine (I thought that it was just the message ID
related to _your_ news server, and I implied that the same message on my
server would have had a different ID, now I think that actually _that_
is _the_ ID for that message... don't worry if I still haven't gotten it
straight, I'll have a look to the appropriate RFC to clear this out)

Thanks again

 

[Jorgen Grahn]

Thank you very much for the instructions. Actually no, my news server
does not allow me searching for message ID,

Maybe not all do ... and anyway the thread was in 2008 so they may not
have it today; it's probably expired.

and I wasn't aware of that
GG search feature. Now I found it and I think I've also cleared out a
misunderstanding of mine (I thought that it was just the message ID
related to _your_ news server, and I implied that the same message on my
server would have had a different ID, now I think that actually _that_
is _the_ ID for that message... don't worry if I still haven't gotten it
straight, I'll have a look to the appropriate RFC to clear this out)

That's ambitious ;-) I'm writing a toy news server in my spare time;
that's why I went into details.

People normally refer to old postings by their Google Groups URL, but
those URLs are 100+ characters long and unwieldy, or I would have
given that one for the thread. If Google also have URLs which make
more sense (e.g. http://groups.google.com/<msgid>) I haven't seen
anyone use them.

/Jorgen

 

[Alf P. Steinbach /Usenet]

* Jorgen Grahn, on 30.07.2010 12:38:

People normally refer to old postings by their Google Groups URL, but
those URLs are 100+ characters long and unwieldy, or I would have
given that one for the thread. If Google also have URLs which make
more sense (e.g. http://groups.google.com/<msgid>) I haven't seen
anyone use them.

They had them in original Google Groups. Then they removed them and added
messing-up of valid signature delimiters for Usenet postings.

Cheers & hth.,

- Alf

 

[Francesco S. Carta]

Maybe not all do ... and anyway the thread was in 2008 so they may not
have it today; it's probably expired.

Small correction, it's my news _reader_ that doesn't allow me to - at
least, not by default (the search fields are "author" and "subject"). I
think I can add a custom field, and maybe that would work, but it's very
likely that they do not archive threads that old.

That's ambitious ;-) I'm writing a toy news server in my spare time;
that's why I went into details.

Your first line above seems to tell me that reading that RFC is not
exactly childplay ;-) Can you save me some headache and confirm that
messages get an unique ID tied to the originating news server,
(potentially) recognized everywhere?

People normally refer to old postings by their Google Groups URL, but
those URLs are 100+ characters long and unwieldy, or I would have
given that one for the thread. If Google also have URLs which make
more sense (e.g. http://groups.google.com/<msgid>) I haven't seen
anyone use them.

This will work, just following from your suggestion:

http://groups.google.com/[email protected]

As per the GG generated link, it should be:

http://groups.google.com/groups/[email protected]

(in the former I dropped the "groups/" part but it works fine anyway)

....not as short as we'd like them, and chances are that some newsreader
will break/wrap the line somewhere, but still

 

[Peter Nimmo]

Small correction, it's my news _reader_ that doesn't allow me to - at
least, not by default (the search fields are "author" and "subject"). I
think I can add a custom field, and maybe that would work, but it's very
likely that they do not archive threads that old.



Your first line above seems to tell me that reading that RFC is not
exactly childplay ;-) Can you save me some headache and confirm that
messages get an unique ID tied to the originating news server,
(potentially) recognized everywhere?


This will work, just following from your suggestion:

http://groups.google.com/[email protected]

As per the GG generated link, it should be:

http://groups.google.com/groups/[email protected]

(in the former I dropped the "groups/" part but it works fine anyway)

...not as short as we'd like them, and chances are that some newsreader
will break/wrap the line somewhere, but still

--
  FSC -http://userscripts.org/scripts/show/59948
 http://fscode.altervista.org-http://sardinias.com- Hide quoted text -

- Show quoted text -

In every single of these messages the message-id has embedded "..." in
it. Even when I go to show original, under More Options. It also
doesn't seem to be valid when I click it either!

 

[Francesco S. Carta]

In every single of these messages the message-id has embedded "..." in
it. Even when I go to show original, under More Options. It also
doesn't seem to be valid when I click it either!

Blame Google Groups, they mangle everything that looks like an email
address so that you cannot directly see it.

If you're interested in this particular thread we linked, this is the
message id:

gbdhoa$pb9$1 @ cb.generation-online.de

paste it after the "as_umsgid=" part in the links above, remove the
spaces and you'll be taken there.

 

[Jorgen Grahn]

Small correction, it's my news _reader_ that doesn't allow me to - at
least, not by default (the search fields are "author" and "subject"). I
think I can add a custom field, and maybe that would work, but it's very
likely that they do not archive threads that old.

This is a different kind of search. The NNTP protocol has an (optional)
command "give me the posting with this message ID, no matter which
groups it was posted to" and at least my client (slrn) has a function
which uses it.

Your first line above seems to tell me that reading that RFC is not
exactly childplay ;-)

I think C++ programmers will find these RFCs clear and simple, but
it *is* plenty of text to browse through.

Can you save me some headache and confirm that
messages get an unique ID tied to the originating news server,
(potentially) recognized everywhere?

Almost correct: either the client /or/ the first server is responsible
for somehow generating a globally unique ID for the message.

This will work, just following from your suggestion:

http://groups.google.com/[email protected]

As per the GG generated link, it should be:

http://groups.google.com/groups/[email protected]

(in the former I dropped the "groups/" part but it works fine anyway)

...not as short as we'd like them, and chances are that some newsreader
will break/wrap the line somewhere, but still

I guess that's acceptable. But when you have to do detective work to
produce these URLs (like you did) not many will do it. They'll
copy-and-paste from their browser's address bar.

/Jorgen

 

[Francesco S. Carta]

This is a different kind of search. The NNTP protocol has an (optional)
command "give me the posting with this message ID, no matter which
groups it was posted to" and at least my client (slrn) has a function
which uses it.

Ah, I see now. Thunderbird has not that feature built-in but I just
found an appropriate addon.

I think C++ programmers will find these RFCs clear and simple, but
it *is* plenty of text to browse through.

Good to know - for the future ;-)

For the moment, you saved me from getting that info by myself...

Almost correct: either the client /or/ the first server is responsible
for somehow generating a globally unique ID for the message.

....just here above, thank you

I guess that's acceptable. But when you have to do detective work to
produce these URLs (like you did) not many will do it. They'll
copy-and-paste from their browser's address bar.

I agree with you, not many will do. Now that I am able to search
messages by their ids I think I'll resort to mentioning just ids... if
some others will not be aware of this feature, I will then have to
explain them how to search for those messages (as you kindly did with
me) and that's fine: good distributed growth by mutual help