On Sun,  8 Oct 2006 23:28:20 GMT, petebecker@acm.org (Pete Becker)
wrote:

>Gennaro Prota wrote:
>>
>> 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.

Are you implying that the same holds for the DR I linked to? That one
doesn't look editorial to me.

--
Gennaro Prota

---
[ 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 Mon,  9 Oct 2006 16:07:11 CST, kuyper@wizard.net wrote:
>
>> When the reason why something was not done, was that a group of
>> people couldn't agree as to how it should be done, why would you
>> expect there to be a single compelling example of why it couldn't
>> be
>> done? If it could, in fact, not be done, and if the reason why it
>> couldn't be done were known and compelling, people would, by
>> definition, have been compelled by that reason to give up on their
>> various alternative ideas about how it should be done, and would
>> have reached agreement that it couldn't be done.
>
> 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. Isn't portability the whole
> reason of having a standard? Note that the crux of the matter lies
> in
> that "is allowed to": if the inclusion were obligatory the issue
> would
> be --under this specific respect-- different: the included stuff
> would
> be part of the "contents" and the #include directive showed in the
> header synopsis.

Is this limited to <iostream>, <istream>, and <ostream>, or are you
prepared to solve the other chicken-and-egg problems in the library?
Like how <string> can use exceptions that take a std::string argument,
or how basic_ios in <ios> can have a char_traits default template
parameter, when char_traits::pos_type must be streampos defined in
<ios>.

So I get that <string> must include <stdexcept> and <ios>, which both
must include <string>. Or what?

And should <string> also include <istream> and <ostream> to be able to
define operators << and >> ?


You don't understand why the committee decided to leave this up to the
implementation?


Bo Persson


---
[ 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 Mon,  9 Oct 2006 16:07:11 CST, kuyper@wizard.net wrote:
>
> >Gennaro Prota wrote:
> >> On Mon,  9 Oct 2006 11:29:24 CST, Francis Glassborow
> >> <francis@robinton.demon.co.uk> wrote:
> >.
> >> >It was because WG21 could not come up with a generally agreed
> >> >partitioning of the library that we have the current licence.
> >>
> >> So you certainly have a compelling example which illustrates why the
> >> license is necessary, don't you?
> >
> >When the reason why something was not done, was that a group of people
> >couldn't agree as to how it should be done, why would you expect there
> >to be a single compelling example of why it couldn't be done? If it
> >could, in fact, not be done, and if the reason why it couldn't be done
> >were known and compelling, people would, by definition, have been
> >compelled by that reason to give up on their various alternative ideas
> >about how it should be done, and would have reached agreement that it
> >couldn't be done.
>
> Well, if your intent was to stun me by shots of tongue twisters... you
> succeeded :-) + O_O

Thanks - I think. :-} I know I have a tendency to use overly
complicated sentence structures. I'm trying to keep that tendency under
control.

> 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. Isn't portability the whole
> reason of having a standard? Note that the crux of the matter lies in
> that "is allowed to": if the inclusion were obligatory the issue would
> be --under this specific respect-- different: the included stuff would
> be part of the "contents" and the #include directive showed in the
> header synopsis.

I understand your point, perfectly. From Francis' comments, I gather
that many (most? all?) of the committee members would agree. However,
they could not agree on the best way of partitioning the library to
avoid this problem. If there were a compelling example that showed by
it couldn't be done, they would have reached agreement on the fact that
it couldn't be done.

---
[ 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                      ]

On Tue, 10 Oct 2006 22:43:40 GMT, bop@gmb.dk ("Bo Persson") wrote:

>Like how <string> can use exceptions that take a std::string argument,

Oops... another disaster... Perhaps the voting members had some
antipathy for const char * that day.

>[...]

I don't understand this question. Is your point that the answer is
obvious? Then I'm just stupid. After all no stupid knows that he is.
(Exiting thread with renunciation code:
EXIT_ERRORS_WHAT_ARE_THEY_POINT_MAINTAINED_BY_THE_COUNTERPART)

--
Gennaro Prota

---
[ 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:

    [...]
> 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. Isn't portability the whole reason of having a
> standard? Note that the crux of the matter lies in that "is
> allowed to": if the inclusion were obligatory the issue would
> be --under this specific respect-- different: the included
> stuff would be part of the "contents" and the #include
> directive showed in the header synopsis.

Like most things, it's a trade off.  Try to implement a version
of the standard library in which no header includes another, or
defines anything that isn't specified by the standard as being
in that header.  Once you've done that, you'll have an idea of
the cost of adding a stricter requirement.  Now, what is the
cost of the present situation with regards to portability: there
is some, because I can't deliver header files being 100% sure
that they will compile everywhere.  On the other hand, if I have
made a mistake, it's a pretty good chance that the compiler will
catch it if I move to a compiler which doesn't include what I
need.  So I add the include (which is valid for all of the other
compilers as well, obviously), and that's it.  About the only
real worry (even if the standard formally says undefined
behavior) is that the presence or absense of an include affects
the overload set in such a way that the code compiles both with
and without the header, but has different semantics.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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                      ]

On Wed, 11 Oct 2006 09:34:25 CST, "kanze" <kanze@gabi-soft.fr> wrote:

>Like most things, it's a trade off.  Try to implement a version
>of the standard library in which no header includes another, or
>defines anything that isn't specified by the standard as being
>in that header.  Once you've done that, you'll have an idea of
>the cost of adding a stricter requirement.

And once all of the participants to the discussion have done that we
can really continue speaking.

Believe it or not I have an (admittedly not so precise) idea of the
difficulties. I just think that they depend either on design errors
(coupling) or --in most cases- by the quasi-random header partitioning
(I'd say "stuffing") employed in the library. Incidentally, I made a
quick check on a library I'm just beginning; so far there are really
few facilities there and it already has 346 source files of which 68
are .hpp. Compare that with 33...

But I hear someone claiming that it would be "impratical" (whatever
that means) for a standard library to have hundred of headers; if
anyone thinks so, I'd like to hear why. FWIW, the naming convention I
adopt makes it automatic to come up with the header name once you
remember the name of the facility you want (which is what one
remembers first, isn't it? or does one start from the header name?).
Can you do the same for istreambuf_iterator?

That said, I see that the general attitude in this thread is shooting
the messenger, so I'm quitting, sorry... Looks like it's easier for a
camel to go through the eye of a needle than for WG21 to admit its
errors.

--
Gennaro Prota

---
[ 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 Tue, 10 Oct 2006 22:43:40 GMT, bop@gmb.dk ("Bo Persson") wrote:
>
>> Like how <string> can use exceptions that take a std::string
>> argument,
>
> Oops... another disaster... Perhaps the voting members had some
> antipathy for const char * that day.

No, I think the designers of std::string just wanted to use
std::string as much as possible.  :-)

>
>> [...]
>
> I don't understand this question. Is your point that the answer is
> obvious?

No, my point is that the answer is totally non-obvious. :-)

Prescribing that <iostream> should include <ostream> and/or <istream>
just solves one problem. There are lots of similar problems all
through the library.

One possible way to solve this is by compiler magic. Using #include
<something> enables all the names defined in that header. No files
used at all.

Another way is to split the declarations into a number of files
containing sub-headers, and then combine these files into the requied
standard headers. The committee couldn't agree on the One-True-Way(tm)
of doing this split, so they just said that (unlike C) a C++ header
can include any other C++ header.


Bo Persson


---
[ 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                      ]

On Oct 6, 8:50 pm, petebec...@acm.org (Pete Becker) wrote:
> Greg wrote:

> > 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."    17.4.4.1
> 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.

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?

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

Gennaro Prota wrote:
> On Wed, 11 Oct 2006 09:34:25 CST, "kanze" <kanze@gabi-soft.fr> wrote:

> >Like most things, it's a trade off.  Try to implement a version
> >of the standard library in which no header includes another, or
> >defines anything that isn't specified by the standard as being
> >in that header.  Once you've done that, you'll have an idea of
> >the cost of adding a stricter requirement.

> And once all of the participants to the discussion have done
> that we can really continue speaking.

> Believe it or not I have an (admittedly not so precise) idea
> of the difficulties. I just think that they depend either on
> design errors (coupling) or --in most cases- by the
> quasi-random header partitioning (I'd say "stuffing") employed
> in the library. Incidentally, I made a quick check on a
> library I'm just beginning; so far there are really few
> facilities there and it already has 346 source files of which
> 68 are .hpp. Compare that with 33...

But that's a different issue.  I agree that with a well designed
library, it would be fairly straightforeward, or at least, that
you could specify clearly which headers did include which
others.  (I think it more than reasonable, for example, that a
header for std::vector include whatever header defines
std::allocator.)  But we're talking about the standard library
here.  Given the current organization of the standard library, I
don't think such a requirement would be practically realizable.

(Note too that the absense of export in most compilers renders
it much more difficult too.)

> But I hear someone claiming that it would be "impratical"
> (whatever that means) for a standard library to have hundred
> of headers; if anyone thinks so, I'd like to hear why. FWIW,
> the naming convention I adopt makes it automatic to come up
> with the header name once you remember the name of the
> facility you want (which is what one remembers first, isn't
> it? or does one start from the header name?).  Can you do the
> same for istreambuf_iterator?

Logically, <istreambuf_iterator>, non?

> That said, I see that the general attitude in this thread is
> shooting the messenger, so I'm quitting, sorry... Looks like
> it's easier for a camel to go through the eye of a needle than
> for WG21 to admit its errors.

There are errors which aren't easily corrected.  I don't think
that changing the organization of the headers is doable; think
of the repercusions on existing code.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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 wrote:
> On Oct 6, 8:50 pm, petebec...@acm.org (Pete Becker) wrote:
> > Greg wrote:
> > > 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."    17.4.4.1

> > 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.

> 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.

<istream> and <ostream> don't just include definitions for the
corresponding classes.  They include declarations for a certain
number of namespace scope functions; overloads of operator<< or
operator>>, for example.  And of course, without the class
definition, the member functions are not known either.

> 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?

Because it's poor software engineering.  Arguably, good software
engineering would have cin and wcin in <istream>, and cout, et
al. in <ostream>.  But given the current breakdown, good
software engineering says to include as little as possible, to
limit the amount of unnecessary junk users pull in indirectly.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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                      ]

U   ytkownik ""Bo Persson"" <bop@gmb.dk> napisa    w wiadomo   ci
news:4p2jurFguun1U1@individual.net...
> Is this limited to <iostream>, <istream>, and <ostream>, or are you
> prepared to solve the other chicken-and-egg problems in the library? Like
> how <string> can use exceptions that take a std::string argument,

define string
include exceptions
use exceptions

> or how basic_ios in <ios> can have a char_traits default template
> parameter, when char_traits::pos_type must be streampos defined in <ios>.

The default parameter is not used until the basic_ios is instantiated so
char_traits need not be defined at the point of the template declaration.
And you can also

define streampos
include char_traits
define basic_ios

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

Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci
news:1160657114.275380.81270@h48g2000cwc.googlegroups.com...
> Gennaro Prota wrote:
>> But I hear someone claiming that it would be "impratical"
>> (whatever that means) for a standard library to have hundred
>> of headers; if anyone thinks so, I'd like to hear why. FWIW,
>> the naming convention I adopt makes it automatic to come up
>> with the header name once you remember the name of the
>> facility you want (which is what one remembers first, isn't
>> it? or does one start from the header name?).  Can you do the
>> same for istreambuf_iterator?
>
> Logically, <istreambuf_iterator>, non?

Which will reduce to <istreamb> under MS-DOS.  We are lucky if do not
generate a name clash.
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.comeaucomputing.com/csc/faq.html                      ]

Kristof Zelechovski wrote:

>
> Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci
> news:1160657114.275380.81270@h48g2000cwc.googlegroups.com...
>> Gennaro Prota wrote:
>>> But I hear someone claiming that it would be "impratical"
>>> (whatever that means) for a standard library to have hundred
>>> of headers; if anyone thinks so, I'd like to hear why. FWIW,
>>> the naming convention I adopt makes it automatic to come up
>>> with the header name once you remember the name of the
>>> facility you want (which is what one remembers first, isn't
>>> it? or does one start from the header name?).  Can you do the
>>> same for istreambuf_iterator?
>>
>> Logically, <istreambuf_iterator>, non?
>
> Which will reduce to <istreamb> under MS-DOS.  We are lucky if do not
> generate a name clash.

It is up to the compiler to decide how to map header names to filenames (or
if, indeed, it even maps to a file at all).  There is no reason why the
compiler couldn't recognize <istreambuf_iterator> and map it to a file
named istrea~1 or some other style.

Ian McCulloch

---
[ 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                      ]

"Kristof Zelechovski" wrote:
> Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci
> news:1160657114.275380.81270@h48g2000cwc.googlegroups.com...
> > Gennaro Prota wrote:
> >> But I hear someone claiming that it would be "impratical"
> >> (whatever that means) for a standard library to have hundred
> >> of headers; if anyone thinks so, I'd like to hear why. FWIW,
> >> the naming convention I adopt makes it automatic to come up
> >> with the header name once you remember the name of the
> >> facility you want (which is what one remembers first, isn't
> >> it? or does one start from the header name?).  Can you do the
> >> same for istreambuf_iterator?

> > Logically, <istreambuf_iterator>, non?
>
> Which will reduce to <istreamb> under MS-DOS.  We are lucky if
> do not generate a name clash.

Nonsense.  It will map to whatever the implementation decides it
will map to.  The implementations of NFS I'm familiar with,
faced with long names, mapped them to something along the lines
of istrea??, where the last two characters were generated from
some sort of hashing of the rest of the name.

Of course, any time there is a mapping, there is a risk of
collision.  If I have a header file named IStream, it will
clash when I move to Windows, because the mapping there is
different than under Unix.  That's one of the realities of
"portable" programming.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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                      ]

K=F8i=B9tof =AEelechovski wrote:
> U=BFytkownik ""Bo Persson"" <bop@gmb.dk> napisa=B3 w wiadomo=B6ci
> news:4p2jurFguun1U1@individual.net...
>> Is this limited to <iostream>, <istream>, and <ostream>, or are you
>> prepared to solve the other chicken-and-egg problems in the=20
>> library?
>> Like how <string> can use exceptions that take a std::string
>> argument,
>
> define string
> include exceptions
> use exceptions

But what about <stdexcept> that defines the exceptions, that depends=20
on std::string?

>
>> or how basic_ios in <ios> can have a char_traits default template
>> parameter, when char_traits::pos_type must be streampos defined in
>> <ios>.
>
> The default parameter is not used until the basic_ios is=20
> instantiated
> so char_traits need not be defined at the point of the template
> declaration. And you can also
>
> define streampos
> include char_traits
> define basic_ios

You are just showing the problem.  :-)

The class char_traits is defined in <string>, while streampos and=20
basic_ios are defined in <ios>. Then <ios> is required by <istream>=20
and <ostream>, that are required to define the << and >> operators in=20
<string>.

How did you get char_traits in between streampos and basic_ios? In=20
what header?


Bo Persson


---
[ 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                      ]

Oops, MSOE failed to quote, must top-post, sorry!

The solution is to tag severable features with different macrodefinitions
and use the macrodefinitions consistently to guard against ODR violations=
=20
and infinite recursion.
Consider the following schema:

<stdexcept>

#ifndef _STL_STRING_DECLARED    // prevent infinite recursion
#include<string>
#endif

#ifndef _STL_EXCEPTIONS_DEFINED
#define _STL_EXCEPTIONS_DEFINED
define exceptions (uses string)
#endif

</stdexcept>

<string>

#ifndef _STL_STRING_DECLARED
#define _STL_STRING_DECLARED
declare string
#endif

#ifndef _STL_STRING_DEFINED
#define _STL_STRING_DEFINED
define string (uses exceptions)
#endif

</string>

Scenario 1: preprocessor flow for #include <string>:
(string: declare string; (stdexcept: avoid recursion; define exceptions);=
=20
define string)

Scenario 2: preprocessor flow for #include <stdexcept>:
(stdexcept: (string: declare string; (stdexcept: avoid recursion; define=20
exceptions); define string); observe ODR)

That is it.

I admit this schema does not allow #pragma once
but it goes to the precompiled header anyway so I would not bother about=20
that.

I bet the same approach can be used to solve the <ios> problem.

Chris

U=BFytkownik ""Bo Persson"" <bop@gmb.dk> napisa=B3 w wiadomo=B6ci=20
news:4p9tjiFhk1ttU1@individual.net...
K=F8i=B9tof =AEelechovski wrote:
> U=BFytkownik ""Bo Persson"" <bop@gmb.dk> napisa=B3 w wiadomo=B6ci
> news:4p2jurFguun1U1@individual.net...
>> Is this limited to <iostream>, <istream>, and <ostream>, or are you
>> prepared to solve the other chicken-and-egg problems in the library?
>> Like how <string> can use exceptions that take a std::string
>> argument,
>
> define string
> include exceptions
> use exceptions

But what about <stdexcept> that defines the exceptions, that depends
on std::string?

>
>> or how basic_ios in <ios> can have a char_traits default template
>> parameter, when char_traits::pos_type must be streampos defined in
>> <ios>.
>
> The default parameter is not used until the basic_ios is instantiated
> so char_traits need not be defined at the point of the template
> declaration. And you can also
>
> define streampos
> include char_traits
> define basic_ios

You are just showing the problem.  :-)

The class char_traits is defined in <string>, while streampos and
basic_ios are defined in <ios>. Then <ios> is required by <istream>
and <ostream>, that are required to define the << and >> operators in
<string>.

How did you get char_traits in between streampos and basic_ios? In
what header?


Bo Persson


---
[ 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                      ]


---
[ 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                      ]

Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci
news:1160725777.885273.192940@f16g2000cwb.googlegroups.com...
> "Kristof Zelechovski" wrote:
>> Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci
>> news:1160657114.275380.81270@h48g2000cwc.googlegroups.com...
>> > Gennaro Prota wrote:
>> >> But I hear someone claiming that it would be "impratical"
>> >> (whatever that means) for a standard library to have hundred
>> >> of headers; if anyone thinks so, I'd like to hear why. FWIW,
>> >> the naming convention I adopt makes it automatic to come up
>> >> with the header name once you remember the name of the
>> >> facility you want (which is what one remembers first, isn't
>> >> it? or does one start from the header name?).  Can you do the
>> >> same for istreambuf_iterator?
>
>> > Logically, <istreambuf_iterator>, non?
>>
>> Which will reduce to <istreamb> under MS-DOS.  We are lucky if
>> do not generate a name clash.

The MS-DOS C++ compilers I am familiar with do just that.
And so does fopen, for that matter.
Chris

>
> Nonsense.  It will map to whatever the implementation decides it
> will map to.  The implementations of NFS I'm familiar with,
> faced with long names, mapped them to something along the lines
> of istrea??, where the last two characters were generated from
> some sort of hashing of the rest of the name.
>


---
[ 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                      ]

"Bo Persson" wrote:
[...]
> Like how <string> can use exceptions that take a std::string argument,
> or how basic_ios in <ios> can have a char_traits default template
> parameter, when char_traits::pos_type must be streampos defined in
> <ios>.
>
> So I get that <string> must include <stdexcept> and <ios>, which both
> must include <string>. Or what?

FWIW, <string> need not #include <stdexcept> (in fact, no header
needs to #include it) in order to throw the required exceptions.
Apache stdcxx doesn't. And <stdexcept> doesn't need to #include
<string> or any other header that defines std::string. All it really
needs is a declaration of the specialization of the template.

---
[ 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:

> 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.

I think the shoe is on the other foot.  It's pretty rare to
write a non-trivial program in which the decision about where
output goes to or input comes from is in the same translation
unit as the code actually doing the IO.  They are two logically
separate operations.

> 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 ;-)

In my real world applications, there's generally only one or two
modules which include <iostream>, and they generally don't do
any IO (except indirectly, via calls to the logging system).

(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.)

--
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                      ]

Howard Hinnant wrote:
> In article <afKdnVYqV_NjvbjYnZ2dnUVZ_oadnZ2d@giganews.com>,
>  petebecker@acm.org (Pete Becker) wrote:

> > Alberto Ganesh Barbati wrote:

> > > 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.

Fixing the examples to conform with the normative parts of the
standard would seem just editorial to me.  That there are
additional, non-editorial issues that we might want to consider
is another question.

> Just glancing at 14.6p8, I disagree that <ostream> is required
> (and I doubt it is required in any existing implementation).

It's rather clear (and I believe intentional) that <iostream>
isn't required to declare any << operators.  At least as the
standard reads today.  It's also clear from text in chapter 17
that it may include other headers, which do define such
operators, so an implementation is not non-conforming if it
happens to do so.  (I rather think that this is a mistake in the
C++ standard; it would have been far better to adopt the C
rules, where what you get in a standard header is exactly what
the standard says you get, no more, no less.  On the other hand,
I can understand that this creates some very definite, and
probably unsolvable, problems for implementing the standard
library.)

> 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.

I think there is a valid argument that the standard should
recognize existing practice, even if I don't particularly care
for that practice.

> 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, and that I've been using a slightly
modified version of the g++ library for some time now, that
doesn't include <istream> and <ostream> in <iostream>, and that
it hasn't really changed anything in my code: the modules which
do actual IO are not the modules that reference cin or cout.

>From the point of view of teaching the language, of course,
needing any include to do IO has an effect.  As does requiring
a function, main, in which to put the code.  In the early
presentations, you have to accept the fact that there will be
some "magic" as far as the students are concerned; I'm not
convinced that requiring two magic lines, instead of one, before
some magic declarations with the word main in them, makes a big
difference.

--
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                      ]

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. [Here's a random example by
unknown authors:

  <http://google.com/group/comp.std.c++/msg/8f400916af7afd4a>

]


>(I rather think that this is a mistake in the
>C++ standard; it would have been far better to adopt the C
>rules, where what you get in a standard header is exactly what
>the standard says you get, no more, no less.  On the other hand,
>I can understand that this creates some very definite, and
>probably unsolvable, problems for implementing the standard
>library.)

Could you provide an example?

>> [...]
>
>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, and that I've been using a slightly
>modified version of the g++ library for some time now, that
>doesn't include <istream> and <ostream> in <iostream>,

You mean a version modified by your customer? (Curious about the
rationale for the modification :-))

>and that
>it hasn't really changed anything in my code: the modules which
>do actual IO are not the modules that reference cin or cout.
>
>>From the point of view of teaching the language, of course,
>needing any include to do IO has an effect.  As does requiring
>a function, main, in which to put the code.  In the early
>presentations, you have to accept the fact that there will be
>some "magic" as far as the students are concerned; I'm not
>convinced that requiring two magic lines, instead of one, before
>some magic declarations with the word main in them, makes a big
>difference.

If I were in the audience however I would be struck; and would eagerly
wait to understand the question; when time would come for exposition
of the relevant headers' contents I would certainly be disappointed.
At best <iostream> is one of the worst names that could be chosen (the
fact that an <iostream.h> header existed eariler is not a
justification, quite the contrary).

--
Gennaro Prota

---
[ 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                      ]

On Sun,  8 Oct 2006 10:34:08 CST, "James Kanze" <kanze.james@neuf.fr>
wrote:

>(Note that I'm not against adding a lot of extra junk to
><iostream>, given that 1) it's what most implementations do
>anyway

In this specific case I think this is not a good motivation though: it
follows from the freedom for C++ standard headers to include other C++
headers, which I (sorry for restating) consider an error. I suspect
the general perception of the problem would be different if <iostream>
were named for instance <predefined_streams> (the current name is
general enough that one mentally associates it with "I want to do some
input/output with streams", which isn't the case: it just refers to
the declaration of 8 specific stream objects).

(Not particularly relevant to this thread but... isn't the wording in
27.3/1: "The header <iostream> declares objects that associate
objects" a bit odd?)

--
Gennaro Prota

---
[ 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   user wrote:
> 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>.

FWIW: I modified the g++ implementation to do just that.  It
required changing only two or three lines, and works fine.

So in addition to the theoretical arguments, there is a proof of
concept.

--
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                      ]

In article <9ubki29e8m169974e02n0d7s1bnnqa98el@4ax.com>, Gennaro Prota
<gennaro_prota@yahoo.com> writes
>In this specific case I think this is not a good motivation though: it
>follows from the freedom for C++ standard headers to include other C++
>headers, which I (sorry for restating) consider an error.

You are entitled to hold that opinion but the corollary is that you
present a scheme whereby such is not necessary. In doing so you need to
take into account all reasonable implementation strategies.

It was because WG21 could not come up with a generally agreed
partitioning of the library that we have the current licence.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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                      ]

On Mon,  9 Oct 2006 11:29:24 CST, Francis Glassborow
<francis@robinton.demon.co.uk> wrote:

>In article <9ubki29e8m169974e02n0d7s1bnnqa98el@4ax.com>, Gennaro Prota
><gennaro_prota@yahoo.com> writes
>>In this specific case I think this is not a good motivation though: it
>>follows from the freedom for C++ standard headers to include other C++
>>headers, which I (sorry for restating) consider an error.
>
>You are entitled to hold that opinion but the corollary is that you
>present a scheme whereby such is not necessary. In doing so you need to
>take into account all reasonable implementation strategies.
>
>It was because WG21 could not come up with a generally agreed
>partitioning of the library that we have the current licence.

So you certainly have a compelling example which illustrates why the
license is necessary, don't you?

--
Gennaro Prota

---
[ 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:

    [...]
> >Fixing the examples to conform with the normative parts of the
> >standard would seem just editorial to me.
> >(I rather think that this is a mistake in the
> >C++ standard; it would have been far better to adopt the C
> >rules, where what you get in a standard header is exactly what
> >the standard says you get, no more, no less.  On the other hand,
> >I can understand that this creates some very definite, and
> >probably unsolvable, problems for implementing the standard
> >library.)

> Could you provide an example?

Well, consider the header in question here, <iostream>.
According to the standard, it provides a declaration for 8
symbols: cin, cout, cerr, clog, wcin, wcout, wcerr, and wclog.
And while its relatively easy to implement it so that it doesn't
define istream et al., implementing it in such a way that it
doesn't declare them would require compiler magic.

Even if we accept that the necessary types may be (must be)
declared here, what about something like vector.  The required
complexity of the templated constructor depends on the iterator
type, which in turn requires iterator_traits, and thus,
<iterator>. Presumably, it would be possible for the
implementation to provide a separate _M_iterator_traits class,
an exact copy of iterator_traits, but as a private member.  But
in practice, I don't think anyone wants to force an implementor
to have to maintain many different copies of the same thing.

> >> [...]

> >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, and that I've been using a slightly
> >modified version of the g++ library for some time now, that
> >doesn't include <istream> and <ostream> in <iostream>,

> You mean a version modified by your customer? (Curious about
> the rationale for the modification :-))

A version modified by me.  It's not the version we use in
production (it's based on 4.1.0, and in production, we are still
at 3.4.1), but it's interesting to pass our production code
through it.

Of course, one of the reasons it might not cause problems is
that we only moved from the classical io streams to the standard
ones about two years ago.  I was already here, and they asked me
what would be necessary.

Another reason, of course, might be because the application is a
server, which is started as a demon, and whose std::cerr (and
the others) is connected to /dev/null.  Which means that there
aren't many references to std::cerr et al. in the code to begin
with:-).

However, the same experience holds for the numberous little
helper programs that get written, which for the most part
conform to the Unix filter pattern.  But std::cout and std::cin
are only referenced in main() here, and main() calls other
functions, in other compilation units for the most part, with
the istream& and ostream& depending on the command line.

> >and that it hasn't really changed anything in my code: the
> >modules which do actual IO are not the modules that reference
> >cin or cout.

> >>From the point of view of teaching the language, of course,
> >needing any include to do IO has an effect.  As does requiring
> >a function, main, in which to put the code.  In the early
> >presentations, you have to accept the fact that there will be
> >some "magic" as far as the students are concerned; I'm not
> >convinced that requiring two magic lines, instead of one, before
> >some magic declarations with the word main in them, makes a big
> >difference.

> If I were in the audience however I would be struck;

If I were in the audience, I'd be struck by the fact that I
needed some very strange syntax, period.  Why, for example, must
the first non-blank in the line be a #, which cannot be used
elsewhere?

> and would eagerly wait to understand the question; when time
> would come for exposition of the relevant headers' contents I
> would certainly be disappointed.

Why?  My gut fealing is the opposite: on one hand, I have a
header declaring types, and on the other, one declaring objects.

> At best <iostream> is one of the worst names that could be
> chosen (the fact that an <iostream.h> header existed eariler
> is not a justification, quite the contrary).

The fact that it is not compatible with the earlier <iostream>,
in any way, certainly makes the choice of names a poor one.  The
fact that most of the time, you are dealing with functions with
the same name as in the old one, but with slightly different
semantics (except where streambuf is involved, in which case,
you have the same semantics, but different names) certainly
doesn't make things any nicer.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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                      ]

On Mon,  9 Oct 2006 11:38:33 CST, "kanze" <kanze@gabi-soft.fr> wrote:

>Even if we accept that the necessary types may be (must be)
>declared here, what about something like vector.  The required
>complexity of the templated constructor depends on the iterator
>type, which in turn requires iterator_traits,

Yes.

>and thus, <iterator>.

Why? It doesn't require *all* of <iterator> (no need e.g. for
reverse_iterator<>), so the needed part could be factored out. If you
ask me part of the problem is exactly that many headers, such as
<iterator>, are monolitic aggregates of stuff where partitioning seems
more "terminological" than logical. To me reverse_iterator should
already be in a separate standard header.

> [...]
>
>> and would eagerly wait to understand the question; when time
>> would come for exposition of the relevant headers' contents I
>> would certainly be disappointed.
>
>Why?

Because of the names.

>My gut fealing is the opposite: on one hand, I have a
>header declaring types, and on the other, one declaring objects.

Yes, as long as the header-names made that clear (if they did, I'd
probably infer the reason before the contents got actually exposed;
all that one would need for that is a basic familiarity with the
possibility to define UDTs and the difference between a type and an
instance of a type)

--
Gennaro Prota

---
[ 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 Mon,  9 Oct 2006 11:29:24 CST, Francis Glassborow
> <francis@robinton.demon.co.uk> wrote:
.
> >It was because WG21 could not come up with a generally agreed
> >partitioning of the library that we have the current licence.
>
> So you certainly have a compelling example which illustrates why the
> license is necessary, don't you?

When the reason why something was not done, was that a group of people
couldn't agree as to how it should be done, why would you expect there
to be a single compelling example of why it couldn't be done? If it
could, in fact, not be done, and if the reason why it couldn't be done
were known and compelling, people would, by definition, have been
compelled by that reason to give up on their various alternative ideas
about how it should be done, and would have reached agreement that it
couldn't be done.

---
[ 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                      ]

On Mon,  9 Oct 2006 16:07:11 CST, kuyper@wizard.net wrote:

>Gennaro Prota wrote:
>> On Mon,  9 Oct 2006 11:29:24 CST, Francis Glassborow
>> <francis@robinton.demon.co.uk> wrote:
>.
>> >It was because WG21 could not come up with a generally agreed
>> >partitioning of the library that we have the current licence.
>>
>> So you certainly have a compelling example which illustrates why the
>> license is necessary, don't you?
>
>When the reason why something was not done, was that a group of people
>couldn't agree as to how it should be done, why would you expect there
>to be a single compelling example of why it couldn't be done? If it
>could, in fact, not be done, and if the reason why it couldn't be done
>were known and compelling, people would, by definition, have been
>compelled by that reason to give up on their various alternative ideas
>about how it should be done, and would have reached agreement that it
>couldn't be done.

Well, if your intent was to stun me by shots of tongue twisters... you
succeeded :-) + O_O

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. Isn't portability the whole
reason of having a standard? Note that the crux of the matter lies in
that "is allowed to": if the inclusion were obligatory the issue would
be --under this specific respect-- different: the included stuff would
be part of the "contents" and the #include directive showed in the
header synopsis.

--
Gennaro Prota

---
[ 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                      ]

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.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?
>

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

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

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

On Fri,  6 Oct 2006 14:33:28 GMT, howard.hinnant@gmail.com (Howard
Hinnant) wrote:

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

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".

--
Gennaro Prota

---
[ 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                      ]

On Sat,  7 Oct 2006 03:51:33 GMT, AlbertoBarbati@libero.it (Alberto
Ganesh Barbati) wrote:

>[...] 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.

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*) predominant 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 ;-))

>
>Just my 2 eurocent,
>
>Ganesh
>
>PS: what about <fstream> and <sstream>? Should we treat them the same way?

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

--
Gennaro Prota

---
[ 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                      ]

Pete Becker wrote:
> Greg wrote:

> > 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.

> 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.

And, of course, there is no requirement that such a header even
exist as a separate file, much less that it be "well-formed".
An implementation could simply recognize the standard include,
and turn on pre-created entries in its symbol table, for
example.  I'm not convinced that <iostream> requires even a
declaration of std::basic_istream, much less a definition (and
it certainly doesn't require a typedef for istream).

> 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>.

I don't think you have to go this far.  Just include <iosfwd> in
<iostream>, and you're fully compliant.

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

That would take some fancy #ifdef'ing, in order to avoid
multiple definitions in the same translation unit when you
included both <iostream> and <istream>.  But nothing really
impossible, and there's considerable precedant---the C standard
practically requires such in some of their 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."    17.4.4.1

> This is a footnote. Footnotes are not normative.

And I don't see how it applies here anyway, since there are no
definitions needed to declare an external object, regardless of
its type.  (Well, as long as the type isn't nested, at least.)

--
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                      ]