C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Re: #include doubts          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Rui Maciel Guest Posted: Fri Jun 27, 2003 7:02 pm    Post subject: Re: #include doubts On 20 Jun 2003 05:34:31 -0400, llewelly <llewelly.at (AT) xmission (DOT) dot.com> wrote: Quote: Rui Maciel <rui_maciel (AT) mail (DOT) com> writes: Could anyone explain me what is the right way to include a header in C++? Is it #include <header> or #include <header.h> ? #include The standard header names do not have suffixes. And why is that? No-one could agree on the 'right' suffix, so the committee chose to have no suffix at all, resulting in poorer support for standard headers in many tools, which expect some special suffix or other. This may be a rather stupid question but why didn't they opted for some suffix like .hpp ? It seemed to be the logic way to go Quote: This doubt surfaced because of my problems with the compiler which comes with Dev-C++ and it seems that there are some issues with the standard headers. What kind of issues? Please post short but complete code examples, and the error messages they produce. IIRC, the compiler problems surfaced when I upgraded Dev-C++, which camed with GCC 3.2, a more standard-complying version of the old compiler, if I'm not mistaken. The new compiler, being more standard-compliant, raised some warnings when compiling older code which was less faithfull to the standards. One of the issues was the one in question. Fortunatelly that problem was extremelly easy to solve (remove the .h) but still it was enough to make me realize that I didn't knew much about the subject. And by the way, I would like to thank everyone who replied to my post. You were all of great help and you (along with others who share the same spirit) are a credit not only to this newsgroup but to the entire C++ community Kudos to all . [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top llewelly Guest Posted: Sat Jun 28, 2003 11:18 pm    Post subject: Re: #include doubts Rui Maciel <rui_maciel (AT) mail (DOT) com> writes: Quote: On 20 Jun 2003 05:34:31 -0400, llewelly <llewelly.at (AT) xmission (DOT) dot.com wrote: Rui Maciel Could anyone explain me what is the right way to include a header in C++? Is it #include <header> or #include <header.h> ? #include The standard header names do not have suffixes. And why is that? No-one could agree on the 'right' suffix, so the committee chose to have no suffix at all, resulting in poorer support for standard headers in many tools, which expect some special suffix or other. This may be a rather stupid question but why didn't they opted for some suffix like .hpp ? It seemed to be the logic way to go Different tools accepted different suffixes: .h, .hh, .hxx, .h++, .hpp . Different compiler and library implementors used different suffixes. .hpp may have been the most widely accpted (I don't know), but they couldn't agree. Personally, I suspect any of the competing suffixes would have been a better choice than no suffix at all, but the lack of a suffix doesn't cause me any significant problems, and it has a certain aesthetic appeal. (I've come to view filename suffixes as a kind of hungarian for filesystems.) Certain standard library implementors have complained in this newsgroup, however. Quote: This doubt surfaced because of my problems with the compiler which comes with Dev-C++ and it seems that there are some issues with the standard headers. What kind of issues? Please post short but complete code examples, and the error messages they produce. IIRC, the compiler problems surfaced when I upgraded Dev-C++, which camed with GCC 3.2, a more standard-complying version of the old compiler, if I'm not mistaken. using namespace std; Read up on namespaces and the standard C++ library. Above, I assume you are encountering the most commonly reported problem with gcc 3.2 . [snip] Quote: And by the way, I would like to thank everyone who replied to my post. You were all of great help and you (along with others who share the same spirit) are a credit not only to this newsgroup but to the entire C++ community You are welcome. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Mon Jun 30, 2003 10:37 am    Post subject: Re: #include doubts Francis Glassborow <francis.glassborow (AT) ntlworld (DOT) com> wrote Quote: In message <e6s5fv0uppfu3g586ioepillpm6h3jrkpk (AT) 4ax (DOT) com>, Rui Maciel [email]rui_maciel (AT) mail (DOT) com[/email]> writes This may be a rather stupid question but why didn't they opted for some suffix like .hpp ? It seemed to be the logic way to go 1) that would not have been a neutral decision, it would have handicapped compilers that already used that extension because classical headers would collide with new ones that had different content. Hmmm. This raises the question: why did the new headers have different content? (Or more realistically, why wasn't the content upwards compatible. There weren't that many headers around before the standard, and adding an imbue function to the various classes in <iostream.h> wouldn't have broken anything.) In fact, I think that part of it was that the most wide spread convention (.H) depended on case sensitivity, and the other conventions varied too much. Quote: 2) Why .hpp and not .h, after all they are not lexically different from C headers. Unlike implementation files where many compilers have to switch modes there is no significance to the compiler. What do you mean they are not lexically different from C headers. Most C++ headers I've seen wouldn't pass a C compiler -- when the standard was being written, most wouldn't even have passed the lexical phase of a C compiler (because of the // comments). Generally, when I see a file with a .h, I expect it to be compilable by both the C compiler and the C++ compiler. When I saw .H, I knew it was strictly C++. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique oriente objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, Tl. : +33 (0)1 30 23 45 16 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Mon Jun 30, 2003 4:03 pm    Post subject: Re: #include doubts llewelly <llewelly.at (AT) xmission (DOT) dot.com> wrote Quote: Rui Maciel <rui_maciel (AT) mail (DOT) com> writes: On 20 Jun 2003 05:34:31 -0400, llewelly [email]llewelly.at (AT) xmission (DOT) dot.com[/email]> wrote: Rui Maciel <rui_maciel (AT) mail (DOT) com> writes: Could anyone explain me what is the right way to include a header in C++? Is it #include <header> or #include <header.h> ? #include The standard header names do not have suffixes. And why is that? No-one could agree on the 'right' suffix, so the committee chose to have no suffix at all, resulting in poorer support for standard headers in many tools, which expect some special suffix or other. This may be a rather stupid question but why didn't they opted for some suffix like .hpp ? It seemed to be the logic way to go Different tools accepted different suffixes: .h, .hh, .hxx, .h++, .hpp. Different compiler and library implementors used different suffixes. .hpp may have been the most widely accpted (I don't know), but they couldn't agree. You forgot .H. Part of the problem is that the initial C++ offering used .h for the headers (which is an obvious mistake, not to differentiate from C headers), and .C for source files. The obvious solution, in this case, is .H for headers. Except that some OS's don't distinguish case, so we're back where we started. My interpretation of the decision in the standard was that it leaves the implementation free -- if the convention was .hpp, then the compiler maps a name without a suffix to a .hpp suffix; if the convention was .H, it maps it to a .H suffix, etc.. That way, each platform continued to use the suffix it was used to, and the source code was portable. Regretfully, compiler implementors don't seem to have seen it this way. Quote: Personally, I suspect any of the competing suffixes would have been a better choice than no suffix at all, but the lack of a suffix doesn't cause me any significant problems, and it has a certain aesthetic appeal. (I've come to view filename suffixes as a kind of hungarian for filesystems.) Certain standard library implementors have complained in this newsgroup, however. The filename suffixes are a hungarian for file systems. In this case, however, the "hungarian" is justified, because there are operations that you want to do on all files of a specific type. One of the most frustrating things under Unix is that executables don't have a suffix. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Mon Jun 30, 2003 6:28 pm    Post subject: Re: #include doubts In message <d6652001.0306300144.6dec797c (AT) posting (DOT) google.com>, [email]kanze (AT) gabi-soft (DOT) fr[/email] writes Quote: Hmmm. This raises the question: why did the new headers have different content? (Or more realistically, why wasn't the content upwards compatible. There weren't that many headers around before the standard, and adding an imbue function to the various classes in wouldn't have broken anything.) But before we decided to add such things as vector there were no potential standard header files for such things. Using any common extension would have adversely affected already existing code. -- ACCU Spring Conference 2003 April 2-5 The Conference you should not have missed ACCU Spring Conference 2004 Late April Francis Glassborow ACCU [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Niklas Matthies Guest Posted: Mon Jun 30, 2003 9:03 pm    Post subject: Re: #include doubts On 2003-06-30 16:03, [email]kanze (AT) gabi-soft (DOT) fr[/email] <kanze (AT) gabi-soft (DOT) fr> wrote: Quote: llewelly <llewelly.at (AT) xmission (DOT) dot.com> wrote: [...] Personally, I suspect any of the competing suffixes would have been a better choice than no suffix at all, but the lack of a suffix doesn't cause me any significant problems, and it has a certain aesthetic appeal. (I've come to view filename suffixes as a kind of hungarian for filesystems.) Certain standard library implementors have complained in this newsgroup, however. The filename suffixes are a hungarian for file systems. In this case, however, the "hungarian" is justified, because there are operations that you want to do on all files of a specific type. One of the most frustrating things under Unix is that executables don't have a suffix. That's rather a definciency of file globbing syntax, isn't it? If files had true file types and there was appropriate syntax for selecting files with some given type (or family of types), no one would even dream of encoding file types into file names. -- Niklas Matthies [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ben Hutchings Guest Posted: Mon Jun 30, 2003 9:04 pm    Post subject: Re: #include doubts In article <d6652001.0306300152.73bcfc3a (AT) posting (DOT) google.com>, [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote: Quote: llewelly <llewelly.at (AT) xmission (DOT) dot.com> wrote in message news:<86ptky98az.fsf (AT) Zorthluthik (DOT) local.bar>... snip Personally, I suspect any of the competing suffixes would have been a better choice than no suffix at all, but the lack of a suffix doesn't cause me any significant problems, and it has a certain aesthetic appeal. (I've come to view filename suffixes as a kind of hungarian for filesystems.) Certain standard library implementors have complained in this newsgroup, however. The filename suffixes are a hungarian for file systems. In this case, however, the "hungarian" is justified, because there are operations that you want to do on all files of a specific type. One of the most frustrating things under Unix is that executables don't have a suffix. This is good because it allows a command to be implemented in any language without affecting its name. Executable files of any type can be recognised by their mode bits; executable files of a specific type can be recognised by magic numbers. However, I would prefer it if file types were stored in the file-system as metadata (as in BeOS, and RISCOS and MacOS before it). [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top André Pönitz Guest Posted: Tue Jul 01, 2003 12:45 pm    Post subject: Re: #include doubts [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote: Quote: The filename suffixes are a hungarian for file systems. You say that as if you considered this an advantage. 'Hungarian' has the annoying habit to get out-of-sync with reality over time as there is no way the compiler can flag a deviation from the intended 'standard'. So this is more of a burden than a help in strongly typed languages as C++. [It might have been a good solution in the 'everything is either an int or a char *' times, but these times are gone...] Quote: [...] One of the most frustrating things under Unix is that executables don't have a suffix. [Personally, I _this_ is an advantage. Just imagine having to type string.tcl foo.o | sort.pl | uniq.bin | less.sh on FooNix 2.3 and string.pl foo.o | sort.ksh | uniq.py | less.exe on BarNix 8.1. Or do you mean a 'single' 'generic' executable suffix like ..exe/.com/.bat/...?] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Tue Jul 01, 2003 6:27 pm    Post subject: Re: #include doubts Ben Hutchings <do-not-spam-ben.hutchings (AT) businesswebsoftware (DOT) com> wrote in message news:<slrnbg0tof.214.do-not-spam-ben.hutchings (AT) tin (DOT) bwsint.com>... Quote: In article <d6652001.0306300152.73bcfc3a (AT) posting (DOT) google.com>, [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote: llewelly <llewelly.at (AT) xmission (DOT) dot.com> wrote in message news:<86ptky98az.fsf (AT) Zorthluthik (DOT) local.bar>... snip Personally, I suspect any of the competing suffixes would have been a better choice than no suffix at all, but the lack of a suffix doesn't cause me any significant problems, and it has a certain aesthetic appeal. (I've come to view filename suffixes as a kind of hungarian for filesystems.) Certain standard library implementors have complained in this newsgroup, however. The filename suffixes are a hungarian for file systems. In this case, however, the "hungarian" is justified, because there are operations that you want to do on all files of a specific type. One of the most frustrating things under Unix is that executables don't have a suffix. This is good because it allows a command to be implemented in any language without affecting its name. What you really mean is that the information must be hidden somewhere else. The OS needs it. At times, when you are looking at a directory listing, you need it -- they didn't invent the file command for nothing. Quote: Executable files of any type can be recognised by their mode bits; executable files of a specific type can be recognised by magic numbers. However, I would prefer it if file types were stored in the file-system as metadata (as in BeOS, and RISCOS and MacOS before it). I agree that that would be the best solution. Provided, of course, that the set of file types was open, and that the information could be accessed and displayed by normal tools. In the meantime, "normal" tools access directory entries, and under Unix, sometimes, the inode data -- you can't do a find (that I know of) with a search criteria involving some magic numbers in the file. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Tue Jul 01, 2003 6:28 pm    Post subject: Re: #include doubts Niklas Matthies <comp.lang.c++.moderated_2003-06-30 (AT) nmhq (DOT) net> wrote in message news:<slrnbg0seq.2t3b.comp.lang.c++.moderated_2003-06-30 (AT) nmhq (DOT) net>... Quote: On 2003-06-30 16:03, [email]kanze (AT) gabi-soft (DOT) fr[/email] <kanze (AT) gabi-soft (DOT) fr> wrote: llewelly <llewelly.at (AT) xmission (DOT) dot.com> wrote: [...] Personally, I suspect any of the competing suffixes would have been a better choice than no suffix at all, but the lack of a suffix doesn't cause me any significant problems, and it has a certain aesthetic appeal. (I've come to view filename suffixes as a kind of hungarian for filesystems.) Certain standard library implementors have complained in this newsgroup, however. The filename suffixes are a hungarian for file systems. In this case, however, the "hungarian" is justified, because there are operations that you want to do on all files of a specific type. One of the most frustrating things under Unix is that executables don't have a suffix. That's rather a definciency of file globbing syntax, isn't it? If files had true file types and there was appropriate syntax for selecting files with some given type (or family of types), no one would even dream of encoding file types into file names. Agreed. But there are a number of reasons why this isn't the case, and won't be anytime soon: you'd need some sort of registry for the types, and of course, you'd need some sort of way of overriding the type. For the moment, we're stuck with what we have, and the absense of a suffix for executable files under Unix is a real pain. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16 [ 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 Page 1 of 1   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.