In article <EDP57.11614$Up.345384@sea-read.news.verio.net>, C. M. Heard
<heard@vvnet.com> writes
>That would be a reasonable way to use those terms, but it's not the
>way the C++ standard uses them.

True, but they expect readers to understand linkage :)


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
>In article <%9657.11405$Up.339914@sea-read.news.verio.net>, C. M. Heard
><heard@vvnet.com> writes
>>That's incorrect.  Namespace scope objects are deprecated, but namespace
>>scope functions are are not.  Interestingly, core language issues #167
>>and #174 suggested that this be rectified, but in opposite ways:  #167
>>proposed to deprecate namespace scope static functions, while #174 proposed
>>to reverse the deprecation of namespace scope static objects.  Both of
>>these have been subsumed under issue #223.
>>
>>Mike
>>
>>P.S.  I happen to agree with Mr. Mensonides and with the proposal in core
>>language issue #174.  It's not at all obvious to me why declaring namespace
>>scope static functions or objects is a bad thing to do  (other than,
>>perhaps, the unintuitive overloading of the word "static").
>
>I think you meant 'filescope' in several places where you wrote
>'namespace scope'.

No, I meant 'namespace scope'.  I used that term because it's what appears
in the standard.  If I read the standard correctly, the older term 'file
scope' has been superseded by the term 'global scope' and is a special case
of 'namespace scope'.

>Two features of declarations in the anonymous namespace should be noted.
>The first is that such items have extern linkage. That can be important
>because some templates require template parameters with extern linkage.

Understood.

>The second is that it is the only way that we can declare a class that
>will only be visible at filescope. I am greatly in favour of consistency
>and so would advocate that those writing declarations that need to have
>restricted visibility (restricted to filescope) should put all of them
>in an anonymous namespace.

I was not aware of that.  Thanks for pointing it out.

>This also, I think, demonstrates why the definitions of functions
>declared in an anonymous namspace must also be lexically in such that
>same namespace. Trying to define them at filescope will result in either
>internal linkage (if you qualify them as static) or global visibility if
>you do not.
>
>Of course we could change the linkage rules but I do not think I am the
>only one who dislikes special cases.

No problem by me (although I expect Mr. Mensonides will be displeased).

Mike

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <u4s57.11507$Up.342471@sea-read.news.verio.net>, C. M. Heard
<heard@vvnet.com> writes
>No, I meant 'namespace scope'.  I used that term because it's what appears
>in the standard.  If I read the standard correctly, the older term 'file
>scope' has been superseded by the term 'global scope' and is a special case
>of 'namespace scope'.


No, file scope is not the same as global scope. A static qualified
declaration outside an explicit namespace has internal linkage and is at
filescope, if it is not static qualified it has global scope. Yet
another place for confusion to reign.

Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> No, file scope is not the same as global scope. A static qualified
> declaration outside an explicit namespace has internal linkage and is at
> filescope, if it is not static qualified it has global scope. Yet
> another place for confusion to reign.

Francis, my question was entirely whether it it legal to *define* a function
outside of the unnamed namespace where it was *declared*.  I completely agree
that unnamed namespaces are a better solution.  However, if I *must* define them
inside of the unnamed namespace proper, it will be the *only* place that I must
define functions in a nested manner.  That is definitely an anomaly (as are
anonymous namespaces in general).

My question is this:  if I have a function declaration in an unnamed namespace:

namespace {
    void f();
}

And then I have a function definition outside of it:

void f() {
    // ...
    return;
}

Does the definition of "f" refer to the declaration of "f" in the anonymous
namespace, or is it an ambiguous overload (i.e. without :: qualification)?

Ideally, in my opinion, the "f" definition should define the previously declared
"f".  Otherwise, I have two alternatives:

-----------------------------------

// ex. 1

namespace {

    int g_x = 1, g_y = 2, g_z = 3;

    void f() {
        // ... long winded function here
        return;
    }

    void g() {
        // ... long winded function here also
        return;
    }

} // anonymous namespace

----------------------------------- or...

// ex. 2

namespace {
    int g_x = 1, g_y = 2, g_z = 3;
}

static void f() {
    // ... long winded (non-nested) function here
    return;
}

static void g() {
    // ... long winded (non-nested) function here as well
    return;
}

-----------------------------------

Example #1 looks like Java.  I *hate* being forced to define things in a nested
declaration.  It is a waste of my screen space.  It is especially bad when there
are many nested levels:

-----------------------------------

// ex. 3

namespace MyLibrary {
    namespace SubSection {
        class C {
            public:
                void f();
        };
        namespace {
            void annoying() {
                // ... long winded function defined inline
                // ex:
                for (...) {
                    if (...) {
                        if (...) {
                            while (...) {
                                if (...) {
                                    // ...
                                }
                            }
                        }
                        else {
                            // ...
                        }
                    }
                    else if (...) {
                        while (...) {
                            switch (...) {
                                case a:
                                    // ...
                                    break;
                                case b:
                                    // ...
                                    break;
                                default:
                                    // ...
                            }
                        }
                    }
                    else {
                        do {
                            // ...
                        } while (...);
                    }
                }
                return;
            }
        }
    }
    class D {
        public:
            void g();
    };
}

void MyLibrary::SubSection::C::f() {
    // ... long winded function
    return;
}

void MyLibrary::D::g() {
    // ... long winded function
    return;
}

void MyLibrary::SubSection::annoying() {
    // ... can this be *defined* outside of the unnamed namespace?
    for (...) {
        if (...) {
            if (...) {
                while (...) {
                    if (...) {
                        // ...
                    }
                }
            }
            else {
                // ...
            }
        }
        else if (...) {
            while (...) {
                switch (...) {
                    case a:
                        // ...
                        break;
                    case b:
                        // ...
                        break;
                    default:
                        // ...
                }
            }
        }
        else {
            do {
                // ...
            } while (...);
        }
    }
    return;
}

Paul Mensonides

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <HOH57.378546$p33.7579781@news1.sttls1.wa.home.com>, Paul
Mensonides <pmenso57@home.com> writes
>My question is this:  if I have a function declaration in an unnamed namespace:
>
>namespace {
>    void f();
>}
>
>And then I have a function definition outside of it:
>
>void f() {
>    // ...
>    return;
>}
>
>Does the definition of "f" refer to the declaration of "f" in the anonymous
>namespace, or is it an ambiguous overload (i.e. without :: qualification)?
>
>Ideally, in my opinion, the "f" definition should define the previously declared
>"f".  Otherwise, I have two alternatives:

Definitions are always declarations. Therefore the two f() are different
declarations, but there is no way of disambiguating them outside the
namespace (though inside ::f() would, I think, do the job)


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
>In article <u4s57.11507$Up.342471@sea-read.news.verio.net>, C. M. Heard
><heard@vvnet.com> writes
>>No, I meant 'namespace scope'.  I used that term because it's what appears
>>in the standard.  If I read the standard correctly, the older term 'file
>>scope' has been superseded by the term 'global scope' and is a special case
>>of 'namespace scope'.
>
>No, file scope is not the same as global scope. A static qualified
>declaration outside an explicit namespace has internal linkage and is at
>filescope, if it is not static qualified it has global scope. Yet
>another place for confusion to reign.

That would be a reasonable way to use those terms, but it's not the
way the C++ standard uses them.   The only place where the term
'file scope' is used is in the non-normative Annex C.  The normative
sections of interest are 3.3.5 and D.2, and this is what they say:

     3.3.5 Namespace scope                        [basic.scope.namespace]
     [...]
     A name declared outside all named or unnamed namespaces (7.3),
     blocks (6.3), function declarations (8.3.5), function definitions
     (8.4) and classes (clause 9) has global namespace scope (also
     called global scope).  The potential scope of such a name begins
     at its point of declaration (3.3.1) and ends at the end of the
     translation unit that is its declarative region.  Names declared
     in the global namespace scope are said to be global.
     [ ...]
     D.2 static keyword                                     [depr.static]
     The use of the static keyword is deprecated when declaring objects
     in namespace scope (see 3.3.5).

If you think this is confusing and was not what was intended then
perhaps a DR is in order.

Mike

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Is it legal to define a function outside of an unnamed namespace?

namespace {
    void f();
}

void f() {
    return;
}

If it isn't, it should be.  Defining functions in a nested fashion is annoying,
and it makes me (and possibly others) prefer 'static' functions:

static void f() {
    return;
}

// rather than:

namespace {
    void f() {
        return;
    }
}

Paul Mensonides

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Paul Mensonides wrote:
>
> Is it legal to define a function outside of an unnamed namespace?
>
> namespace {
>     void f();
> }
>
> void f() {
>     return;
> }

Yes. What you've done there is define f() in the global namespace.

> If it isn't, it should be.  Defining functions in a nested fashion is annoying,
> and it makes me (and possibly others) prefer 'static' functions:
>
> static void f() {
>     return;
> }

That use of static is officially deprecated, in favor of the following:

> namespace {
>     void f() {
>         return;
>     }
> }

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3B54E127.E35402FF@wizard.net...
> Paul Mensonides wrote:
> >
> > Is it legal to define a function outside of an unnamed namespace?
> >
> > namespace {
> >     void f();
> > }
> >
> > void f() {
> >     return;
> > }
>
> Yes. What you've done there is define f() in the global namespace.

That is not what I mean.  Is f(), in the above example, local to the translation
unit, or is f() a declaration in a *different* scope than the one declared in
the unnamed namespace?  I want to *define* the function outside of the namespace
nesting:

// like this...

namespace A {
    void f();
}

void A::f() { return; }

// but without the namespace name...

namespace {
    void f();
}

void f() { return; }

> > If it isn't, it should be.  Defining functions in a nested fashion is
annoying,
> > and it makes me (and possibly others) prefer 'static' functions:
> >
> > static void f() {
> >     return;
> > }
>
> That use of static is officially deprecated, in favor of the following:

I realize that.  My point is that defining functions in a nested manner is
annoying.

Paul Mensonides

> > namespace {
> >     void f() {
> >         return;
> >     }
> > }


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

James Kuyper Jr. wrote:
> Paul Mensonides wrote:
[ ... ]
> > If it isn't, it should be.  Defining functions in a nested fashion is
> > annoying, and it makes me (and possibly others) prefer 'static' functions:
> >
> > static void f() {
> >     return;
> > }
>
> That use of static is officially deprecated, in favor of the following:
>
> > namespace {
> >     void f() {
> >         return;
> >     }
> > }

That's incorrect.  Namespace scope objects are deprecated, but namespace
scope functions are are not.  Interestingly, core language issues #167
and #174 suggested that this be rectified, but in opposite ways:  #167
proposed to deprecate namespace scope static functions, while #174 proposed
to reverse the deprecation of namespace scope static objects.  Both of
these have been subsumed under issue #223.

Mike

P.S.  I happen to agree with Mr. Mensonides and with the proposal in core
language issue #174.  It's not at all obvious to me why declaring namespace
scope static functions or objects is a bad thing to do  (other than,
perhaps, the unintuitive overloading of the word "static").

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B54E127.E35402FF@wizard.net>...

> Paul Mensonides wrote:
> >
> > Is it legal to define a function outside of an unnamed namespace?
> >
> > namespace {
> >     void f();
> > }
> >
> > void f() {
> >     return;
> > }
>
> Yes. What you've done there is define f() in the global namespace.
>
> > If it isn't, it should be.  Defining functions in a nested fashion is annoying,
> > and it makes me (and possibly others) prefer 'static' functions:
> >
> > static void f() {
> >     return;
> > }
>
> That use of static is officially deprecated, in favor of the following:
> > namespace {
> >     void f() {
> >         return;
> >     }
> > }

The Standard only depricates namespace scope _object declarations_
that feature the keyword static. No mentioning of _function
declarations_ is made. See 7.3.1.1/2 and D.2/1.


Regards,

Andrei Iltchenko.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <%9657.11405$Up.339914@sea-read.news.verio.net>, C. M. Heard
<heard@vvnet.com> writes
>That's incorrect.  Namespace scope objects are deprecated, but namespace
>scope functions are are not.  Interestingly, core language issues #167
>and #174 suggested that this be rectified, but in opposite ways:  #167
>proposed to deprecate namespace scope static functions, while #174 proposed
>to reverse the deprecation of namespace scope static objects.  Both of
>these have been subsumed under issue #223.
>
>Mike
>
>P.S.  I happen to agree with Mr. Mensonides and with the proposal in core
>language issue #174.  It's not at all obvious to me why declaring namespace
>scope static functions or objects is a bad thing to do  (other than,
>perhaps, the unintuitive overloading of the word "static").

I think you meant 'filescope' in several places where you wrote
'namespace scope'.

Two features of declarations in the anonymous namespace should be noted.
The first is that such items have extern linkage. That can be important
because some templates require template parameters with extern linkage.

The second is that it is the only way that we can declare a class that
will only be visible at filescope. I am greatly in favour of consistency
and so would advocate that those writing declarations that need to have
restricted visibility (restricted to filescope) should put all of them
in an anonymous namespace.

This also, I think, demonstrates why the definitions of functions
declared in an anonymous namspace must also be lexically in such that
same namespace. Trying to define them at filescope will result in either
internal linkage (if you qualify them as static) or global visibility if
you do not.

Of course we could change the linkage rules but I do not think I am the
only one who dislikes special cases.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]