Defect Report: examples missing #include <istream> or #include <ostream>

Defect Report: examples missing #include <istream> or #include <ostream>

Post by AlbertoBar » Sat, 07 Oct 2006 00:03:30


Hi Everybody,

often on this NG and on comp.lang.c++.moderated, experts (correcly)
warns non-so-experts that including <iostream> alone does not guarantee
the inclusion of either <istream> and <ostream> as well. What about the
C++ standard? It seems that there are five different examples that are
lacking proper #includes. Those are:

14.6/8 misses #include <ostream>
22.2.8/5 misses #include <ostream> and #include <istream>
22.2.8/12 misses #include <ostream>
22.2.8/14 misses #include <ostream>
27.6.1.3/23 misses #include <ostream> and #include <istream>

(references are made against the latest publicly available WD, a few
paragraphs have different numbers in C++03.)

We can't fix all the books out there promoting this incorrectness, but
at least the standard should be correct, shouldn't it?

Regards,

Ganesh

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by petebecke » Sat, 07 Oct 2006 00:22:56


Yup, the standard shouldn't be sloppy. This doesn't need the formalism
of a defect report. It's an editorial correction. I've made a note to
fix it.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

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

 
 
 

Defect Report: examples missing #include <istream> or #include <ostream>

Post by Chris Jeff » Sat, 07 Oct 2006 03:29:27


Really this seems to me like the standard should just be changed and
these headers merged (although obviously for backward compatability
each header should remain).

Personally, I really hope that the C++0x standard has a <all> header,
which given suitably good precompiled header support in your compiler
should make life easier, and not be much slower, or possibly even
faster if you don't normally use precompiled headers (I'm imagining a
compiler could notice the common case of #include<all> being the first
line and automatically pull in a pre-compiled version without any user
interaction).

Chris

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by howard.hin » Sat, 07 Oct 2006 23:33:28

In article < XXXX@XXXXX.COM >,




I've no objection to adding additional includes to examples. But I
disagree that this issue is editorial. Just glancing at 14.6p8, I
disagree that <ostream> is required (and I doubt it is required in any
existing implementation). I've reopened LWG 343 to track this. Fwiw, I
don't agree with the proposed resolution in 343 either. However,
reasonable compromises to this problem have been proposed over the
years, and I would like to see them further explored.

HelloWorld should only require <iostream>. Anything else is a
significant usability hit to the language.

-Howard

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by Falk Tannh » Sat, 07 Oct 2006 23:59:44

Greg schrieb:

No, the class declarations are sufficient.
class foo;
extern foo f;
is well-formed.

Thus, it would be sufficient for <iostream> to include <iosfwd>.

Falk

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by howard.hin » Sun, 08 Oct 2006 02:04:57

In article < XXXX@XXXXX.COM >,



According to Martin and
http://www.yqcomputer.com/ #343, the
standard isn't clear one way or the other. We closed it as NAD/Future.
The Future is now. :-)

-Howard

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by greg » Sun, 08 Oct 2006 03:01:45


Not all requirements need to be explicitly stated. For example, we can
readily deduce that <iostream> must include <istream> and <ostream> from the
requirement that <iostream> must declare the global stream objects:
std::cout, std::cin and friends.

First, we know that in order for <iostream> to be able to declare the set of
global stream objects, the <iostream> header itself must be well-formed.
After all, an ill-formed <iostream> header has no chance of declaring
anything. And in order for <iostream> to be well-formed, it must include the
class definitions for the std::istream and std::ostream objects it is
obligated to declare. Furthermore, the definitions for these stream classes
are found (as the Standard also requires) in the <istream> and <ostream>
headers. Therefore we have successfully deduced that <iostream> must include
<istream> and <ostream> in order for it to declare the objects that the
Standards requires that it declare. So it should not come as a surprise,
that <iostream> always does include those two headers.

Nor are we alone in following this line of reasoning; the Standard itself
reaches the same logical conclusion that we just did (and no doubt for the
exact same reasons) when it states: "[Standard Library] C++ headers must
include a C++ header that contains any needed definition." 7.4.4.1
>> What about the >> C++ standard? It seems that there are five different examples that are >> lacking proper #includes. Those are: >> ... >> We can't fix all the books out there promoting this incorrectness, but >> at least the standard should be correct, shouldn't it?

The existing examples in the Standard are correct as written. And it would
be a shame to "wikipedify" the Standard and allow any change to be made just
as long as enough people (or enough, influential people) believe the change
should be made. In a Standard wikipedified in this manner, not even the
logic of its own requirements, the supporting evidence of every C++
implementation and just plain common sense would be allowed to stand in the
way of the force of popular opinion.

It may also be worth noting that Standard Library Issue #343 which deals
with ambiguous header dependencies in the C++ Standard, implicitly
acknowledges that< must include< and<. The issue
in #343 is actually which headers must< include.

Greg

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by gennaro_pr » Sun, 08 Oct 2006 04:35:20

On Fri, 6 Oct 2006 14:33:28 GMT, XXXX@XXXXX.COM (Howard



Well, were it just for HelloWorld... For one thing, I don't "use" it a
lot ;-) Seriously I think all this issue is a result of a completely
illogical header partitioning. Allowing headers to include other
headers was a quick "fix" which actually just worsens the problem; and
I have a hard time figuring out what the solution could be. The <all>
header, if you ask me, is like saying "ok, we were kidding; the
library is just one big thing and this is what you should include;
anything else is non-portable".

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by petebecke » Sun, 08 Oct 2006 12:50:14


The actual requirement in the standard is not that names be defined in
any particular header, but that they be defined when you issue a
#include directive that pulls in the contents of that header. For example:

/* header istream_def.h */
template ... class istream { ... }; // details omitted for brevity

/* header ostream_def.h */
template ... class ostream { ... }; // details omitted for brevity

/* header istream */
#include <istream_def.h>
// the rest of <istream>

/* header ostream */
#include <ostream_def.h>
// the rest of <ostream>

/* header iostream */
#include <istream_def.h>
#include <ostream_def.h>
// the rest of <iostream>

With this skeleton implementation, istream and ostream both have full
definitions of all the things they are required to provide. iostream
does, too, but it does not include <istream> or <ostream>, and it does
not have the non-member stream inserters and extractors that are defined
in <istream> and <ostream>.

An perverse, but allowable, implementation would simply repeat the
definitions of istream and ostream in the header <iostream>.


This is a footnote. Footnotes are not normative. And there's quite a bit
of stuff in chapter 17 that's descriptive rather than normative, and
often wrong. There is no experiment you can perform in standard C++ to
detect whether an implementation grabs stuff by including standard
headers, including implementation-specific common headers, or by
repeating definitions. So this assertion is simply empty.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by petebecke » Sun, 08 Oct 2006 12:50:29


I don't see any discussion of <iostream> in 343. It's only mentioned in
the proposed resolution.

The examples are highly unconvincing. I assume they're taken from actual
practice, in that they compile but rely on some headers defining things
they aren't required to define.


Yes, as it ought to be. And this is far too complex a change to
undertake in the guise of a defect report.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by AlbertoBar » Sun, 08 Oct 2006 12:50:58

Falk Tannhser ha scritto:

Precisely!


Exactly the opposite. Issue #343 makes the inclusion explicit. The point
is that the problem is real and it's a source of endless embarrassment
in the newsgroups. I just think it's time we address the issue in one
way or another, that is: either making the inclusion explicitly required
or explicitly not required. Frankly, I agree with Howard Hinnant that
HelloWorld should compile with <iostream> only. However, since the
current standard is actually saying the opposite and several gurus and
non-gurus agrees on that, I believed that argument would have been
easier to support and could have better chances of being approved.

Ganesh

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by AlbertoBar » Sun, 08 Oct 2006 12:51:33

Howard Hinnant ha scritto:

Could you please summarize the proposals that have already been made,
please?


If <iostream> does not include neither <istream> nor <ostream>, then a
compilation unit can't do very much with <iostream> only. The only
reasonable thing that it can do is to pass references to cin, cout... to
some other compilation unit. Otherwise, it will need to include either
<istream> or <ostream> sooner or later. It could be interesting to
estimate the number of real-life C++ programs out there that would not
include them. For what it's worth, I expect that most program would need
at least <ostream>, while <istream> might be a bit more rare. Frankly, I
would be rather pleased to avoid including them both ;-)

One compromise solution could be to add one more "fwd" file. For example
we could move the declarations of cin, cout, etc. into a <iostreamfwd>
file, with the following requirements:

1) it's unspecified whether <iostreamfwd> includes either <istream> or
<ostream>

2) <iostream> shall simply include <iostreamfwd>, <istream> and
<ostream> (not necessarily in this order)

Number 1) is to help implementors in the transition phase and possibly
to overcome some platform-specific issues.

Just my 2 eurocent,

Ganesh

PS: what about <fstream> and <sstream>? Should we treat them the same way?

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by gennaro_pr » Mon, 09 Oct 2006 13:02:43

On Sat, 7 Oct 2006 03:51:33 GMT, XXXX@XXXXX.COM (Alberto



I think implementors have already been helped too much, with the
"may-include-whatever-you-like" rule. And that has been to users'
detriment.

Since the usage of <iostream> to have also <ostream> and <istream>
seems (well, *is*) pre *** then probably that's what ought to be
ratified.

To have declarations of the eight stream objects only I'd prefer a
totally different name (not one derived by appending "fwd" to the
existing name; BTW I've always hated that suffix, as well as the name
"ios" which really says nothing --would you be able to intuit what the
difference is with "iostream"? All in all, it seems to me the standard
header names have been chosen just for the sake of choosing a name;
and then let's not get started about <exception> and <stdexcept>
and... ok, I said let's not get started ;-))


You see. It's a mess from which I doubt we'll ever come out :-(

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

Defect Report: examples missing #include <istream> or #include <ostream>

Post by jdennet » Mon, 09 Oct 2006 14:40:49


Often that's all I need; the TU that contains main doesn't
contain much else, but it might well refer to the standard
stream objects. Other TUs generally don't use <iostream>,
but rather are told which streams to use. For this style,
there's no need for anything more than a minimal <iostream>.

-- James

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