Defect: std::endl in (a) 22.2.8/5, (b) 22.2.8/11, (c) 22.2.8/13, (d) 27.6.1.3/22

[Alf P. Steinbach]

std::endl is declared by <ostream>, which is not necessarily
included by <iostream>.

The cited paragraps, (a) 22.2.8/5, (b) 22.2.8/11, (c) 22.2.8/13 and
(d) 27.6.1.3/22, contain program examples that use std::endl without
including <ostream>, just <iostream>, and even though the unofficial
revision list for C++2003 contains a fix for e.g. 22.2.8/11 this issue
has not been fixed there (I don't have the C++2003 standard).

My suggested resolution is to keep the examples as-is but ensure that
the declaration of std::endl is available via <iostream>, since this
is commonly assumed, both in textbooks and actual code. Is there any
problem in stating that <ostream> is included by <iostream>? Otherwise
one can simply state that std::endl is available via <iostream>.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

[Alberto Barbati]

Alf P. Steinbach wrote:
> std::endl is declared by <ostream>, which is not necessarily
> included by <iostream>.
>
> The cited paragraps, (a) 22.2.8/5, (b) 22.2.8/11, (c) 22.2.8/13 and
> (d) 27.6.1.3/22, contain program examples that use std::endl without
> including <ostream>, just <iostream>, and even though the unofficial
> revision list for C++2003 contains a fix for e.g. 22.2.8/11 this issue
> has not been fixed there (I don't have the C++2003 standard).
>

Well, if you want to be fussy, it's not a problem of std::endl only. If
<iostream> did not eventually include <ostream> then *any* meaningful
use of std::cout, including std::cout << "hello, world\n", would be
ill-formed, because all the necessary overloads of operator<< are
defined in <ostream>. Ditto for std::cin.

> My suggested resolution is to keep the examples as-is but ensure that
> the declaration of std::endl is available via <iostream>, since this
> is commonly assumed, both in textbooks and actual code. Is there any
> problem in stating that <ostream> is included by <iostream>? Otherwise
> one can simply state that std::endl is available via <iostream>.
>

Maybe it would simpler to add in the <iostream> synopsis in 27.3 the two
lines:

#include <istream>
#include <ostream>

just like the <ios> synopsis in 27.4 explicitly provides #include <iosfwd>.

Alberto

[dietma...@yahoo.com]

Alf P. Steinbach wrote:
> std::endl is declared by <ostream>, which is not necessarily
> included by <iostream>.

Actually, this is an old problem: I first reported it in 1998 (see:
<http://groups-beta.google.com/group/comp.std.c++/msg/6f6abf4bc98c3d20?output=gplain>)
but it was always considered to not really be a problem:
essentially it was agreed that all implementation are better off doing
the right thing. Despite Nathan Myers' claim that there certainly will
be a defect report on this issue, I don't think there was ever a defect
reported. I never bothered to write a defect, partially because I don't
think it is one: I would like to *NOT* include <istream> and/or
<ostream> in my implementation when including <iostream>. Essentially,
<iostream> is the wrong header in many situations where it currently
seems to do the right thing. Unless you need to use one of the eight
standard stream objects, you should not include it because a popular
initialization technique for these objects takes up some time during
start-up and finalization for each translation unit including
<iostream>.
--
<mailto:dietma...@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

[dietma...@yahoo.com]

Alf P. Steinbach wrote:
> The cited paragraps, (a) 22.2.8/5, (b) 22.2.8/11, (c) 22.2.8/13 and
> (d) 27.6.1.3/22, contain program examples that use std::endl without
> including <ostream>, just <iostream>, and even though the unofficial
> revision list for C++2003 contains a fix for e.g. 22.2.8/11 this
issue
> has not been fixed there (I don't have the C++2003 standard).

Just another note (I didn't realize that you are actually talking
about Chapter 22): all uses of 'std::endl' in the quoted clauses
are ill-advised anyway! Especially bad is the first one: 'std::cout'
is 'tie()'ed to 'std::cin' and is thus flushed prior to a read
attempt on 'std::cin' anyway. Excessive use of 'std::endl' can
cause unnecessary performance problems! The only legitimate reason
to use 'std::endl' is in my opinion for log files and even for these
you are probably better off setting 'std::ios_base::unitbuf' anyway...

--
<mailto:dietma...@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

---

[Thomas Mang]

<dietma...@yahoo.com> schrieb im Newsbeitrag
news:1105974195.0...@f14g2000cwb.googlegroups.com...

> Alf P. Steinbach wrote:
> > std::endl is declared by <ostream>, which is not necessarily
> > included by <iostream>.
>
> Actually, this is an old problem: I first reported it in 1998 (see:
>
<http://groups-beta.google.com/group/comp.std.c++/msg/6f6abf4bc98c3d20?outpu
t=gplain>)
> but it was always considered to not really be a problem:
> essentially it was agreed that all implementation are better off doing
> the right thing. Despite Nathan Myers' claim that there certainly will
> be a defect report on this issue, I don't think there was ever a defect
> reported. I never bothered to write a defect, partially because I don't
> think it is one: I would like to *NOT* include <istream> and/or
> <ostream> in my implementation when including <iostream>. Essentially,
> <iostream> is the wrong header in many situations where it currently
> seems to do the right thing. Unless you need to use one of the eight
> standard stream objects, you should not include it because a popular
> initialization technique for these objects takes up some time during
> start-up and finalization for each translation unit including
> <iostream>.

I don't have an opinion if <iostream> should include <ostream> and <istream>
[even if I had, it wouldn't matter at all]. Doing it not seems to match with
the "Don't pay for something you don't need" rule; and just because many
books or references get it wrong, that doesn't mean it's the Standard
faults.

However, search for examples in the 2003-version of the Standard. I haven't
counted, but I think all the first 5 or so I found were wrong, because they
included only <iostream>. Now I know examples are non-normative, but
frankly, what style does the Standard propagate if it doesn't get it's own
code snippets right?

I am convinced at least the Standard has to be fixed - whatever the solution
might be. Current situation cannot be accepted IMHO.
I was also surprised that, although the issue is known for many years now,
nobody corrected it in the 2003 review.

Thomas