On Tue, Feb 17, 2004 at 09:14:02AM -0800, Dave Carrigan wrote: > On Tue, Feb 17, 2004 at 12:23:37PM -0500, Mike M wrote: > > > The discussion of declaring main is off the point though. The example > > is to show that the C++ compilers weren't complaining about the .h on the > > #includes. > > Off the point, but still important: portable C++ requires that main() > returns an int.
Agreed. But not in small code examples. It's plain to see from the example that the -Wall option caught the infraction and described it quite plainly. I always use -Wall and I always clean up the warnings. > > > It's puzzling to me why it was necessary to make iostream when > > iostream.h works just fine. (That's a retorical question aimed at > > the C++ godz). Me thinks the godz are running out of room for improving C++. They have reached the point of rapidly diminishing returns. > > Part of the formal C++ standard includes the specification of the C++ > Standard Library. That spec says what the names of the standard header > files should be, and the spec says that none of the standard header > files have an extension. > > Vendors can do whatever they want behind the scenes to implement the > spec. In the case of GNU C++, they choose to implement it by putting an > "iostream" file in the standard include search path, and that file > #include's an "iostream.h". In theory, a vendor could choose to > implement "#include <iostream>" by loading a pre-compiled header file > from a database, and not providing an actual file called iostream at > all. The only important thing is that the vendor supports #include > <iostream> correctly. > > If you want to write portable C++, you must also use the proper header > name. That means > > #include <iostream> > > NOT > > #include <iostream.h> It's important if you want to the use the namespace feature. However, as detailed below, the namespace feature is esoteric and not widely available. According to the advice above 100% of C++ programmers must change to accomodate the namespace feature which is used by a small percentage of C++ coders. > > The latter might work for GNU C++, but it might not work for somebody > else's C++. To reiterate: when you #include <iostream.h>, you are > emphatically NOT getting definitions for the C++ Standard Library's > iostream classes. With GNU C++ you emphatically are. The GNU C++ maintainers implemented iostream as wrapper to iostream.h. The GNU C++ implementors are a smart bunch and they obviously are not making much of a distintion between iostream and iostream.h. Besides, what use is a compiler that does not support iostream.h with reliable functionality? I think the real issue is that the C++ godz want mortal coders to change their habits so that their latest features will work. > You might think you are, but you're not, and your code > won't be portable. You cannot simply write C++ to the standard and expect to be portable. The mozilla guide bears this position. There is portability defined by the standard and then there is portability defined by practical application of a variety compilers against a code set. The two methods disagree at times and the second method settles the arguments at the the mozilla project. > > The main reason why this became the standard is because they needed to > provide backwards compatibility. Vendors had already been shipping > iostream.h, but the Standard put iostream into the std namespace, and > many vendors' iostream.h did not. So, they needed to come up with new > headers that could follow the Standard without breaking backwards > compatibility with existing code that #include's iostream.h. So iostream.h is still valid. It has to be or old code can't be compiled with the new compiler, and that makes the new compiler less valuable. > > The standards committee decided that the most straightforward approach > would be to eliminate the extension altogether. They didn't eliminate the extension. They just sternly say you shouldn't use .h extrensions anymore. Nevermind the fact that there are unfathomable person-hours of human engineering to use the .h extension in include files. The removal of the .h extension is in support of the namespace feature which seems to be implemented unevenly. >From the mozilla C++ portability guide: <quote> 5. Don't use namespace facility. Support of namespaces (through the namespace and using keywords) is a relatively new C++ feature, and not supported in many compilers. Don't use it. </quote> BTW, the user controllable namespace concept is truly frightening from a code maintenance point of view. The maintainer must learn the new namespace functionality like it was a new and poorly documented language. > > Not also that if you want to include C headers (e.g., stdlib.h), the > correct include is > > #include <cstdlib> > > NOT > > #include <stdlib.h> The C standard committee has surely lost its way if this is true. I'll change when there's something in it for me: 1. compiler rejects .h extension 2. include files with .h extrensions are no longer available 3. someone pays me -- Mike Two hundred years ago, we note mischievously, the average American or European had a standard of living not very much superior to that of the average man in India or China. -- dailyreckoning.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
