Gennaro Prota wrote:
>
> While slowly recovering, however, I'd like to clarify my point (isn't
> that admirable? :-O): the reason why the include-what-you-like license
> is wrong is that, given how easy it is to forget a #include in user
> code, it makes programs non-portable.

Portability is not an absolute. Portable code is easy to move to another
platform. Non-portable code is not. This is not high on my list of
porting issues. If I missed a standard header and another compiler won't
compile my code, I add the appropriate #include directive.

--

 -- 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.comeaucomputing.com/csc/faq.html                      ]

Greg Herlihy ha scritto:
>
> But the point is simply: even if <iostream> does not need to include
> <istream> or <ostream> in order to define the global stream objects,
> then there would still be no reason for any of the code examples in
> Standard that include <iostream> - and in which the typenames "istream"
> and "ostream" never appear once - would need to include those two
> header files for reasons of their own. In other words, the Standard
> should simply clarify that declarations for global objects are declared
> with complete types. After all, why wouldn't they be?
>

It's true that, in these examples, neither istream nor ostream are
mentioned, but those example use overloads of operator<< and operator>>
that are explicitly defined in <istream> and <ostream>. That's a very
good reason for having them included. The fact that, as some of those
overloads are member functions, you have to also pull in the complete
types is purely accidental and not strictly necessary a priori.

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.comeaucomputing.com/csc/faq.html                      ]

James Kanze ha scritto:
> Alberto Ganesh Barbati wrote:
>
>> 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.
>
> <snip>
>
> (Note that I'm not against adding a lot of extra junk to
> <iostream>, given that 1) it's what most implementations do
> anyway, and 2) there are so few sources that include the header
> anyway.  But arguing that any source which includes <iostream>
> probably also needs <ostream> is arguing against basic software
> engineering principles like the separation of concerns.)
>

Well... it seems that we totally agree, then. Maybe my previous
statement was not well formulated but I never argued that a source
including <iostream> probably also needs <ostream>. I said: *either* it
passes references to cin/cout to some other TU *or* they need to include
<istream> or <ostream>. In the latter case, I expect <ostream> to occur
more often than <istream> (I know this fact is irrelevant to the
discussion, it would have been better if I didn't say it).

When I said that an estimate would be interesting, I really meant that,
I actually don't know which use-case is prevalent. I can only be sure
about the programs *I* wrote ;-)

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.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota wrote:
> On Sun,  8 Oct 2006 13:16:57 CST, "James Kanze" <kanze.james@neuf.fr>
> wrote:
>
>>>> 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.
>>> I've no objection to adding additional includes to examples.
>>> But I disagree that this issue is editorial.
>> Fixing the examples to conform with the normative parts of the
>> standard would seem just editorial to me.
>
> I don't know the rules about this but I'm still wondering why messages
> with a "Defect Report:*" subject accepted here no more have a
> forwarded-to-the-C++-committee note.

The reason that I replied as I did was precisely to avoid that.
Editorial corrections, by definition, don't need to go through the
defect report mechanism. They're handled by the Editor.

--

 -- 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.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
> Howard Hinnant wrote:
>> HelloWorld should only require <iostream>.  Anything else is a
>> significant usability hit to the language.
>
> Well, it does mean that you need one more line to write a hello,
> world program.  I'll admit, however, that I don't write such
> programs professionally,...

I'd like to add a comment as a university teacher. Although C++ is a
language meant for professionals, those professionals do not just pop out of
void. When people make decisions on which programming language to use in an
introductory level course, features such as these *do* matter somewhat. C++
already has a reputation as a language that is very difficult to master, and
if writing a correct HelloWorld program is difficult, I'm not at all
surprised fewer institutions choose C++ as their programming language.

--
------------- Matti Rintala ------------ matti.rintala@tut.fi ------------
Painting is the art of inclusion. Photography is an art of exclusion.

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:
> 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?
>

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.comeaucomputing.com/csc/faq.html                      ]

Howard Hinnant wrote:
> In article <afKdnVYqV_NjvbjYnZ2dnUVZ_oadnZ2d@giganews.com>,
>  petebecker@acm.org (Pete Becker) wrote:
>
>> Alberto Ganesh Barbati wrote:
>>> 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?
>>>
>> 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.
>
> 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).

Glancing at an example is not sufficient to determine what the standard
requires, nor is polling existing implementations. Please show me the
words in the standard that say that this is correct.

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

Yes, that's certainly what was intended. Where in the standard is it
required?

--

 -- 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.comeaucomputing.com/csc/faq.html                      ]

Greg schrieb:
> 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.

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.comeaucomputing.com/csc/faq.html                      ]

Greg wrote:
>=20
>=20
> First, we know that in order for <iostream> to be able to declare the s=
et 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 includ=
e the
> class definitions for the std::istream and std::ostream objects it is
> obligated to declare. Furthermore, the definitions for these stream cla=
sses
> are found (as the Standard also requires) in the <istream> and <ostream=
>
> headers. Therefore we have successfully deduced that <iostream> must in=
clude
> <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.
>=20

The actual requirement in the standard is not that names be defined in=20
any particular header, but that they be defined when you issue a=20
#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=20
definitions of all the things they are required to provide. iostream=20
does, too, but it does not include <istream> or <ostream>, and it does=20
not have the non-member stream inserters and extractors that are defined=20
in <istream> and <ostream>.

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

> Nor are we alone in following this line of reasoning; the Standard itse=
lf
> reaches the same logical conclusion that we just did (and no doubt for =
the
> exact same reasons) when it states: "[Standard Library] C++ headers mus=
t
> include a C++ header that contains any needed definition." =A717.4.4.1

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

--=20

 -- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and=20
Reference." For more information about this book, see=20
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.comeaucomputing.com/csc/faq.html                      ]

Howard Hinnant wrote:
> In article <peidnfn0T5zJ77vYnZ2dnUVZ_tGdnZ2d@giganews.com>,
>  petebecker@acm.org (Pete Becker) wrote:
>
>>> HelloWorld should only require <iostream>.  Anything else is a
>>> significant usability hit to the language.
>>>
>> Yes, that's certainly what was intended. Where in the standard is it
>> required?
>
> According to Martin and
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#343, the
> standard isn't clear one way or the other.

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.

> We closed it as NAD/Future.

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.comeaucomputing.com/csc/faq.html                      ]

Howard Hinnant ha scritto:
> However,
> reasonable compromises to this problem have been proposed over the
> years, and I would like to see them further explored.

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

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

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.comeaucomputing.com/csc/faq.html                      ]

Falk Tannh=E4user ha scritto:
> Greg schrieb:
>> 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.
>=20
> No, the class declarations are sufficient.
>   class foo;
>   extern foo f;
> is well-formed.
>=20
> Thus, it would be sufficient for <iostream> to include <iosfwd>.

Precisely!

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

Exactly the opposite. Issue #343 makes the inclusion explicit. The point=20
is that the problem is real and it's a source of endless embarrassment=20
in the newsgroups. I just think it's time we address the issue in one=20
way or another, that is: either making the inclusion explicitly required=20
or explicitly not required. Frankly, I agree with Howard Hinnant that=20
HelloWorld should compile with <iostream> only. However, since the=20
current standard is actually saying the opposite and several gurus and=20
non-gurus agrees on that, I believed that argument would have been=20
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.comeaucomputing.com/csc/faq.html                      ]

Alberto Ganesh Barbati wrote:
> Howard Hinnant ha scritto:
>> However, reasonable compromises to this problem have been proposed
>> over the years, and I would like to see them further explored.
>
> Could you please summarize the proposals that have already been made,
> please?
>
>> HelloWorld should only require <iostream>.  Anything else is a
>> significant usability hit to the language.
>
> 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.

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.comeaucomputing.com/csc/faq.html                      ]