bs@alice.UucP (Bjarne Stroustrup) (02/13/86)
> From sfmag!sftig!mhuxm!mhuxn!mhuxr!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!glacier!cdp!ted Tue Feb 11 01:44:00 1986 > Newsgroups: net.lang.c++ > Subject: Gee Toto were not in kansas anymore > A milestone would seem to have been reached. > I would assume that since a news group has been created > to discuss C++, that the language has gained some > measure of popularity in a short time. > How about a few words from the makers of C++ about where > the langauge is currently and where it is likely to go? The real milestone, which the creation of net.lang.c++ reflects, is that C++ has (finally) become available outside AT&T. This again reflects that enough people are convinced that the language definition, implementation, and documentation are sufficiently good and stable for use by a larger audience. > What features will be added? The best first order answer is none. For the moment the stability of the language is essential. An uncontrolled growth of ``features'' would be very bad. For the moment I consider myself restricted to `` bug fixes'' and ``just thinking''. What will happen in the long run is hard to predict. Naturally C++ will evolve, but I/we take compatibility very seriously. My guess is that there are a million lines of C++ ``out there'', and we are not going to make them illegal overnight. The areas where the greatest advantages can be gained now is ``standard libraries'' and ``programming environment support''. In these areas we must also strive for some measure of commonality so that we might eventually achieve a standard. In particular, a larger standard library would be really nice to have. I/we are thinking/working hard on this, but currently we have nothing to show. > Could the C++ C subset input language ever conform to ANSI standard C ? ``Conform'' in the technical sense NO, but for practical purposes YES. The ``C subset of C++'' accepted by the C++ translator (now) is probably closer to ANSI C now than your C compiler is. For example, ``struct s s;'' is not C++ since C++ has only a single name space (no separate name space for structure tags), but the C++ translator can actually handle most such declarations (though it produces a warning). Consider another example: extern f(); g() { f(1); } this is legal ANSI C, but not C++. However, the ANSI C document recommends that a compiler produces a warning in the case where a function is declared without arguments but called with arguments, thus C++ accepts the ANSI C programs that does not draw a warning. There are many minor points where C++ will simply conform to ANSI C once it becomes a standard (or even before if I/we are convinced that the proposal is good and will not change incompatibly). For example, you should eventually see single precision floating point arithmetic in C++ because there is no reason not to once it is defined for ANSI C. My friends in AT&T-IS write a lot of their compiler and programming environment stuff in C++ these days, so they are very keen on avoiding a compatibility mess. > Can the C++ output langauge conform to ANSI Standard C ? > E.g. ANSI standard C is proposed to have only > 31 character identifiers. The output of C++ > frequenetly uses more characters than that? Trivially yes, except for the 31 character limit, which is not fundamental anyway. My lastest ANSI C draft still accepts implementations with 7 character names as conforming. My hope is that the de facto standard (``portable to most systems'') will be larger than 31 (now implemented by, for example, the Microsoft loader). However, C++ can safely be used on a system with only 31 character external names. Most output (1) does not use 31 character names, (2) when it does the names are typically unique in less than 31 characters, and (3) when they are not the resulting C program will not compile. You can live with that if you have to, but try not getting into that mess (bug your compiler/linker supplier). More importantly there is no requirement that a C intermediate form be produced from C++. A ``native compiler'' would not necessarily run into the long names problem at all. > Will programming environment support tools and predefined > classes be bundled? That of course depends on a lot of things. For example, I would consider it most unlikely that AT&T would be the only supplier of such goodies. The answer might also depend on the specific tool, class, library. We will simply have to wait and see. Please note that I, as a member of AT&T Bell Labs Research, cannot speak for any AT&T marketing group let alone for AT&T as a whole. I comment on ``language issues'' not ``product plans''. > In wonder of it all, > Ted Goldstein > glacier!cdp!ted - Bjarne Stroustrup (AT&T Bell Labs, Murray Hill)