From -2213332189012024088 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,22698cf43904ecac X-Google-Attributes: gidf78e5,public From: Steve Clamage Subject: Re: iostream changes Date: 1997/09/11 Message-ID: <34173136.52AA@Eng.Sun.COM> X-Deja-AN: 271672262 References: <340BA7EE.500A@parawave.com> <5v6ife$64h@hermes.synopsys.com> X-Original-Date: Wed, 10 Sep 1997 16:45:59 -0700 Organization: Sun Microsystems, Inc. X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBNBhNlUy4NqrwXLNJAQHnegH9FStCKC2ZJb/k7onR61r9WQCGnrIe65vp P8nlMjaBUT2A2jS5TNjSNXcJhleKZbuMBrg+UqyHrBeSwjbGYyrcIA== =FrcQ Newsgroups: comp.std.c++ Originator: austern@isolde.mti.sgi.com Joe Buck wrote: > > Ironic, isn't it? The committee worked very hard to make traditional > C programs continue to compile, but felt free to break every traditional > C++ program anyone has ever written (e.g. the traditional "Hello, world" > program). The "hello world" breakage is putting all the C++ standard library into namespace std. If we had not put the library into its own namespace, we would have been flamed to a crisp for making it impossible to write portable programs because a programmer could not know what additional names an implementor might have put into the global namespace. OTOH if you really do want the whole library in the global namespace, you have that option. You can just put "using namespace std;" in your project header file. The C++ Committee agonized over the problem for writers of introductory programming texts. It would be nice to be able to present "hello world" without a "using" clause or double colons. We couldn't find a way to make that feasible. One way for writers to address the issue is the same way they address the mysterious but necessary include directive: describe it as magic which will be explained later. > This point is made very effectively in Al Stevens' column in the September > Dr. Dobbs Journal. He points out that the column writer has a dilemma: > he can write standard C++, which no compiler on earth will accept, or > he can write traditional C++, ... Did he also mention that no possible C++ standard could allow all (or even most) existing "traditional" C++ programs to compile? C++ compilers have historically been different enough that programmers have traditionally complained at being unable to write a real- world program that worked unchanged across different implementations. Would Stevens now have us believe that all the previous complaining was unfounded, that programmers routinely wrote perfectly portable programs, and the standard only now causes programs to break? > He also has some suggestions for implementers as to > how they can limit the damage: e.g. includes > and also does "using namespace std;" so that "Hello, world" still works. That is a truly bad suggestion. You would then have only two choices: leave iostreams in namespace standard, or put the entire C++ library in the global namespace, even those portions you didn't want to collide with other parts of your program. (String classes come to mind.) A better idea is for the vendor to provide an header which puts only the iostream names into the global namespace. You do that with individual using-declarations, not with the sledgehammer of "using namespace std;". I would expect vendors to provide a header along those lines so that their customers would have a smooth transition to standard C++. > It would be nice if all vendors would do such things in the same way. Aye, there's the rub. The problem is that different vendors implemented the iostream headers in different ways, using differently-named headers partitioned differently. For example, some vendors used ".h" suffixes, some used ".hxx" or ".H" or ".hh" or ".h++". Sometimes the specialized headers like fstream included the basic iosteam header and sometimes not. Sometimes the header names were truncated to 8 characters and sometimes not. No matter what extra compatibility headers the standard mandated, it would cause problems or be a waste of effort for users (and vendors) on some important systems. Instead of requiring extra features that might be counter-productive, the standard does two positive things: 1. It mandates a standard form which all systems must support. 2. It allows vendors to provide their own compatibilty-mode headers and compilers to provide a smoother transition for their customers. (Old code will continue to work.) It would have been nice to specify something that would have allowed all programmers to continue to use their old code and yet have it work unchanged across all standard-conforming implementations. That was impossible. The remainder of the changes in iostreams were required to support internationalization. The classic iostream design made it impossible to support wide characters or different locales. A standard that did not support I18N could not have passed any ISO (or ANSI) vote. Programs using iostreams in a simple way (e.g. programs in textbooks) will continue to work as written. Programmers using more sophisticated iostream features will find that some modification is necessary, often minor. Programmers concerned with I18N will find that some of it comes for free, compared to finding it impossible to do previously. I sympathize with Al Stevens' problems trying to write about C++ in a changing world. I claim his problems are no worse with the advent of the standard than they were before. The situation is analagous to writing about C in, say, 1989. This too shall pass. -- Steve Clamage, stephen.clamage_nospam@eng.sun.com ( Note: remove "_nospam" when replying ) --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]