Xref: utzoo gnu.g++.bug:1254 comp.lang.c++:5925 Path: utzoo!telly!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!dcl-cs!aber-cs!pcg From: pcg@aber-cs.UUCP (Piercarlo Grandi) Newsgroups: gnu.g++.bug,comp.lang.c++ Subject: Re: bug 12178901 (1.36.1) - linkage of global const objects Summary: Ansi C: extern const; C++: static const Message-ID: <1516@aber-cs.UUCP> Date: 18 Dec 89 23:30:27 GMT Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi) Distribution: gnu Organization: Dept of CS, UCW Aberystwyth (Disclaimer: my statements are purely personal) Lines: 71 In article <8912171136.aa08237@ICS.UCI.EDU> rfg@ICS.UCI.EDU writes: // bug 12178901 - linkage of global const objects // What is the `linkage' of const objects in C++? storage class, not linkage: static // GCC generates code for the following such that `ci' has // extern linkage, and such that its initial value is 99. Ansi C inanely mandates it. // G++ 1.36.1 however optimizes this declaration into nothing. // Thus, if some other file contained `extern const int ci;' // that other file would fail to link. const int ci = 99; BS once posted a persuasive discussion of why const in C++ has default storage class static (and thus local linkage). If you want your const to have global linkage, use extern const ci = 99; Now, now, I am disappointed :-) about rfg not reading one of my previous fundamental and world enlightening contributions (:-> :-> :->): I posted a while ago some guidelines for C++ coding in which I suggested that the storage class and inline or const should always be explicitly indicated in C++ programs. Among the reasons I gave were the different rules concerning inlines and consts, which vary between Ansi C and C++, between releases of GNU C++ (which used, until 1.35?, to have global linkage by default for consts), and between the various C++ compilers (some do have member functions inline by default, some do not, to some inlines are static, to some are not, etc...). However, the official C++ 2.0 position is: const objects are static by default, and can be merrily optimized away if no address is taken to them; members functions defined and not just declared in the class definition are inline by default; inline functions are static by default (less sure of this, but I really hope so). Another interesting note: somebody once asked how one can specify the type of linkage for member functions, if it is to be local. Easy, at least with GNU C++: when *defining* the function, you can use static without it meaning that it is a class member function, e.g.: class first { int i; int f (int); }; // in first.H static int first::f(int i) { .... } // in first.C In other words: static in a member function *declaration* is quite different from static in a *definition*; not so inline, thank goodness. Same goes for inlining etc... My advice, as in the posted guidelines, is to *never* define member functions in the class definition, but always separately, even if they are to be inline; e.g., after the previous example: class first { int i; int f (int); int g(int); }; // in first.H static inline first::g(int i) { .... } // in first.H as well static int first::f(int i) { .... } // in first.C -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk