🚀 go-pugleaf

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