rfg@ics.uci.edu (Ron Guilmette) (12/23/89)
In article <1545@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > > Anyway, many people have now corrected me regarding the C++ default linkage > for const objects. > >This is really being a language lawyer, but: linkage != storage class. From >what I understand, const implies by default the *storage class* static; this >in turn, at file scope, implies local linkage. To see the difference, ^^^^^^^^^^^^^^^^^^^^^ *This* is really being a language lawyer, but note that the two concepts are strongly related. >consider const entities local to a block; is their default storage class >"auto" or "static"? To me it is "static" in C++ (and "auto" in Ansi C), even >if linkage only really makes sense at file scope level. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ More language lawyering. This is *not* true in cases where you have nested things declared `extern'. >Just to show off: how many of you did know that "typedef" technically is a >storage class in C (and C++), Not me, but then that is just a syntactic convenience which should be invisible to the user if proper semantic errors are being produced. >and that 'extern "C"' does *not* imply >the "extern" storage class, because it is not a storage class? But it *does* (at least partially). In 7.4: "Otherwise, a function declared in a linkage specification behaves as if it was explicitly declared `extern'". >Does it matter that 'extern "C"' is not a storage class ? YES! for example, >both of these are accepted gleefully by GNU C++ (and correctly, I believe): > > extern "C" typedef int algebraic; /* correct, but somewhat pointless */ Perhaps there is some point to such a construct if your debugger has enough smarts to know about typedef names, but is also to dumb to know about C++ name mangling. >Notice that since mangling does not apply to variable names yet... Yes. Can somebody please tell me why that is the case? It seems to me that all of the "type checking" effects that are squeezed out of the linker via name mangling function names would be equally applicable to the problem of assuring that the types of variables and (extern) const's were consistant across object files. What's the story? >I think that Ron Guilmette (I remember he being the author) has a few new/old >interesting test cases to add to his fine C++ test suite... And a little more You can be sure that I've squirrled your posting away for inclusion at some future point Peter. // rfg
pkturner@cup.portal.com (Prescott K Turner) (12/27/89)
In article <259312BD.11972@paris.ics.uci.edu> rfg@ics.uci.edu (Ron Guilmette) w rites: > In article <1545@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > > ... > >Notice that since mangling does not apply to variable names yet... > > Yes. Can somebody please tell me why that is the case? It seems to me that > all of the "type checking" effects that are squeezed out of the linker via > name mangling function names would be equally applicable to the problem > of assuring that the types of variables and (extern) const's were consistant > across object files. What's the story? This was a conscious decision documented in Stroustrup's paper on type-safe linkage at Usenix '88. The difference between variables and functions is that in most references to a function name, arguments are present which neatly determine which overloaded alternative to call. Consider a header file which declares extern long count; then in a file which includes this header a user declares int count; ... // and refer to count: long i = count; There are two ways to look at this that relate to name mangling: 1. "count" is an overloaded variable name, and the user is going to get the variable declared long. 2. "count" has inconsistent declarations. Number 1 is unsatisfactory because this kind of example can surprise the user. The paper doesn't find it worth discussing. Number 2 is not supported by name mangling. Since "long count" and "int count" would have different mangled names, the linker would not find the error in the program. -- Prescott K. Turner, Jr. Language Processors, Inc. 959 Concord St., Framingham, MA 01701 USA (508) 626-0006 x232 UUCP: ...sun!cup.portal.com!pkturner Internet: pkturner@cup.portal.com