From 5860273217941002074 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,9a6b7da9ba54eaea X-Google-Attributes: gid109fba,public X-Google-Thread: f78e5,9a6b7da9ba54eaea X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1993-06-22 14:13:11 PST Xref: gmd.de comp.lang.c++:24937 comp.std.c++:2850 Newsgroups: comp.lang.c++,comp.std.c++ Path: gmd.de!xlink.net!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!rfg From: rfg@netcom.com (Ronald F. Guilmette) Subject: Re: C++ Language Extensions Message-ID: Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <1993Jun15.214156.3591@mole-end.matawan.nj.us> <25807@alice.att.com> Date: Tue, 22 Jun 1993 20:54:19 GMT Lines: 108 In article <25807@alice.att.com> ark@alice.UUCP () writes: >In article rfg@netcom.com (Ronald F. Guilmette) writes: > >> Now don't get me wrong. I like a good Rolls-Royce as much as the next guy, >> but given my immediate needs, I'll take the Volkswagon today, rather than >> the Rolls-Royce in (maybe) five years. > >and in he writes: > >> In article daniels@NeoSoft.com (Brad Daniels) writes: >>> Section 3.3 of the working document makes explicit mention of the fact >>> that it is not possible to declare a class name static. What is the >>> rationale behind this restriction? > >> Good question. This is just another C (in-)compatability wart in my >> opinion... and an almost totally pointless one. > >This kind of behavior seems to be almost universal among people interested >in the C++ language: one moment they're saying that the language has enough >stuff in it already and the next moment they're proposing a new feature. > >I don't mean to single out Ron here -- he just happened to provide a >convenient example... OK. I don't mean to single out Andrew Koenig here, but this kind of behavior seems to be almost universal among people interested in C++. Lots of people seem to work real hard to put on blinders when it comes to discussing C++ and they seem to go out of their way to view everything strictly in a C++ context, without either an adequate understanding of, nor an adequate respect for the rules embodied in the ANSI C standard. Thus, it is often the case that such people have a hard time really grasping even simple concepts which are apparent to anyone who is on intimate terms with the ANSI C standard. So it is in this case. Andrew seems to have exercized some "selective reading" on my prior posting. He fixated on my suggestion that things like: static struct S { int member; }; static enum color { red, green, blue }; should be allowed, and he seems to have failed entirely to notice that I also mentioned the fact that in ANSI C, the names of types simply DO NOT HAVE EXTERNAL LINKAGE. Thus, in C, the above declarations are precisely and exactly equivalent to: struct S { int member; }; enum color { red, green, blue }; In other words, the `static' specifiers in the previous set of declarations are entirely superfluous in C, and they are (in effect) simply ignored by any conformant ANSI C compiler. What I suggested was that this should be the case in C++ also, for the sake of compatability with ANSI C. Now perhaps this constitutes a "new feature", but it does not exactly provide any new functionality to the programmer. Let me be quite clear about this. I *DID NOT* suggest adding any new functionality to the C++ language. I seems that Andrew and others may have totally misunderstood what I said however, and may have come to the incorrect conclusion that I was agreeing with those (confused?) folks who have here suggested that type names may have external linkage, and that some method of controlling the linkage of such names ought to be provided in C++. But nothing could be further from the truth. It is my contention that (in ANSI C at least) there simply is no such thing as a type name which has external linkage. I believe that this is also true for C++. (If not, it should be.) Thus, as I tried to point out earlier, it is simply nonsensical to even talk about adding a feature to the language which would enable the program to DISABLE external linkage for some selected type names, because those type names never even had external linkage to begin with! (Repeat after me... linkers make links for variables and functions... NOT FOR TYPE NAMES.) In short, I disagree completely with those people who believe that types names can have (or do have) external linkage, and that the keyword `static' might be used as a way to disable this external linkage. I believe that these people are just confused, and that they ought to get copies of the ANSI C standard, and spend some more time trying to understand what the term "external linkage" (which is well defined therein) really means. Separately however, I attempted to note that in ANSI C, a declaration such as: static enum color { red, green, blue }; ... is allowed, and that the `static' keyword in such a declaration is simply treated as superfluous noise, and is ignored by the compiler. Sadly, the current definition of the C++ language does not seem to be compatible with ANSI C in this respect. In C++, you are not allowed to put such a superfluous `static' specifier in a declaration of this kind. I would like to see C++ follow C in this regard. Specifically, I would like to see the keyword be allowed but ignored. It is a pity that this simple message was so completely misconstrued, but it does illustrate (I think) the level to which ignorance of the ANSI C standard abounds in the C++ community (and also in the C++ standardization committee). -- -- Ronald F. Guilmette ------------------------------------------------------ ------ domain address: rfg@netcom.com --------------------------------------- ------ uucp address: ...!uunet!netcom.com!rfg -------------------------------