Xref: utzoo comp.lang.c++:5967 gnu.g++.bug:1263 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!jarthur!uci-ics!rfg From: rfg@ics.uci.edu (Ron Guilmette) Newsgroups: comp.lang.c++,gnu.g++.bug Subject: Linkage & a question on name mangling Message-ID: <259312BD.11972@paris.ics.uci.edu> Date: 23 Dec 89 05:53:00 GMT References: <1545@aber-cs.UUCP> Reply-To: Ron Guilmette Distribution: gnu Organization: University of California, Irvine - Dept of ICS Lines: 58 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