Skip to content

SL.io.50 (Avoid endl): Mention string streams #1920

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 13, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions CppCoreGuidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -20308,6 +20308,14 @@ For writing to a file, there is rarely a need to `flush`.

##### Note

For string streams (specifically `ostringstream`), the insertion of an `endl` is entirely equivalent
to the insertion of a `'\n'` character, but also in this case, `endl` might be significantly slower.

`endl` does *not* take care of producing a platform specific end-of-line sequence (like "\r\n" on
Windows). So for a string stream, `s << endl` just inserts a *single* character, `'\n'`.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or \n\r for Mac ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or \n\r for Mac ;)

@BenjamenMeyer You mean '\r', right? But hasn't Mac moved towards using just a single \n, nowadays? Otherwise, are there still actively used C++11 Standard Library implementations for Mac whose file output streams produce a '\r' on each end-of-line?

I did notice the smiley in your comment, but I just want to be entirely sure that it's OK not to mention the old Mac '\r' in the proposed text.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@N-Dekker AFAIK mac is still doing the \n\r - now, perhaps it changes from application to application, but I've still seen it in recent years. The new text called out the Windows behavior as an example; it could be worth noting (legacy or otherwise) the Mac behavior too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just want to be entirely sure that it's OK not to mention the old Mac '\r' in the proposed text.

Please don't mention Macs. Your proposed change is fine. What matters is that it doesn't output a platform-specific line ending, you don't need to give multiple examples of things it doesn't do.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with this PR documenting it ;) (e.g not a change - just the commentary here)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jwakely @BenjamenMeyer Thanks, I won't mention old Macs line endings, if it isn't really necessary. So I also think the PR is OK now.


##### Note

Apart from the (occasionally important) issue of performance,
the choice between `'\n'` and `endl` is almost completely aesthetic.

Expand Down
1 change: 1 addition & 0 deletions scripts/hunspell/isocpp.dic
Original file line number Diff line number Diff line change
Expand Up @@ -389,6 +389,7 @@ optimizable
O'Reilly
org
ostream
ostringstream
overabstract
overconstrain
overconstrained
Expand Down