C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Need for #include <ios> Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Ray Lischner Guest Posted: Sat Aug 05, 2006 9:10 am    Post subject: Need for #include <ios> We all assume that <istream>, <ostream>, <fstream>, and <sstream> have #include <ios>, but I don't see that as a requirement of the standard. Real implementations of these headers as text files containing source code necessarily need to #include <ios> to obtain the base class definitions, but suppose we have a hypothetical library implementation that defines basic_istream, say, as "__builtin class basic_istream;" and all knowledge of basic_istream is built into the compiler. In that case, #include <istream> gets basic_istream, et al., but not ios, ios_base, et al. Perhaps this is an area where the standard should reflect practice, and simply state that <istream>, etc., #include <ios>. Or does it, and I missed it? Or am I being paranoid about libraries that don't and never will exist? -- Ray Lischner, author of C++ in a Nutshell http://www.tempest-sw.com/cpp [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Bo Persson Guest Posted: Sun Aug 06, 2006 12:04 am    Post subject: Re: Need for #include <ios> "Ray Lischner" <rl.news@tempest-sw.com> skrev i meddelandet news:2910872.KNvIDnCgA0@tempest-sw.com... Quote: We all assume that <istream>, <ostream>, <fstream>, and <sstream have #include <ios>, but I don't see that as a requirement of the standard. No, there is none. Unlike C, where it is forbidden, in C++ the standard allows one header to include another. It doesn't go into any more details. Quote: Real implementations of these headers as text files containing source code necessarily need to #include <ios> to obtain the base class definitions, but suppose we have a hypothetical library implementation that defines basic_istream, say, as "__builtin class basic_istream;" and all knowledge of basic_istream is built into the compiler. In that case, #include <istream> gets basic_istream, et al., but not ios, ios_base, et al. The standard says in a non-normative footnote (#170) that a header must include the defintions it needs. It doesn't say how. As a footnote, it also just shows the intention of the committee, and is not formally binding. As a programmer, it is a good idea to follow this rule anyway. Just include the headers containing the definitions you need, and it will always work. Sometimes it will work anyway, by chance. If you use any ios:: or ios_base:: names, just add #include <ios> at the top of your file. Not too much work, really! :-) Quote: Perhaps this is an area where the standard should reflect practice, and simply state that <istream>, etc., #include <ios>. Or does it, and I missed it? Or am I being paranoid about libraries that don't and never will exist? The standard doesn't specify exactly how the header files are composed (or whether they are files at all). We know that it is impossible to have exactly the headers specified in the standard, as files. Because of circular dependencies, an implementation must break it down in smaller pieces, and compose the required headers from those. For example, std::string throws out_of_range exceptions, who's constructor takes a string parameter. This might require the <string> header to include <stdexcept>, and <stdexcept> to include <string>. Not too good! The Standard leaves it up to the implementation to solve minor things like this! Bo Persson [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Greg Herlihy Guest Posted: Sun Aug 06, 2006 4:36 am    Post subject: Re: Need for #include <ios> Ray Lischner wrote: Quote: We all assume that <istream>, <ostream>, <fstream>, and <sstream> have #include <ios>, but I don't see that as a requirement of the standard. "C++ headers must include a C++ header that contains any needed definition (3.2)." [§17.4.4.1]. The definition of a base class is clealy a definition needed by any derived class. Therefore <istream> has to include <ios>. Quote: Real implementations of these headers as text files containing source code necessarily need to #include <ios> to obtain the base class definitions, but suppose we have a hypothetical library implementation that defines basic_istream, say, as "__builtin class basic_istream;" and all knowledge of basic_istream is built into the compiler. In that case, #include <istream> gets basic_istream, et al., but not ios, ios_base, et al. Eidther <ios> contains a definition that <istream> needs - or it does not. If it does, then <istream> will include <ios> - otherwise it may not. The bottom line is that it should never be necessary to include <ios> in order to include <istream>. Greg [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Greg Herlihy Guest Posted: Sun Aug 06, 2006 4:37 am    Post subject: Re: Need for #include <ios> Bo Persson wrote: Quote: "Ray Lischner" <rl.news@tempest-sw.com> skrev i meddelandet news:2910872.KNvIDnCgA0@tempest-sw.com... Real implementations of these headers as text files containing source code necessarily need to #include <ios> to obtain the base class definitions, but suppose we have a hypothetical library implementation that defines basic_istream, say, as "__builtin class basic_istream;" and all knowledge of basic_istream is built into the compiler. In that case, #include <istream> gets basic_istream, et al., but not ios, ios_base, et al. The standard says in a non-normative footnote (#170) that a header must include the defintions it needs. It doesn't say how. As a footnote, it also just shows the intention of the committee, and is not formally binding. Footnote #170 is normative. Only those paragraphs that being with "Example:' or "Note:" are non-normative and 17.4.4.1 contains neither. Besides, what sense would it make to use the word "must" in non-normative text? I would recommend posting followups to comp.std.c++. Greg [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Pete Becker Guest Posted: Mon Aug 07, 2006 2:44 am    Post subject: Re: Need for #include <ios> Greg Herlihy wrote: Quote: Footnote #170 is normative. Only those paragraphs that being with "Example:' or "Note:" are non-normative and 17.4.4.1 contains neither. Besides, what sense would it make to use the word "must" in non-normative text? Under ISO rules, footnotes are not normative. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Pete Becker Guest Posted: Mon Aug 07, 2006 2:46 am    Post subject: Re: Need for #include <ios> Greg Herlihy wrote: Quote: Ray Lischner wrote: We all assume that <istream>, <ostream>, <fstream>, and <sstream> have #include <ios>, but I don't see that as a requirement of the standard. "C++ headers must include a C++ header that contains any needed definition (3.2)." [§17.4.4.1]. That's in a footnote, not in the running text. Footnotes are not normative. Quote: The definition of a base class is clealy a definition needed by any derived class. Therefore <istream has to include <ios>. <ios> is not required to contain the definitions of the base classes. The requirement is that #include <ios> provides the definitions. It can do that by pulling in another header which has the actual definitions, and the statement that C++ headers must include a header that contains any needed definition is satisfied by pulling in that auxiliary header wherever it's needed. Anything in <ios> that isn't needed in <istream>, etc. doesn't have to be supplied by <istream>, etc. If your code uses names provided by <ios> you should #include <ios>. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ray Lischner Guest Posted: Mon Aug 07, 2006 2:46 am    Post subject: Re: Need for #include <ios> On Saturday 05 August 2006 07:36 pm, Greg Herlihy wrote: Quote: Eidther <ios> contains a definition that <istream> needs - or it does not. If it does, then <istream> will include <ios> - otherwise it may not. The bottom line is that it should never be necessary to include ios> in order to include <istream>. Let me rephrase my question in more concrete terms. Every real compiler/library that I know of can compile the following program without any problems, but I can imagine a compiler/library that would complain about std::hex being undefined because the program does not include <ios> explicitly. So is the program correct or not? #include <iostream> #include <ostream> int main() { std::cout << std::hex << 42 << '\n'; } -- Ray Lischner, author of C++ in a Nutshell http://www.tempest-sw.com/cpp [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Seungbeom Kim Guest Posted: Mon Aug 07, 2006 5:50 am    Post subject: Re: Need for #include <ios> Ray Lischner wrote: Quote: We all assume that <istream>, <ostream>, <fstream>, and <sstream> have #include <ios>, but I don't see that as a requirement of the standard. Real implementations of these headers as text files containing source code necessarily need to #include <ios> to obtain the base class definitions, but suppose we have a hypothetical library implementation that defines basic_istream, say, as "__builtin class basic_istream;" and all knowledge of basic_istream is built into the compiler. In that case, #include <istream> gets basic_istream, et al., but not ios, ios_base, et al. Perhaps this is an area where the standard should reflect practice, and simply state that <istream>, etc., #include <ios>. Or does it, and I missed it? Or am I being paranoid about libraries that don't and never will exist? I agree that there are so many headers that programmers have to take care of, even in simplest programs. For example, every program that interacts with the user through stdin/stdout should include <istream>, <ostream>, and <iostream>. Compare this to the simple <stdio.h> in C. (There are 9 C++ headers introduced in Clause 27, plus 3 from C.) How iostreams are implemented is not what every programmer should be aware of, and neither is all the "intermediate" headers. It would make lives of many, many programmers much easier if they had to take care of a few "major" iostream headers, such as: * <iostream> for everything needed to use std::cin, std::cout, etc., * <sstream> for everything needed to use string streams, * <fstream> for everything needed to use file streams. Those who want to derive from "intermediate" classes can include <ios> or <streambuf> or whatever and get only what they want. Others shouldn't be bothered with all the details, IMHO. -- Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ray Lischner Guest Posted: Mon Aug 07, 2006 8:25 am    Post subject: Re: Need for #include <ios> On Sunday 06 August 2006 08:50 pm, Seungbeom Kim wrote: Quote: Those who want to derive from "intermediate" classes can include <ios or <streambuf> or whatever and get only what they want. Others shouldn't be bothered with all the details, IMHO. My concern is not actually with deriving from ios_base, but making use of the various entities that <ios> declares, such as the formatting flag manipulators. Many, many C++ programs use these manipulators and whatnot without explicitly including <ios>. They successfully compile because <istream> and <ostream> happen to include <ios>, but I think we're being sloppy by omitting the explicit inclusion of <ios>. -- Ray Lischner, author of C++ in a Nutshell http://www.tempest-sw.com/cpp [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Bo Persson Guest Posted: Tue Aug 08, 2006 12:32 am    Post subject: Re: Need for #include <ios> "Seungbeom Kim" <musiphil (AT) bawi (DOT) org> skrev i meddelandet news:eb6mrh$jth$1 (AT) news (DOT) Stanford.EDU... Quote: Ray Lischner wrote: On Sunday 06 August 2006 08:50 pm, Seungbeom Kim wrote: Those who want to derive from "intermediate" classes can include ios or <streambuf> or whatever and get only what they want. Others shouldn't be bothered with all the details, IMHO. My concern is not actually with deriving from ios_base, but making use of the various entities that <ios> declares, such as the formatting flag manipulators. Many, many C++ programs use these manipulators and whatnot without explicitly including <ios>. They successfully compile because <istream> and <ostream> happen to include <ios>, but I think we're being sloppy by omitting the explicit inclusion of <ios>. Yes, that's also a valid concern. Derivation was just an example. Formally, those programs that use formatting flags and manipulators should include <ios>, usually in addition to <{i,o,io}stream>. This is too much clutter, and should be improved. If you think this is too much trouble, you could easily create an ioeverything.h header, and include that in all your programs. Why should the standard care to specify it? Bo Persson [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Seungbeom Kim Guest Posted: Tue Aug 08, 2006 3:39 pm    Post subject: Re: Need for #include <ios> Bo Persson wrote: Quote: "Seungbeom Kim" <musiphil (AT) bawi (DOT) org> skrev i meddelandet news:eb6mrh$jth$1 (AT) news (DOT) Stanford.EDU... Formally, those programs that use formatting flags and manipulators should include <ios>, usually in addition to <{i,o,io}stream>. This is too much clutter, and should be improved. If you think this is too much trouble, you could easily create an ioeverything.h header, and include that in all your programs. Why should the standard care to specify it? I could do it myself, but if I do it, others will have to learn what it means, because it's non-standard and not a common knowledge. Moreover, many others would want to do similar things, each would have to invent his/her own wheels, and the readers would have to learn each of them. If you say "You could create one; why should the standard bother?", should each of us write his/her own String class, or his/her own Bool type? The reason is the same: to avoid repeating the same thing (writing each one's own and others' learning it) and to make lives of many (especially beginners) easier. (Of course, there's no inter- operability issues here as in the String class or the Bool type. ) In addition, in this particular case, there's the discrepancy between the rules and the practice, as Ray mentioned: many people expect #include <iostream> int main() { std::cout << "Hello, world!\n"; } to work, as well as #include <ostream> // with, or even without... #include <iostream> int main() { std::cout << std::hex << 42 << '\n'; } to work, but the standard doesn't guarantee this, which is a surprise factor. Then what's your argument *against* the standard's correcting this? -- Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Bo Persson Guest Posted: Tue Aug 08, 2006 11:02 pm    Post subject: Re: Need for #include <ios> "Seungbeom Kim" <musiphil (AT) bawi (DOT) org> skrev i meddelandet news:eb87c9$4us$1 (AT) news (DOT) Stanford.EDU... Quote: Bo Persson wrote: "Seungbeom Kim" <musiphil (AT) bawi (DOT) org> skrev i meddelandet news:eb6mrh$jth$1 (AT) news (DOT) Stanford.EDU... Formally, those programs that use formatting flags and manipulators should include <ios>, usually in addition to <{i,o,io}stream>. This is too much clutter, and should be improved. If you think this is too much trouble, you could easily create an ioeverything.h header, and include that in all your programs. Why should the standard care to specify it? I could do it myself, but if I do it, others will have to learn what it means, because it's non-standard and not a common knowledge. Moreover, many others would want to do similar things, each would have to invent his/her own wheels, and the readers would have to learn each of them. If you say "You could create one; why should the standard bother?", should each of us write his/her own String class, or his/her own Bool type? The reason is the same: to avoid repeating the same thing (writing each one's own and others' learning it) and to make lives of many (especially beginners) easier. (Of course, there's no inter- operability issues here as in the String class or the Bool type. ) In addition, in this particular case, there's the discrepancy between the rules and the practice, as Ray mentioned: many people expect #include <iostream int main() { std::cout << "Hello, world!\n"; } to work, as well as #include <ostream> // with, or even without... #include <iostream int main() { std::cout << std::hex << 42 << '\n'; } to work, but the standard doesn't guarantee this, which is a surprise factor. Then what's your argument *against* the standard's correcting this? The standards committee has done an effort to put different classes in different headers, to get some structure into the library. You don't have to include the entire io-library, just to write WriteReportTo(std::cout); If you want to simplify for beginners, why not put everything in a single header, so we could get away with #include <std> Would be much easier to remember. :-) Bo Persson [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Seungbeom Kim Guest Posted: Wed Aug 09, 2006 7:00 am    Post subject: Re: Need for #include <ios> Bo Persson wrote: Quote: "Seungbeom Kim" <musiphil (AT) bawi (DOT) org> skrev i meddelandet news:eb87c9$4us$1 (AT) news (DOT) Stanford.EDU... Then what's your argument *against* the standard's correcting this? The standards committee has done an effort to put different classes in different headers, to get some structure into the library. You don't have to include the entire io-library, just to write WriteReportTo(std::cout); If you want to simplify for beginners, why not put everything in a single header, so we could get away with #include <std Would be much easier to remember. I agree to the general principle that different things should be put into different headers so that only those needed can be included. I'm not suggesting anything as radical as a single header <std> that includes everything; it's a matter of granularity. I understand your point, but on the other hand, it has never been a concern for me to include the entire <stdio.h> just to mention stdout. We know that we cannot separate everything into different headers. That being said, the issue is how many programs that need <iostream> also (formally) need <istream> and/or <ostream>, etc. I cannot give you statistics for this. Maybe we should invent a new header that includes <ios>, <istream>, <ostream> and <iostream>? By the way, I don't see why the header that does nothing but containing 8 extern declarations is named <iostream>, when the entire C++ I/O library is commonly called iostream library (compared to stdio from C)... -- Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top James Kanze Guest Posted: Tue Aug 15, 2006 8:56 pm    Post subject: Re: Need for #include <ios> Bo Persson wrote: Quote: "Seungbeom Kim" <musiphil (AT) bawi (DOT) org> skrev i meddelandet news:eb6mrh$jth$1 (AT) news (DOT) Stanford.EDU... Ray Lischner wrote: On Sunday 06 August 2006 08:50 pm, Seungbeom Kim wrote: Those who want to derive from "intermediate" classes can include <ios> or <streambuf> or whatever and get only what they want. Others shouldn't be bothered with all the details, IMHO. My concern is not actually with deriving from ios_base, but making use of the various entities that <ios> declares, such as the formatting flag manipulators. Many, many C++ programs use these manipulators and whatnot without explicitly including <ios>. They successfully compile because <istream and <ostream> happen to include <ios>, but I think we're being sloppy by omitting the explicit inclusion of <ios>. Yes, that's also a valid concern. Derivation was just an example. Formally, those programs that use formatting flags and manipulators should include <ios>, usually in addition to {i,o,io}stream>. This is too much clutter, and should be improved. If you think this is too much trouble, you could easily create an ioeverything.h header, and include that in all your programs. Why should the standard care to specify it? To conform with existing practice. Personally, I rather liked the idea that each header only included a minimum, and that you only included the headers you absolutely needed. But there are good arguments both ways, and existing practice is pretty much that <iostream> includes everything except <fstream> and <sstream> (and maybe <streambuf>). What isn't acceptable is the current situation, where something is formally undefined behavior, but works with all, or almost all, existing implementations, and is widely used by programmers, albeit unknowingly. -- James Kanze kanze.james (AT) neuf (DOT) fr 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 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gennaro Prota Guest Posted: Wed Aug 16, 2006 4:39 am    Post subject: Re: Need for #include <ios> On 15 Aug 2006 11:56:15 -0400, James Kanze <kanze.james (AT) neuf (DOT) fr> wrote: Quote: Personally, I rather liked the idea that each header only included a minimum, and that you only included the headers you absolutely needed. Indeed. The partitioning of standard headers is in fact on the opposite front (I'm curious: if you only need std::min or max, do you include <algorithm>?). What's worse, I've seen lot of standard proposals taking shape on the Boost list; and what where several, reasonably articulated, include files inevitably became a single monolithic <>-style header in the final paper, under the belief that this was "the standard way" to go. Hard to explain why the partitioning itself isn't considered part of the existing library practice. -- Gennaro Prota [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.