In article <3985F6B9.FAC62118@jps.net>, Dennis Yelle <dennis51@jps.net>
writes
>I really don't understand why some people dislike that
>usage of "static" so much.

Basically, because it is used in so many ways and so often not used when
it should be. It is a lot easier to write (by default) my whole TU in an
unnamed namespace and simply yank out the bits I want 'exported'. In
addition it allows me to have strictly TU scope udt's. Once we have a
more general mechanism it seems reasonable to use it to replace the
previous one (particularly when the previous one uses a keyword that has
other meanings).

I think that with the exception of filescope static, the static keyword
always means 'compile time' (the sense of 'static' as opposed to
'dynamic' in CS) Filescope 'static' is an oddity because what it
qualifies is always static, and what it means is 'intern' in the sense
of not 'extern'.

Even writing about 'static' is confusing, talking about it (where we
have no source code font for disambiguation) is near impossible.


Francis Glassborow      Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <39863429.441ED1E1@jps.net>, Dennis Yelle  <dennis51@jps.net> wrote:
>Greg Comeau wrote:
>> In article <8lshrm$q9$1@plutonium.btinternet.com>,
>> Chris Newton <chrisnewton@no.junk.please.btinternet.com> wrote:
>> >Why is the use of unnamed namespaces preferred over "static"?....
>>
>> I'm not exactly sure what you're looking for, but have a look at
>> http://www.comeaucomputing.com/techtalk/#nostatic
>> If there's some other issue, holler.
>
>OK, I read that (section of) that page, and everything was OK
>until I got to this:
>
>  Draw your attention to that that none of the above is equal to this:
>
>  // x.cpp
>  namespace { // DDD
>      static bool flag = false;
>  }
>
>I give up, when would I ever want to say that instead of this:
>
> namespace { // DDD
>      bool flag = false;
>  }
>
>And please don't tell me that it prevents flag from being used
>as a template parameter.

My point was that you really wouldn't want to say it.
I guess one could say that it is redundant, and kinda just
brings the issues right back.  I only showed it because
I figured somebody would have thought that one of the previous
versions looked like that, and wanted to point out that none were.
I'll add some words to this effect.

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <3985F6B9.FAC62118@jps.net>, Dennis Yelle <dennis51@jps.net>
> writes
> >I really don't understand why some people dislike that
> >usage of "static" so much.
>
> Basically, because it is used in so many ways and so often not used when
> it should be. It is a lot easier to write (by default) my whole TU in an
> unnamed namespace and simply yank out the bits I want 'exported'. In
> addition it allows me to have strictly TU scope udt's. Once we have a
> more general mechanism it seems reasonable to use it to replace the
> previous one (particularly when the previous one uses a keyword that has
> other meanings).
>
> I think that with the exception of filescope static, the static keyword
> always means 'compile time' (the sense of 'static' as opposed to
> 'dynamic' in CS) Filescope 'static' is an oddity because what it
> qualifies is always static, and what it means is 'intern' in the sense
> of not 'extern'.
>
> Even writing about 'static' is confusing, talking about it (where we
> have no source code font for disambiguation) is near impossible.

Well, since static always means "not-auto and not-extern" I
guess that the only real reason people find it confusing is
that the books don't explain it properly.  The only reason static
SEEMS to mean 2 different things is that it can be used inside
a function, where the default for variables is "auto and not-extern"
and outside a function where the default is "not-auto and extern".
And it is impossible to have a variable (or anything else)
that is both auto and extern.  (For hopefully obvious reasons.)
But I thought that the regulars here already knew all of this.
(Especially you, Francis, and, by the way, this is intended to be
 a complement, not an insult.)

You are right when you say that static is not used as often as
it should be.  Just like const, static should have been the default
for functions and variables defined outside a function.  But, I suppose
that it is too late to change either of those now.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  http://table.jps.net/~vert

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <3985F6B9.FAC62118@jps.net>, Dennis Yelle <dennis51@jps.net>
> writes
> >I really don't understand why some people dislike that
> >usage of "static" so much.
>
> Basically, because it is used in so many ways and so often not used when
> it should be. It is a lot easier to write (by default) my whole TU in an
> unnamed namespace and simply yank out the bits I want 'exported'. In
> addition it allows me to have strictly TU scope udt's. Once we have a
> more general mechanism it seems reasonable to use it to replace the
> previous one (particularly when the previous one uses a keyword that has
> other meanings).
>
> I think that with the exception of filescope static, the static keyword
> always means 'compile time' (the sense of 'static' as opposed to
> 'dynamic' in CS) Filescope 'static' is an oddity because what it
> qualifies is always static, and what it means is 'intern' in the sense
> of not 'extern'.
>
> Even writing about 'static' is confusing, talking about it (where we
> have no source code font for disambiguation) is near impossible.

  Please ignore my previous message on this subject.
  This is what I intended to write:

Well, since static always means "not-auto and not-public" I
guess that the only real reason people find it confusing is
that the books don't explain it properly.  The only reason static
SEEMS to mean 2 different things is that it can be used inside
a function, where the default for variables is "auto and not-public"
and outside a function where the default is "not-auto and public".
And it is impossible to have a variable (or anything else)
that is both auto and public.  (For hopefully obvious reasons.)
But I thought that the regulars here already knew all of this.
(Especially you, Francis, and, by the way, this is intended to be
 a complement, not an insult.)

You are right when you say that static is not used as often as
it should be.  Just like const, static should have been the default
for functions and variables defined outside a function.  But, I suppose
that it is too late to change either of those now.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  http://table.jps.net/~vert

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <398A345C.26196E2E@jps.net>, Dennis Yelle  <dennis51@jps.net> wrote:
>Well, since static always means "not-auto and not-extern" I
>guess that the only real reason people find it confusing is
>that the books don't explain it properly.

That's one reason, in fact a real good one.  However, it
really is confusing.  Check out this bugger:

    static int i;
    extern int i;

This is fine in C and C++, and also ripples into that people
really don't know what extern means either.

>The only reason static SEEMS to mean 2 different things

It doesn't seem, it really does have more than one meaning.

> is that it can be used inside
>a function, where the default for variables is "auto and not-extern"
>and outside a function where the default is "not-auto and extern".

As an aside that's not completely true of C++: consider consts.

Anyway, the default outside a function is still static [lifetime],
whether you say it's so or not.  So telling somebody that,
and then telling them they can also actually use the static
keyword certainly is confusing to folks.  "If it's already
static, why do I need to say say?"  Because this one means
something else....

And of course, static on a static member means it has
external linkage, and you cannot repeat the static for the
definition.  Again, this is multiple meanings and is confusing to folks.

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dennis Yelle wrote:
>
>   Please ignore my previous message on this subject.
>   This is what I intended to write:

It's still wrong. :-)

>
> Well, since static always means "not-auto and not-public" I
> guess that the only real reason people find it confusing is
> that the books don't explain it properly.  The only reason static
> SEEMS to mean 2 different things is ...

The word "static" in C++ has at least three different meanings:

1. Having a lifetime until the end of the program.
2. Having internal linkage.
3. Belonging to a class and not to any instance of the class.

The surrounding context determines the meaning.

Example translation unit:

int a;  // static storage duration, external linkage
static int b; // static storage duration, internal linkage
class C {
 static int c; // static storage duration, external linkage
   // not part of any class instance
};
void f()
{
 static int d; // static storage duration, no linkage
}

Any object declared with the keyword "static" has static storage
duration, and you might be thinking only of that property.  But
some objects not declared static also have static storage duration,
such as "a" in my example.

The static keyword also affects linkage, but not in any uniform way:
For b,    static changes the linkage from external to internal.
For C::c, static changes the linkage from none to external.
For d,    static does not change the linkage.

--
Steve Clamage, stephen.clamage@sun.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <398A345C.26196E2E@jps.net>, Dennis Yelle <dennis51@jps.net>
writes
>But I thought that the regulars here already knew all of this.
>(Especially you, Francis, and, by the way, this is intended to be
> a complement, not an insult.)

Of course I knew it, I even worked out the rationale for myself many
years ago but that does not really justify the usage (IMHO) and if we
can simplify things for others we should do so instead of hanging onto
the arcana more appropriate to some secret priesthood.

>
>You are right when you say that static is not used as often as
>it should be.  Just like const, static should have been the default
>for functions and variables defined outside a function.  But, I suppose
>that it is too late to change either of those now.

Yep, just one more place where the default is exactly 180 degrees out
from what it should be, IMO.


Francis Glassborow      Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Chris Newton wrote:
>
> Why is the use of unnamed namespaces preferred over "static"?

Last week we had some troubles (at our institute) because of the use of
"static".  We had 2 static template functions defined in separate units,
having the same name and signature.  To our surprise, a function-call
done inside one of the units resulted in a template function from the
other unit being called!!!

So I had written in MyFile.cpp:
  template<typename T>
  static void StaticTemplateFunc(T param)
  {
     std::cout << "You are now in MyFile.cpp";
  }
While my college had written in HerFile.cpp:
  template<typename T>
  static void StaticTemplateFunc(T param)
  {
     std::cout << "You are not in MyFile.cpp, you are in HerFile.cpp";
  }
And then when I did:
  void MyMain(void)  // In MyFile.cpp
  {
    StaticTemplateFunc(0);
  }
...the call to StaticTemplateFunc gave me: "You are not in MyFile.cpp,
you are in HerFile.cpp".

Does the Standard allow a C++ compiler to give me this unexpected
result?  (We got these troubles when we compiled with MSVC++ 6 SP4.)

If we would convert from using static keywords to unnamed namespaces,
these troubles would not occur, and I would get what I wanted: "You are
now in MyFile.cpp".  (BTW We did not get these troubles when we used
Borland C++ 5.5 instead of MSVC++.)

Niels Dekker
ndekker "at" nki "dot" nl

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <398AD98F.32E06FB@REMOVETHISnki.nl>,
Niels Dekker  <ndekker@REMOVETHISnki.nl> wrote:
>a function-call done inside one of the units resulted in a
>template function from the other unit being called!!!
>
>So I had written in MyFile.cpp:
>  template<typename T>
>  static void StaticTemplateFunc(T param)
>  {
>     std::cout << "You are now in MyFile.cpp";
>  }
>While my college had written in HerFile.cpp:
>  template<typename T>
>  static void StaticTemplateFunc(T param)
>  {
>     std::cout << "You are not in MyFile.cpp, you are in HerFile.cpp";
>  }
>And then when I did:
>  void MyMain(void)  // In MyFile.cpp
>  {
>    StaticTemplateFunc(0);
>  }
>...the call to StaticTemplateFunc gave me: "You are not in MyFile.cpp,
>you are in HerFile.cpp".
>
>Does the Standard allow a C++ compiler to give me this unexpected
>result?  (We got these troubles when we compiled with MSVC++ 6 SP4.)

If I recall this properly, it is ill-formed, however,
a diagnostic is not required, so this comes down to a QoI
issue in some ways.

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dear all,

Why is the use of unnamed namespaces preferred over "static"? I
appreciate that using static in this manner is deprecated behaviour, and
many experts (and the standard) state that unnamed spaces are a superior
solution to the same problem. I have yet to see any logical reasoning to
support this, however, except that it avoids overloading static with
unnatural (but well-known and idiomatic) meanings. Can anyone provide
such a reason? Is there any difference in practice between
  static int x;
and
  namespace { int x; }
?

Thanks,
Chris


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8lshrm$q9$1@plutonium.btinternet.com>, Chris Newton
<chrisnewton@no.junk.please.btinternet.com> writes
>Dear all,
>
>Why is the use of unnamed namespaces preferred over "static"? I
>appreciate that using static in this manner is deprecated behaviour, and
>many experts (and the standard) state that unnamed spaces are a superior
>solution to the same problem. I have yet to see any logical reasoning to
>support this, however, except that it avoids overloading static with
>unnatural (but well-known and idiomatic) meanings. Can anyone provide
>such a reason? Is there any difference in practice between

The most important issue is one of linkage. static qualified global
objects have internal linkage while unnamed namespace ones have external
linkage. When you start using generic programming (templates) the
difference is very important as template arguments must have external
linkage.



Francis Glassborow      Association of C & C++ Users
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <8lshrm$q9$1@plutonium.btinternet.com>, Chris Newton
> <chrisnewton@no.junk.please.btinternet.com> writes
> >Dear all,
> >
> >Why is the use of unnamed namespaces preferred over "static"? I
> >appreciate that using static in this manner is deprecated behaviour, and
> >many experts (and the standard) state that unnamed spaces are a superior
> >solution to the same problem. I have yet to see any logical reasoning to
> >support this, however, except that it avoids overloading static with
> >unnatural (but well-known and idiomatic) meanings. Can anyone provide
> >such a reason? Is there any difference in practice between
>
> The most important issue is one of linkage. static qualified global
> objects have internal linkage while unnamed namespace ones have external
> linkage. When you start using generic programming (templates) the
> difference is very important as template arguments must have external
> linkage.

Yes, that is true.  But I have never understood exactly why.
When I think about it, that rule seems quite arbitrary.
Can someone explain why they were not allowed to take
static qualified global objects too?

I mean really, we could just decide that this:
  static int thing;
was just an abbreviation for this:
  namespace { int thing; }

Also, as to the original question:
Why is the use of unnamed namespaces preferred over "static"?
Is the above template limitation the only reason?
That just doesn't seem like enough of a reason to depreciate
that usage of static.  It is not likely to be removed from
the language, because it would be another incompatibility with C.

I really don't understand why some people dislike that
usage of "static" so much.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  http://table.jps.net/~vert

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8lshrm$q9$1@plutonium.btinternet.com>,
Chris Newton <chrisnewton@no.junk.please.btinternet.com> wrote:
>Why is the use of unnamed namespaces preferred over "static"? I
>appreciate that using static in this manner is deprecated behaviour,
>and many experts (and the standard) state that unnamed spaces are a
>superior solution to the same problem. I have yet to see any
>logical reasoning to support this, however, except that it avoids
>overloading static with unnatural (but well-known and idiomatic)
>meanings. Can anyone provide such a reason? Is there any difference
>in practice between
>  static int x;
>and
>  namespace { int x; }
>?

I'm not exactly sure what you're looking for, but have a look at
http://www.comeaucomputing.com/techtalk/#nostatic
If there's some other issue, holler.

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <hO79$NBurdh5EwhF@robinton.demon.co.uk>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>static qualified global objects have internal linkage while
>unnamed namespace ones have external linkage.

At least the non-static qualified ones. :)

>When you start using generic programming (templates) the
>difference is very important as template arguments must have external
>linkage.                       ^^^^
                                some

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3985F6B9.FAC62118@jps.net>, Dennis Yelle  <dennis51@jps.net> wrote:
>Francis Glassborow wrote:
>> The most important issue is one of linkage. static qualified global
>> objects have internal linkage while unnamed namespace ones have external
>> linkage. When you start using generic programming (templates) the
>> difference is very important as template arguments must have external
>> linkage.
>
>Yes, that is true.  But I have never understood exactly why.
>When I think about it, that rule seems quite arbitrary.

Because template can have external linkage, and also be
defined/instantiated elsewhere, and some baggage would be
necessary to get non-external types "to" them.

It's not much different that say a class local to a function
not be allowed to have a static member, and so on.
Arbitrary?  Not really.

>Can someone explain why they were not allowed to take
>static qualified global objects too?

Same reason.

>I mean really, we could just decide that this:
>  static int thing;
>was just an abbreviation for this:
>  namespace { int thing; }

We could decide that, however, the committee has already
decided that the above is not exactly the same thing.

>Also, as to the original question:
>Why is the use of unnamed namespaces preferred over "static"?
>Is the above template limitation the only reason?
>That just doesn't seem like enough of a reason to depreciate
>that usage of static.  It is not likely to be removed from
>the language, because it would be another incompatibility with C.
>
>I really don't understand why some people dislike that
>usage of "static" so much.

Check out http://www.comeaucomputing.com/techtalk/#nostatic

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau wrote:
>
> In article <8lshrm$q9$1@plutonium.btinternet.com>,
> Chris Newton <chrisnewton@no.junk.please.btinternet.com> wrote:
> >Why is the use of unnamed namespaces preferred over "static"? I
> >appreciate that using static in this manner is deprecated behaviour,
> >and many experts (and the standard) state that unnamed spaces are a
> >superior solution to the same problem. I have yet to see any
> >logical reasoning to support this, however, except that it avoids
> >overloading static with unnatural (but well-known and idiomatic)
> >meanings. Can anyone provide such a reason? Is there any difference
> >in practice between
> >  static int x;
> >and
> >  namespace { int x; }
> >?
>
> I'm not exactly sure what you're looking for, but have a look at
> http://www.comeaucomputing.com/techtalk/#nostatic
> If there's some other issue, holler.

OK, I read that (section of) that page, and everything was OK
until I got to this:

  Draw your attention to that that none of the above is equal to this:

  // x.cpp
  namespace { // DDD
      static bool flag = false;
  }

I give up, when would I ever want to say that instead of this:

 namespace { // DDD
      bool flag = false;
  }

And please don't tell me that it prevents flag from being used
as a template parameter.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  http://table.jps.net/~vert

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau <comeau@panix.com> wrote...
> Dennis Yelle  <dennis51@jps.net> wrote:
> >Francis Glassborow wrote:
> > > The most important issue is one of linkage. static
> > > qualified global objects have internal linkage while
> > > unnamed namespace ones have external linkage.
> > > When you start using generic programming
> > > (templates) the difference is very important as
> > > template arguments must have external linkage.
> >
> > Yes, that is true.  But I have never understood exactly
> > why. When I think about it, that rule seems quite arbitrary.
>
> Because template can have external linkage, and also be
> defined/instantiated elsewhere, and some baggage would be
> necessary to get non-external types "to" them.

OK, I can accept the argument here by Greg and Francis that the linkage
is relevant if we're going to use a static value in some way in a
template argument. I guess it seems slightly extreme to me to deprecate
this use of static in case someone tries to use a static const int as a
const int & template argument. After all, removing the deprecated use
from the language at a future date would break lots of existing code. I
can see the technical merit in advocating the use of unnamed namespaces,
however.

Perhaps I can change my question somewhat. The vast majority of uses of
static that I have seen have been defining a simple symbolic constant,
something like
  static const double fred = 1.0;
where the constant defined cannot be replaced with an enumeration as
integer constants can. In such cases as these, should we be moving
existing code such as the above to the form namespace { const double
fred = 1.0; } in case the static language feature is later removed? Is
there any serious risk of this, as the deprecation would suggest, or is
existing code fairly safe?

Thanks for the continuing input,
Chris


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8m72f5$74i$1@neptunium.btinternet.com>,
  "Chris Newton" <chrisnewton@no.junk.please.btinternet.com> wrote:
> Perhaps I can change my question somewhat. The vast majority of uses
of
> static that I have seen have been defining a simple symbolic constant,
> something like
>   static const double fred = 1.0;
> where the constant defined cannot be replaced with an enumeration as
> integer constants can. In such cases as these, should we be moving
> existing code such as the above to the form namespace { const double
> fred = 1.0; } in case the static language feature is later removed? Is
> there any serious risk of this, as the deprecation would suggest, or
is
> existing code fairly safe?

This is a subject under active discussion on the Committee.
See http://www.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#223
and the links there to issues 168 and 174 for some background.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8m72f5$74i$1@neptunium.btinternet.com>,
Chris Newton <chrisnewton@no.junk.please.btinternet.com> wrote:
>I guess it seems slightly extreme to me to deprecate
>this use of static in case someone tries to use a static const int as a
>const int & template argument. After all, removing the deprecated use
>from the language at a future date would break lots of existing code. I
>can see the technical merit in advocating the use of unnamed namespaces,
>however.

I simply can't recall the discussions about this at the time
but I imagine it was just the sum of the parts coming to this same
conclusion, and so the deprecation step was taken.  Clearly
static is a rather low level, fine grained, approach to encapsulation.

I think we need to back up a bit, and consider perhaps a bigger
picture.  That is, it's usually accepted that "globals are bad".
So, namespaces, in general, were use to address this in part.
IOWs, at least now you'd have:

   namespace SomeGroupOfNames {
        // names visible through SomeGroupOfNames only
   }

Even within a source file (not just a header).

So the real issue is that a source file can create its own set of
locality in this manner.  _*THIS*_ was used instead of
(read: "to implictly deprecate") statics.  Now, almost as a
side-issue, note that in many cases what was important was not the
name SomeGroupOfNames (which could turn out to clash with some other
randomnly chosen name in another translation unit) but the actual
act of namespace'ing itself.  Furthermore, in many cases,
"funny" names had to be invented for SomeGroupOfNames just to
satisfy the namespace syntax.

So in conclusion, why not allow for unnamed namespaces too?
And oh, "BTW", they are used instead of statics and instead of
named namespaces.  So, IOWs, use of static in this context is
deprecated.  Yes?  Isn't it?  So why not "bless" it thus?

>Perhaps I can change my question somewhat. The vast majority of uses of
>static that I have seen have been defining a simple symbolic constant,
>something like
>  static const double fred = 1.0;
>where the constant defined cannot be replaced with an enumeration as
>integer constants can. In such cases as these, should we be moving
>existing code such as the above to the form namespace { const double
>fred = 1.0; }

Yes, the underlying premise is to use namespaces in general, so...

>in case the static language feature is later removed? Is
>there any serious risk of this, as the deprecation would suggest,
>or is existing code fairly safe?

Speaking for myself, as a general comment, I think that the
committee needs to evaluate what deprecated really means and
what it's implication really are, in full, and on a case by
case basis.  And I'm certain they will, when the standard
comes up for its 5 year revision.  This one clearly has
C compatibility issues, and probably a thing or two
that wasn't originally obvious about it, so it just might
be one of the less clear ones.

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]