Would any of the mavens on the standardization committee help me to
understand the intended effect(s) of unnamed namespaces with respect to
linkage specification?  The draft proposal  (as found in the latest
update to Appendix A of Stroustrup/2e, grabbed off the net) states that:


        "All unnamed namespaces within a compilation unit are treated
        as one namespace 'the unnamed namespace' and treated as if it
        had a name that is unique in a program.  ...
                A type, object, function, etc., declared within a
        namespace is a member of that namespace and doesn't  clash  with
        names defined outside that namespace."

And also ("Comments on Namespaces"):

        "Unnamed namespaces make global static redundant."


  I'm sure I must be missing something obvious here.  Doesn't this say that
each compilation unit gets its *own* unnamed namespace ("treated as if it
had a name that is unique in a program"), and that all declarations in the
unnamed namespace default to static linkage ("Unnamed namespaces make global
static redundant")?  But how can this be, since

        "A file scope name without a storage-class-specifier has external
        linkage unless it has previously been given internal linkage and
        provided it is not declared const."  (ARM, section 7.1.1)

  I'm at a loss (no flames, please) -- the intention of the "unnamed
namespace" cannot be to break the default linkage specification of

file scope names  (can it?), so how should  one interpret the draft
proposal?
  Also -- have the namespace proposals been voted on yet?

                        Many thanks,

                        David  Pannett  (dpannett@lucy.wellesley.edu)

< From: dpannett@marcie.wellesley.edu (David Pannett)
< Fergus Henderson  (fjh@munta.cs.mu.OZ.AU)  writes:
<
< [re declarations within "the unnamed namespace"]
<< "the declarations still have conceptually extern linkage - but it's
<< impossible to refer to them from outside that compilation unit, since the
<< namespace isn't named.  The implementation could implement this using
<< extern linkage, or it could use the "as-if" rule and implement this using
<< static linkage, since there's no way that a conforming program can tell
<< the difference."
<
< This clears up my original question about the apparent inconsistency
< between the draft proposal on namespaces and current C++ rules on default
< linkage specifications -- assuming the correctness of Mr. Henderson's
< interpretation of the namespace proposal, global declarations (in the
< "unnamed namespace") will henceforth be *conceptually* extern, but
< effectively static, and may even be implemented as static by the compiler,
< since such declarations will be invisible from  outside the compilation
< unit.

Mr Henderson's interpretation matches my understanding of the namespace
extension.

< However: doesn't this break lots and lots of code?!  That is, doesn't all
< code relying  on (default) extern  linkage of global declarations --
< e.g., of global functions that get called from  other compilation units --
< break under the proposed namespace rules, since the function definition
< will be invisible outside of the file in which it appears?
<
< This seems like such a basic case of incompatibility with older code that
< I have to believe that I'm still missing something fundamental.  (Forget
< *older* code -- how about *existing* code?)
<
< Is this in fact the correct interpretation of the "unnamed namespace"?
< Has this  been voted on yet?  Anyone?

I think this is what you're missing:

A global extern declared like

 int x;
 int foo() { }

will remain globally visible. If you were to wrap that in an unnamed
namespace

 namespace {  // note: no name
  int x;
  int foo() { }
 }

only then will it be functionally equivalent to

 static int x;
 static int foo() { }

You don't get an unnamed namespace by default.

     Tony Hansen
       hansen@pegasus.att.com, tony@attmail.com
    att!pegasus!hansen, attmail!tony

dpannett@marcie.wellesley.edu writes:

>Would any of the mavens on the standardization committee help me to
>understand the intended effect(s) of unnamed namespaces with respect to
>linkage specification?  The draft proposal  (as found in the latest
>update to Appendix A of Stroustrup/2e, grabbed off the net) states that:
>
>        "All unnamed namespaces within a compilation unit are treated
>        as one namespace 'the unnamed namespace' and treated as if it
>        had a name that is unique in a program.  ...
>                A type, object, function, etc., declared within a
>        namespace is a member of that namespace and doesn't  clash  with
>        names defined outside that namespace."
>
>And also ("Comments on Namespaces"):
>
>        "Unnamed namespaces make global static redundant."
>
>  I'm sure I must be missing something obvious here.  Doesn't this say that
>each compilation unit gets its *own* unnamed namespace ("treated as if it
>had a name that is unique in a program"), and that all declarations in the
>unnamed namespace default to static linkage ("Unnamed namespaces make global
>static redundant")?

No, as I read it the declarations still have conceptually extern
linkage - but it's impossible to refer to them from outside that
compilation unit, since the namespace isn't named.  The implementation
could implement this using extern linkage, or it could use the "as-if"
rule and implement this using static linkage, since there's no way that
a conforming program can tell the difference.  Probably the latter
implementation would lead to slightly reduced link times.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

Fergus Henderson  (fjh@munta.cs.mu.OZ.AU)  writes:

[re declarations within "the unnamed namespace"]
"the declarations still have conceptually extern
linkage - but it's impossible to refer to them from outside that
compilation unit, since the namespace isn't named.  The implementation
could implement this using extern linkage, or it could use the "as-if"
rule and implement this using static linkage, since there's no way that
a conforming program can tell the difference."

This clears up my original question about the apparent inconsistency
between the draft proposal on namespaces and current C++ rules on
default linkage specifications -- assuming the correctness of Mr. Henderson's
interpretation of the namespace proposal, global declarations (in the
"unnamed namespace") will henceforth be *conceptually* extern, but
effectively static, and may even be implemented as static by the
compiler,  since such declarations will be invisible from  outside the
compilation unit.

However: doesn't this break lots and lots of code?!  That is, doesn't all
code relying  on (default) extern  linkage of global declarations --  e.g.,
of global functions that get called from  other compilation units -- break
under the proposed namespace rules, since the function definition will be
invisible outside of the file in which it appears?

This seems like such a basic case of incompatibility with older code that
I have to believe that I'm still missing something fundamental.  (Forget
*older* code -- how about *existing* code?)

Is this in fact the correct interpretation of the "unnamed namespace"?   Has
this  been voted on yet?  Anyone?

                                Many thanks,

                                David Pannett  (dpannett@lucy.wellesley.edu)

In article <12OCT93.16523100@marcie.wellesley.edu>,
 <dpannett@marcie.wellesley.edu> wrote:
>Fergus Henderson  (fjh@munta.cs.mu.OZ.AU)  writes:
>
>[re declarations within "the unnamed namespace"]
>"the declarations still have conceptually extern
>linkage - but it's impossible to refer to them from outside that
>compilation unit, since the namespace isn't named.  The implementation
>could implement this using extern linkage, or it could use the "as-if"
>rule and implement this using static linkage, since there's no way that
>a conforming program can tell the difference."
>
>This clears up my original question about the apparent inconsistency
>between the draft proposal on namespaces and current C++ rules on
>default linkage specifications
...
>However: doesn't this break lots and lots of code?!  That is, doesn't all
>code relying  on (default) extern  linkage of global declarations --  e.g.,
>of global functions that get called from  other compilation units -- break
>under the proposed namespace rules, since the function definition will be
>invisible outside of the file in which it appears?

You're missing the fact that an "extern" declaration makes a variable
global in the traditional sense, as if it were part of a single global
namespace.  In C++, in order for a variable to be used outside the
compilation unit in which it's defined, there must be an "extern"
declaration of the variable included in the other compilation unit
which accesses the variable.  In all well-written C++ programs, if the
variable is meant to be accessed by other compilation units, there will
be such an extern declaration in the header file which declares the classes
and functions implemented in the compilation unit, and that header file
will be included by the compilation unit defining the variable.  Thus,
any code where the defining compilation unit "knows" the variable is
for external consumption (because of an extern declaration) will work
unchanged.

Only really questionable code where the defining compilation unit doesn't
include an extern declaration will break.

- Brad
--
----------------------------------------------------------------------
+ Brad Daniels   | "Let others praise ancient times;  +
+ Biles and Associates  |  I am glad I was born in these."   +
+ These are my views, not B&A's |   - Ovid(43 B.C - 17 A.D)    +

In article <11OCT93.17454571@marcie.wellesley.edu> dpannett@marcie.wellesley.edu writes:
>Would any of the mavens on the standardization committee help me to
>understand the intended effect(s) of unnamed namespaces with respect to
>linkage specification?  The


>        "Unnamed namespaces make global static redundant."
>
>  I'm sure I must be missing something obvious here.  Doesn't this say that
>each compilation unit gets its *own* unnamed namespace ("treated as if it
>had a name that is unique in a program"), and that all declarations in the
>unnamed namespace default to static linkage ("Unnamed namespaces make global
>static redundant")?

 No, things in unnamed namespaces default to external
linkage as usual.

 What happens is that the un-named namespace is like
a named one with a unique name (per translation unit), and
thus names in unnamed namespaces of different translation units
can never be associated with each other at link time.

 // file 1
 namespace { int x; }

 // file 2
 namespace { int x; }

The 'x' here have external linkage, but their mangled names might be

 ___file1_int_$$%%_x
 ___file2_int_$$%%_x

(for example :-)

What this means is that the compiler does not have to bother
exporting these names to the linker ... so the names
are like 'static' variable names in that sense.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA