I am a C++ novice. Let me describe a conceptual problem I'm having...

C traditionally has had three levels of name space: global, module-local,
and inner-block. The word "static", used at the outer level, has
meant "a single copy of the storage for this entity should be allocated
statically. ALSO the scope of the name of this storage should be local
to this module (== compilation unit)."

If I were designing C, I would naturally separate these two meanings
of the word "static"... The keyword "extern" ought to have a complementary
keyword "global". If "extern/global" are not used then the name scope
is local (ie, local scope is the default on the outer block just as
in the inner blocks), and "static" *only* refers to the memory allocation.
Inner blocks become free to use "global" in the same way they can use
"extern".

Alternatively, module-local should never have been invented: "static"
would only refer to memory allocation and would be assumed on the
outer block. All outer-block objects would have global scope. This
would have removed the confusion too.

As it is, C is schizoid about its scoping customs.

I unfortunately can't fix C, and I can't fix the C-compatible parts
of C++, but there's still time at least for the classes in C++ to
work right. Specifically: when "static" variables were (recently?)
added to classes, the double meaning of the word "static" got
tangled. If the following lines appear in two different C++
source files (specifically g++ 1.37.1):

    class wrapper {
     static int baz;
    public:
     static void  inside(void);
    };
    static void wrapper::inside(void){ baz = 0; }

the "inside" routines are given module-local scope and the "baz"
variables are given global scope (specifically, .common and .global in
the assembler on my machine). This is not consistent. How can I declare
a class and all its components to be truly module-local? I tried putting a
"static" in front of the words "class wrapper"; the compiler accepted it
but did not change its output.

I'm not sure what cfront would do on the same input, and I unfortunately
don't have a copy of the ARM yet.

Putting "static" in front of "class" is not a good solution; it *seems*
well-defined when you do:

    static class foo { ... };

but it turns on you when you write:

    static class foo { ... } baz;


Class methods work out right because subroutines *always* have static
storage: the word "static" then solely means "local" and everything is
clean. Class variables are a problem though. Suggestions ? How can
we fix "static" ?

PS - Every C program I write has

    #define local   static

in the preamble. Then, for coding clarity, I use only the word "local"
and never "static" in the outer block, and only the word "static"
and never "local" in the inner blocks. Ick.

I'm rambling... someone should start "comp.lang.c.pet.peeves"
(or comp.lang."d").

Garry Wiegand    ---    Ithaca Software, Alameda, California
...!uunet!ithaca!garry, garry%ithaca.uucp@uunet.uu.net

In article <1991Jan23.002457.13584@ithaca.uucp>, garry@ithaca.uucp (Garry Wiegand) writes:

|> I unfortunately can't fix C, and I can't fix the C-compatible parts
|> of C++, but there's still time at least for the classes in C++ to
|> work right. Specifically: when "static" variables were (recently?)
|> added to classes, the double meaning of the word "static" got
|> tangled. If the following lines appear in two different C++
|> source files (specifically g++ 1.37.1):
|>
|>     class wrapper {
|>      static int baz;
|>     public:
|>      static void  inside(void);
|>     };
|>     static void wrapper::inside(void){ baz = 0; }
|>
|> the "inside" routines are given module-local scope and the "baz"
|> variables are given global scope (specifically, .common and .global in
|> the assembler on my machine). This is not consistent. How can I declare
|> a class and all its components to be truly module-local? I tried putting a
|> "static" in front of the words "class wrapper"; the compiler accepted it
|> but did not change its output.

ARM (p.18) says:
  "Static class members have external linkage.
  Noninline class member functions have external linkage. Inline class
  member functions must have exectly one definition in a program."

For static data members this makes sense, since they must be accessible
from all instances of a class. BUT does this also mean, that the
linkage of noninline class member functions ist *allways* external and
cannot be changed?

Cfront 2.0 will not compile the code above: "error: static specified for
qualified name inside()".

--
Igor Metz
Institut fuer Informatik und angew. Mathematik, Universitaet Bern, Switzerland.
domainNet: metz@iam.unibe.ch               Phone: (0041) 31 65 49 90
ARPA:      metz%iam.unibe.ch@relay.cs.net  Fax:   (0041) 31 65 39 65